Rocket Talk - Arduino-based radio flight data

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Another possibility other than cranking up to a bigger processor is to split your processing using more than one arduino and allocate specific tasks to other "intelligent" modules. A simple command and communications interface (serial) between the two can have them cooperating nicely. That's how I design my spectrometers. Interestingly they use ATMega328P devices too ☺.
 
I don't know how much free RAM you have left but I'd try to make a 3 second circular buffer. When a launch is detected start saving the data at the top of the buffer. That way you don't waste any EEPROM but have all the data from prior to launch. Just remember to wait 4 or 5 seconds after landing to stop recording so all the buffered data is saved. Of course this assumes that you can write to EEPROM faster than new data is coming in. Just a thought.

Thanks all for the feedback. It sounds like my launch detect threshold is too low, but unlike a basic DD altimeter, I am trying to capture as much data and telemetry as possible, so I don't want to miss logging the first few seconds of the launch. When the rocket is sitting on the pad for 45 minutes waiting I don't want to be logging data to an SD card at the same resolution as logging during launch (<100ms). I think a hybrid option would be to activate high resolution data logging at the lower accelerometer or "10 foot" trigger threshold, but abort logging if I don't get a real confirmation (much higher accelerometer and barometer readings) within a few seconds. I'll need to play with that logic to get the benefit of early logging without the false positive for launch detect. For now, I'll use both sensors at the bottom and top, until I can characterize some real life data.
 
I don't know how much free RAM you have left but I'd try to make a 3 second circular buffer. When a launch is detected start saving the data at the top of the buffer. That way you don't waste any EEPROM but have all the data from prior to launch. Just remember to wait 4 or 5 seconds after landing to stop recording so all the buffered data is saved. Of course this assumes that you can write to EEPROM faster than new data is coming in. Just a thought.

The Eggtimer altimeters do that, the newer ones use the whole amount of allotted EEPROM in a circular buffer so they can go back arbitrarily from the launch detect to a few seconds prior to launch. Since EEPROM's have a finite number of write cycles, you want to minimize writes if you can, and using a larger EEPROM footprint does that. As far as speed of EEPROM, when you're done with the write you have to wait about 3-5 ms. At 100 samples/sec that can be significant... if you're concerned about write speed then you should think about using a buffer SRAM or FRAM ahead of your EEPROM. Ditto for flash memory... but even more so.
 
Another possibility other than cranking up to a bigger processor is to split your processing using more than one arduino and allocate specific tasks to other "intelligent" modules. A simple command and communications interface (serial) between the two can have them cooperating nicely. That's how I design my spectrometers. Interestingly they use ATMega328P devices too &#9786;.

I had planned to do this on the rocket side, but so far I'm not processor constrained. On the base station I am doing this for the "talking telemetry" capability, so that verbal speaking of telemetry doesn't pause radio reception or incoming data. For the talking telemetry I am using a small Arduino nano with a SD/MP3 module and I'm passing commands/telemetry to it using a serial connection. I can pass serial commands and be done in about 2ms. On the rocket, most of my modules (GPS, Radio, MPU, SD Card, etc) have strong processing and buffering capability, so very little CPU gets tied up.

The 3-4 second looping buffer before launch makes a lot of sense. I can probably fit it in memory (RAM), as my samples will probably be less than 20 times a second. My design has all the telemetry data streaming to an SD card and not to an EPROM, giving me almost unlimited capacity, so I would need to figure out how to dump the 3-4 seconds onto the card at launch and/or maybe wait for descent to spend time writing it out, so I don't miss the "good stuff" immediately following launch. Another option would be to use the EPROM or RAM on the way up and then write to SD on the way down. If I keep a file open on the SD Card I can write a line of data at a rate of 1ms - that is pretty fast, but 3-4 seconds will give me 60-80 lines to write. I am also not sure how the SD card is going to perform under very high G forces -- another reason to use EPROMs on the way up.
 
A quick progress report. I designed a custom 3D printed sled to get all the hardware to fit in a 3" rocket for testing. I was about 4mm shy of getting it to all stack in a 4" x 3" round package, but I ultimately had to stack the radio below the CPU and battery, resulting in a 6.5" sled package. With more work and a different battery I'm sure I could get it down to 4".

In the rocket sled I've got the high power serial radio, a 1200mah 7.2 Lipo battery, an Arduino Mega, a voltage buck converter (to step down voltage to radio and filter radio noise), a barometer, an MPU9250 Accelerometer, Gyro, Magnetometer, a piezo siren, voltage sensor, fore/aft separation sensors, SD card, and a Ublox NEO M8 GPS.

That is a lot of component hardware. It weighs in at 10.4 oz. The only thing missing is the antenna (going external).

I've got all the basic code loaded on the package and the logic laid out. Now I need to refine the code, integrate with the base station, and do some more ground testing.

IMG_6701.jpg IMG_6700.jpg IMG_6699.jpg


IMG_6697.jpg IMG_6696.jpg
 
I am also not sure how the SD card is going to perform under very high G forces...

The SD card should be fine. I've tested mine at 30G's without any issues, logging data at 800 samples per second from multiples sensors.

I was reading through this thread again and am definitely concerned with your apogee detection logic. Nearly all of my rockets rotate well past 20 degrees before apogee. Some combination of barometric and integrated vertical velocity would be a better choice.

As for the preflight data logging issue, I simply start logging to the SD card when the accelerometer reads more than 2.5Gs. Sure, I miss a few samples, but its only 0.02 seconds of data, probably less. If the 2.5Gs isn't sustained for more than 0.3 seconds (user configurable), then the flight computer resets itself, ensuring that an accidental bump or drop at the pad doesn't set everything off.

Your avionics sled and setup are impressive. I'm definitely jealous. Mine look like a tangled mess of connection wires and breakout boards.

Good luck!
 
Last edited:
Thanks Sparky. For now, I'm keeping it simple and will use similar logic for detecting and logging the launch. I get 4 samples of >2g about 30ms apart, but it is all configurable. Since I am not using this for ejection right now, I am doing a bunch of logging around tilt, speed, 3-way acceleration, and pressure (altitude), once I get a number of launches under my belt I'll try and fine tune the best combination to detect apogee. As a simple starting logic I'm using tilt > 70 degrees -or- 3 consecutive altitude drops of 10'.

I am going to do a bunch of backyard "drone launches" with the rig lifted 400' up and down with a drone. Like a super slow motion launch, just to shake out any final bugs in the logging or radio telemetry. I was set to do this on Saturday, but I started to get a lot of odd false launch positives from my MPU while bench testing for long periods of time. When waiting still for launch, I would get a random value of >16g or some burst of random values up or down. I am using the Digital Motion Processor from my MPU6050 (MPU9250), so it was odd to see crazy values from out of nowhere. After 3-4 hours of troubleshooting the MPU, calibrating, and double-checking the quaternion functions I realized my issues were not code related. At first I suspected a memory leak (Arduino freak out when they run out of memory), but then I figured out it was time and heat related. I think I solved the source/cause of the overheating Arduino, so now I am back to constructing some tests.

Mike
 
This week I continued to get a lot of odd readings on the accelerometer / gyro (MPU9250). I originally suspected overheating, since I was really taxing my Arduino regulator, but moving components to other power sources didn't completely solve the issue. I got a good lesson in level shifting this week. Anyone doing serious Arduino work should make sure they understand which components communicate on what voltage level. Each Arduino uses different pin/communication voltages. The Mega2560 is generally using 5V for communicating, but most I2C (SDA/SCL) components are 3.3V chips. I have a I2C Barometer, but it has a level shifter built in, so it is 100% compatible. The same goes for my SD Card. My MPU9250 is 3.3V with no shifter, so driving it with 5V is problematic. I needed a level shifter on the communication lines. I also did a full review of the components and realized my GPS and Radio both needed level shifters on the TX/RX lines, since they are 3.3V and the Arduino is 5V. Both of those seemed to work OK, but I suspect the 5V would eventually wear them out and/or the lower incoming voltage could result in dropped serial packets. Now things seem to be rock solid...at least, on the bench.
 
This thread reads like my past bedtime dreaming to fall asleep over the last year. :) I've been tinkering with the idea myself.

My design constraints though is size. We have a few 24mm and 29mm minimal diameter rockets I'm toying with the idea of trackers and telemetry data to a base station. I am very glad to see this project come to light.

@AllDigital: I see you've ordered from Adafruit. Have you seen their Feathers?

Specifically, the addon "Wing" version with MTK3339 GPS or perhaps one of the LoRa radio versions?

The M0 processor in the Feathers has the same ram, but is 4x faster in CPU cycles than the Mega I think you're using.

The fact that these Feather components come in such a small package that is stackable makes it pretty easy to pick "off the shelf" parts to piece together an electronics bay that fits the students' budget.

I've been curating a number of the GPS and LoRa radio feathers, along with some Teensy 3.2s that someone else mentioned as well during my travels. This fall/winter things should slow down enough to where I can take on the project during downtime.
 
Eric, I love the teensy boards. That is a lot of power in a small package. I have used them in a few other projects. I am not familiar with the feather boards, but at first glance they look fast and small, as well.

I went with the Mega2560 on a small board, given the huge amount of I/O options and the massive amount of developer support for the real Arduino boards. The tried and true libraries and developer knowledge base has been helpful. Also, the smallest rocket for my design was going to be 3&#8221;, so size and weight weren&#8217;t big concerns. That being said, the Mega is not that fast compared to other cpus, but it seems to be fast enough so far for me. Most of the lag time is in the modules (gps, mpu, barometer, sd card, radio, etc).

Everything I&#8217;m building is fairly modular, so all or some of it should be able to port to smaller platforms. Switching radios should also be simple, as long as they are serial TTL. The base station code could also be repurposed to be a bridge or repeater to a phone, laptop or WiFi server. Most of the effort has been getting each component working fast, reliable, and timed with all the other components in a single threaded environment. That code/config is all reusable. Once that was done the fun is in writing the code to orchestrate all the things going on at each phase of flight.
 
I’ve used the Adafruit feathers... There are a few variants, M0, ESP8266, ESP12 - with lots of cheap Chinese knock offs around. I’ve had good luck with the $10 esp8266 based units. They are all arduino compatible - you can use your arduino code *mostly* and program with the arduino C++ variant, but they are way more powerful and much quicker than a traditional AT based arduino. Writing code when you get a few K of ram is a fun challenge, but it’s 2018 not 1983.... No problem interfacing with my existing i2c sensors.

Having onboard wifi means you can write a UI and control these with a phone or laptop. They can all act as their own wifi base station. I just dial up my rocket from my phone and it gives me nice java script rendered SVG graphs of all the flights, I can set up all the parameters, arm/disarm all the things, download the raw data, etc. 3.3v logic though and not nearly as many IO pins, but there are solutions for that.
 
Using a drone to test &#8220;launch&#8221; the rocket package was laughable today. With the weight of the package (10 oz) I couldn&#8217;t even come close to hitting my 2g launch detect. The drone pulled it up to 400&#8217; pretty fast, so I was able to verify the basics.

I&#8217;ll add a pressure (altitude) detect for launch temporarily, so I can verify everything else works.
 
I'm resurrecting this thread after a year of hiatus. My son and I went to launch our “Rocket Talk” telemetry package a few times last summer, but got shut down by wind each time. Around April this year we decided to completely overhaul the project and move the rocket CPU over to an ESP32, instead of the Arduino Mega. Jnobels had suggested the older ESP before, but I was wary of Arduino compatibility. The newer ESP32 is freaking fast with two separate cores. It took a lot to migrate the Arduino code, since the Arduino IDE for the ESP is very touchy and a lot of libraries won’t work without modification. But in the end, the speed and agility was worth it. We have one core just sampling the MPU9250 and the Barometer 100 times a second and the other core doing all the housekeeping of checking the GPS, writing to SD, sending on the radio, and more. We are not using any of the wifi, Bluetooth, or other capabilities on the module and likely using less than 50% CPU.

The rocket side includes the ESP32, a BME280 (barometer+), MPU9250 (gyro, accel, mag), Ublox M8N GPS, SD Card, 2W serial radio in the 2M band, and two small lithium-ion batteries. It also has sensors to detect fore/aft separation events and it uses an inverted V dipole antenna.

After months of porting code, bench testing, and launching it up and down on our drone, we finally tested the package this weekend out at FAR (Friends of Amateur Rocketry) in California. We used a 3” fiberglass rocket with a 54mm MM as the test vehicle, along with two commercial altimeters for dual-deploy (not our boards). Overall, both tests were very productive, but they both had anomalies that we are still investigating. Here is a summary of results:

Test 1: Launched on J760 to 5,548’ and top speed of 843 fps. Everything worked perfect up to apogee and into descent, but then 30 seconds into descent we got extremely high readings off the MPU9250 and the ESP32 core dumped and rebooted. It came back online after rebooting and continued to stream and record data all the way down to landing. The anomaly and reboot happened 30 seconds after drogue separation and 40 seconds before main ejection, so we don't think it was related to pyro stress on the accelerometer.

Test 2: Launched on a K675 to 8,505’ and top speed of 1053 fps. Everything worked perfect to apogee and then 5 seconds after AFT separation the entire CPU went offline/dead. This anomaly could be the same as #1, but appears more timed with AFT separation and potentially something breaking due to the force of separation – although when powered off and back on it functioned normally.

Both of these issues are difficult to troubleshoot without flying. The MPU9250 has been very challenging to get stable with the ESP32. We are directly using the DMP (digital motion processor) instead of the raw data. It is setup for 16G and a sample rate of 100Hz. It is generally stable at rest and in our drone testing. The accelerometer range at 16G should be something like -16000 to +16000, but we were getting values of 32000 and -32000 on the Z axis accelerometer ten seconds before the first failure/reboot. The DMP should be giving us clean readings, since it is using filters by design.

Regardless of the anomalies, everything else worked very well. We detected launch within 1 second and apogee within 1 second and simultaneous with the commercial altimeters. The radio transmitted results consistently at all stages. The GPS lost connection at launch and immediately regained within 5 seconds of apogee. The SD card logging and barometer worked perfect, writing to three files once a second on the way up. The base station also worked perfect.

So, back to the drawing board on the accelerometer...
 
Mike, thanks for posting this update. I've enjoyed following your project. Please post any updates on your work with the accelerometer.

Just out of curiosity, what radio did you use in the final build for your two test flights? Transmit power level?

Thanks.
--MARK
NAR 65148, L1
 
Hi Mark,

I am using serial TTL radios from NiceRF -- in the 433Mhz 70cm band (not 2M mentioned above) and 2W. I know they are in a legal Amateur Radio band and I am including my call sign in all transmissions, but I have not confirmed power/packet parameters for the region. I am running them slow at 4800 baud over-air with strings of less than 150 characters. To improve reliability I queue all transmissions and space them apart 1000ms, while I still log locally to SD at a rate of 100ms. The radios I am using are here: https://www.nicerf.com/product_148_61.html

On the accelerometer side, I am going to experiment with this "Ultimate Sensor Fusion Solution" that packages an EM7180 with a MPU9250 for a (hopefully) more reliable Digital Motion Processor with faster warm-up. It looks promising, but I won't know until I put it through hoops. Here is the link: https://www.tindie.com/products/onehorse/ultimate-sensor-fusion-solution-mpu9250/

I will eventually get my build and code up into Github, so others can use it or iterate.
 
Here is a quick update...

We integrated the EM7180, replacing the MPU9250 accelerometer and a BME180 barometer. The data fusion on the EM7180 is much easier to use and far more stable than the DMP on the MPU9250. We are going to do a few test launches to 10K next weekend, but a dozen "drone launches" have demonstrated solid stability, so I am optimistic. That is an amazing amount of capability on a tiny package.

We also integrated hall sensors and magnets to monitor the forward and aft separation events. Wiring, magnets, and sensors are all wired and epoxied and protected inside the airframe, so hopefully they survive ejection charges.

The base station software has also been upgraded to do full tracking, based on current (radio) long/lat or last known position. It also produces a summary at the end of each launch with dozens of data points, including barometer AGL, GPS AGL, top speed in fps, ops, mph, top acceleration (before ejection), flight time, decent rate, decent speed before hitting the ground, distance from range, etc.

Hopefully tests go well next weekend.
 
QUESTION: The question I am struggling with now is determining Altitude, using only the Accelerometer data. I have good altitude reading from the barometer, but that is only reliable up to 50K feet (?). The GPS is accurate, but cuts out on launch and doesn't always reconnect at apogee. So, I want a third way to calculate altitude using the accelerometer data transmitted to the base station.

Here are my parameters and my assumptions. Let me know if this is correct thinking...

I am sampling the accelerometer 100 times a second (100hz). It is stable and calibrated. At rest, on the Z axis with gravity removed, I show a value of approx. 10 on a scale of -16000 to +16000. upside down it is about -10, so pretty darn accurate. It is going through a good DMP, so noise should be low.

I am storing a cumulative acceleration value (cumAcceleration) with each sample, by adding the difference of the current sample from the last sample. cumAcceleration = cumAcceleration + (currentReading - lastReading). I think that should give me displacement. As the rocket accelerates through burn the cumAcceleration goes up and as it coasts to a stop at apogee the number goes down, eventually to zero. This works on a small scale at the bench, but I haven't tried it in flight. I can expand this by dividing by 100 (100hz sample) and multiplying times 9.8M/s to get altitude.

Does anyone have a good example, sources, or samples of converting the accelerometer data to altitude?
 
Mike, your thinking is correct and your equation is close to correct. Here's what I just tested on my high-rate data files and it worked:

Ac = Ac + (acceleration_current - g) * (timeNow - timePrevious)

Do this every cycle of the code, and when Ac goes negative you have apogee. In my experience, this happens about 2 seconds after true apogee due to various sources of error. Still good enough for deployment above 30K ft.

Your idea is a simpler idea compared to what I do. I use the data to integrate velocity and altitude at 1000Hz, and use a negative velocity value as one trigger for apogee. I also use a smoothed velocity off the barometric pressure sensor as a second trigger.

Here is my code in case you want to use it:

//calculate the new acceleration based velocity
//this makes the apogee event mach immune
accelVel += (accelNow - g) * (timeNow - timePrev);

//calculate the new acceleration based altitude
accelAlt += accelVel * (timeNow - timePrev);

Proper calibration of these MEMS sensors is critical. If your Z-axis is outputting -10 when its perfectly aligned vertical (minus g), then this is a bias in the sensor called an offset. The cumulative error of this value will make your apogee estimate less accurate. Store this value in EEPROM and subtract it off of the acceleration readings each cycle before conducting calculations with it. The offsets don't change that much over time, and I have an entire routine dedicated to calibrating my system.

I'm nearly finished with the prototype of my 3rd generation system, which has a lot of similarities to yours. It records data at 1300Hz and sends telemetry at 20Hz over 433Mhz LoRa.

Front.JPGBack.JPG
 
Last edited:
Wow. That is a great package. Very nice custom PCB. What processor you are using? Also, 1300Hz is screaming fast sample resolution. Are you logging all those (SD or EPROM) or just sampling at that rate?

Right now, for apogee I am using a tilt calculation (tilt > 70d) based on pitch/roll from the integrated accel/gyro. That seems to be the most accurate. I'm using barometer as a back-up (3 checks 1000ms apart >20' drop), but understand it isn't reliable on mach flights or at high altitudes.

Is your real-time integration of accel->velocity->altitude accurate? The formula above makes sense, but it seems too simple. I just got done reading the USC white paper on their Karman line apogee analysis and it gave me a whole new appreciation for how hard it is to calculate altitude above 100K feet. They were not integrating altitude real-time (I don't think), but instead pulled the raw log data into a flight analysis tool after the fact. The paper is a great read for anyone doing serious rocket telemetry. link is here: https://tinyurl.com/y5bla36y It seems like they struggled a lot with the X and Y accelerometer data impacting the Z axis data, given the accelerometers position in the rocket and the amount of spin, tumble, etc. In their analysis of future ideas at the end of the paper they talk about a lot of crazy stuff (ground radar, roll their own partial GPS, permit for aerospace GPS, etc.) they don't talk about doing real-time altitude integrations with the accelerometer. What is your take on that? If the sample rate is high enough and the real-time integration proves accurate for the first 40K feet (verified by barometer) then this seems like an obvious solution.
 
I use the Teensy 3.5 as the main processor, and yes, I log all that data to the SD card. Its actually pretty quick. 83% of my per cycle time is tied up in i2c communication with the three sensors (2 accelerometers, 1 gyro). I'm still working on the latest unit, but I expect about 1500 samples per second. That's far above the sensors' max output rate, but I need that extra room to implement the next phase, which is directly driving active stabilization servos.

The integration is simple and rough, but I'd argue its accurate enough for deployment. Is it perfect? No, but it will most likely get you deployment within a few seconds of true apogee. See the graph below comparing baro, integrated, and GPS altitude (the wiggle in the green line is supersonic flight playing with the barometric data). Barometric is good for altitudes below 30K ft or so. Above that you need something else, or a much better sensor. At altitudes like that, its also probably OK if you are a little late at deployment. The air is thin enough that even if you are traveling at a decent speed it can't provide enough force to cause a significant zipper. Combine this with rotation and I think you have a winning formula. I'm planning on coding up an automatic gain adjustment that should also help with accuracy of integrated altitude & velocity.

When I integrate rotation, I do not use the accelerometer like the USC team. Gyroscope only. I really don't see any measurable cross-axis influence when I do it that way with the L3GD20H or LSM9DS1. With the spin and dynamic forces of our rockets, I'm not even sure how to use the accelerometer to measure rotation. Maybe somebody has figured it out, but any sensor fusion algorithm that needs a g-reference is sure to fail in a typical rocketry flight. A Kalman filter is on my list of things to code, but low priority since the current method is close enough for me.

With the Teensy 3.5 FPU, real-time integration of speed and altitude is not a problem. Even a full-blown Kalman filter will process fairly quickly. I use my own simplified algorithm to integrate rotation, but using quaternions is still almost as fast. A trig lookup table helps a lot if you have the program space to implement it. Look at my Github site if you need an example. https://github.com/SparkyVT/HPR-Rocket-Flight-Computer

Int_Baro_GPS_Altitude.jpg
 
Very cool. I look forward to seeing the servos, perfectly straight flight and no spin. Too bad we aren't allowed to guide it back to the pad and fire landing thrusters. Someday.

I've been playing with the accelerometer->velocity->altitude algorithms and they seem pretty straight forward. I've found with a lower sample rate the altitude formula needs to average the velocity to stay accurate. Something like this:

accelAlt += ((lastVel + accelVel)/2) * (timeNow - timePrev);

I'm not sure how much it matters, but in my simulations at lower resolutions it made a big difference.

My new 9DOF fusion board already uses quaternions and appears to also correct altitude using the barometer. It off-loads the fusion and (local) I2C traffic onto another processor. I need to go deeper with what it is already doing under the covers. I'll see how it tests this weekend under flight.
 
Hi AllDigital,

You may have settled on radios etc already but I though I would add my 2C here as well since I went through this process some years ago and settled on something different again.

The radio I'm using are the RFM23BP from HopeRF, these are using the SiLabs chip (SI4432 I think) + power amp to get the extra 10db. This is a 1W digital radio and has been proven to be solid so far. I am using the same module at both ends and running in the 420 to 430MHz range (HAM operator). The same radios are available in 900MHz range as well.

uC I have been using to date for these types of projects is the dsPIC33EP256MU806 which has enough capability for this sort of project.

On board sensors - triaxial accelerometer MMA68XX, Baro - MS5607-02BA03, GPS - UBlox Neo 6M

Flash memory for logging : 8Mbyte AT45DB161D (proven to be very reliable and quite fast)

https://drive.google.com/open?id=1RillnlNdPHoShPVO_fy_zJc4_Yu_clgB

https://drive.google.com/open?id=1itvPf43WZxqdJid1vDaxFfPmKS_qgcsS

To date I have been using this primarily for tracking and logging functions, but intend to provide some recovery functionality at some point.

I have connected a 9 DOF sensor board from Pololu and gathered some quite useful gyro and magnetometer data as well (over SPI) and shown that the magnetometer data can be utilised quite nicely for apogee detection, likely very useful at higher altitudes.

These two write ups I've done show you the sort of data and performance I've gotten from the system. I plan to fly it to higher altitudes soon, highest to date is only about 11kft.

https://drive.google.com/open?id=0B7tnRi_PndLeTUtuTXJ6cXBfckk

https://drive.google.com/open?id=0B7tnRi_PndLeeWFMWTdsZTRkeHM
 
We did two more test launches this weekend, both above 11K feet AGL (3" rocket w/K motors). Overall, both tests were successful and very informative, but we still have a few issues to iron out.

The most serious issue is a reset of the ESP32 that appears to be associated with g-force. We have done dozens of “drone flights” with no resets, but 3 of 4 of our live flights have caused the ESP32 to reset (reboot and recover). One flight reset just seconds after apogee (16g+ ejection force), one reset happened on impact with the ground (normal descent of ~25fps), and one reset with the ejection of the main (also high g's). We replaced our accelerometer and barometer with a fusion board, between flights 2 and 3, thinking the MPU9250 might be the issue. So that leaves the ESP32, GPS, SD card, radio, and batteries — or code. I suspect it is also possible that >16g is causing some type of overflow in the underlying libraries and a crash. Question 1: Anyone know an easy or quick way to generate >16g force for at home testing?

On each of the four flights our GPS (ublox m8) regained lock immediately at apogee. This was very encouraging. But, in one case, after regaining the GPS it spit out negative altitude numbers for about 10 seconds and then corrected itself. Question 2: Is it normal to get back erroneous GPS data after regaining lock at the top?

On a long-burn motor, we noticed the rocket tilted about 75 degrees while still ascending at the top, for about 5 seconds. It was a windy day at the rocket would be at about 13K feet ASL. This challenged our thinking that tilt was the best indicator of apogee. In this case, tilt would have been fine, as the vehicle was not ascending that fast, but it looks like we’ll need to track acceleration/velocity and tilt.

Craig, thanks for sending along your write-up and components. Also to Sparky. I got my hands on a new Teensie 4.0, so now I am thinking about a version 3 of my build. The Teensie 4 board is amazing fast. So, I am also reassessing all the other components in the stack. I am very satisfied with the GPS (ublox neo m8), but I’d be interested in any feedback on the following:

- Accelerometer: Any solutions out there for >16g
- Barometer: what works to the lowest bar? (highest altitude) - that MS5607 looks good, but ?
- SD reader: most of these are just direct wire to the card, but how to shave milliseconds or microseconds? I could use a combo flash memory and SD.
- Radios: I’m using 2W 70cm serial TTY right now. They have been good, but also looking at LoRa. What is the advantage of LoRa in the 70cm band?

Thanks,

Mike
 
Hi Mike,

What type and form factor batteries are you using? I have seen in the past that some batteries really don't like high accelerations and output drops during the pulse. Do you have any hold up capacitance on the supply?

Regarding the sensor libraries causing a crash, this is easy to avoid in your firmware, simply by limiting the response time for the I2C / SPI interaction and then bugging out. I must say, typically I write my own interface libraries so this sort of functionality is included.

Regarding memory, to you really need more than 16MBytes? This is how much you can easily get in an SOIC8 or similar flash memory chip. The through put in just SPI mode is really fast and in QSPI much faster indeed.

Craig
 
Are you running a crystal or a MEMS-based oscillator module? The newer MEMS units are orders of magnitude more resilient to shock and vibrations loads compared to the crystal elements. Accelerations can damage the crystal and/or drag the frequency around.

As for force for making a test acceleration, just use F=mA and work out a distance to decelerate the accelerometer module over to generate the required level of decell. Some foam of some sort for the module to fall onto would probably work well. Add height to increase deceleration. Alternatively just drop it from increasing heights till you achieve the required peak value.
 
So, I am also reassessing all the other components in the stack. I am very satisfied with the GPS (ublox neo m8), but I’d be interested in any feedback on the following:

- Accelerometer: Any solutions out there for >16g

A few weeks ago, I came across this high-g accelerometer on the Adafruit web site:
https://www.adafruit.com/product/1413

I have not used (or even purchased) this sensor, but would be interested in feedback if any others have used it.

--MARK
 
The ADXL377 is an analog sensor. When used with an AVR (most traditional Arduinos) with an 10bit ADC, will be limited. Depending on the layout, it might also be more susceptible to EMI from the radio. Consider it's digital sibling, the ADXL375 or the alternative H3LIS331DL (more range, but less resolution) instead.

On the other hand, the ADXL377 is probably great if you want to connect it to an oscilloscope for various ground tests. 've considered it for getting data on impact or shock tests of components like switches.

Reinhard
 
On the other hand, the ADXL377 is probably great if you want to connect it to an oscilloscope for various ground tests. 've considered it for getting data on impact or shock tests of components like switches.

Probably doesn't have enough bandwidth. An Endevco 2250A piezo accel would be a better (but expensive) choice.
 
I use the ADXL377 and ADS1115 combo and it seems to work well. I sample it at about 1000 samples per second and they both track very well. The ADXL377 & ADS1115 combo is a bit noisier than the digital LSM303, but not that bad. See the chart below. The blue line is the LSM303, the red line the ADXL377 & ADS1115 combo, and the green line is a 10-point moving average of the ADXL377 & ADS1115 combo.

Acceleration LSM303 ADXL377.jpg

I'm now trying to eliminate the ADS1115 and use the Teensy3.5 ADC to do the job. I haven't cracked the nut yet.
 
A comment regarding oscillator/crystal vulnerabilities due to high g. In all my rocketry electronics designs I stick with internal RC oscillators since these are pretty much immune to these issues. The loss in accuracy is inconsequential I think and considering the improvement in robustness then its a no-brainer for me.
 
Back
Top