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.
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.
In the spectrometers I design I sometimes use RC oscillators in the various modules. They can be trimmed to within about +/-2% (for the ATMega328) at the factory and if that is sufficient then it makes sense to use. Other modules require more accuracy and I am now switching to MEMS oscillators for newer designs.
 
Thanks for all the great feedback. I received the Teensy 4.0 and have been putting it through some tests. It is so crazy fast. I have a short program that just increments a counter and checks for 1000ms timer to display a count. When I run it on the Teensy 4.0 I get 8,109,923 increments a second (wow!). On the ESP if I run it straight up on one core I get 763,000. On both cores and then added together, I get 1,364,624. So, for my purposes, the new Teensy is 6X faster than the ESP32 in a much smaller package. That said, I really like the ESP32's dual core framework, so I can do sampling on one core and housekeeping (logging, transmitting, etc) on the other core without worrying about single-threaded delays impacting sampling.

I ordered a bunch of components to test and trial. I ordered the 200g accelerometers ADXL377 and the ADXL375. I might run one in addition to what I have today, just to capture and log the extremes. That Endevco 2250A is insanely expensive ($750), so it will wait.

I also ordered some QSPI memory to compare memory logging vs. SD card. It is possible I'd use both with launch logging to memory and then dumping to SD later for convenience. These chips get big, up to 128Mb, so I am excited to try them out.

On the reset issue, I also suspect a power glitch with batteries or the main switch. We did not have a cap on VCC, but we do now. That was a big oversight. The batteries are two Lithium Ion (3.7v) cells. We had swelling on one of the cells in high heat (127 degrees), so they could also be suspect. We also were not using a key switch, but instead a small inset push button spring switch. It is plausible that 16g+ could have momentarily opened the switch.

The oscillator/crystal discussion is interesting. The Teensy and ESP32 both have internal and external oscillators/crystals. How would I go about disabling the external 24hz crystal on the T4.0? Replace it with an RC oscillator?

-Mike
 
I did a bunch of tuning on the accelerometer and on logging today. I found a configuration I like that gives me a maximum log rate to SD of 1500 times a second. That's a full csv line of data constructed and written at 1500 Hz on one core of the ESP32. I'm using an SPI SD module and not SD/MMC. The open/close of a file takes the longest (up to 30ms for open, 20ms for close), but writing a line is < 1ms. The downside of continuous writing w/o closing is if there is a fault or anomaly and the file hasn't closed you lose all the data. So, my new logging routine closes and opens the file every 1000ms to ensure the most loss is 1 second of data.

With my accelerometer rate cranked up to 1000hz and sampling >1000hz, I started dropping the package from 20 feet high to see if I could get >16g. After a half dozen attempts, I only hit 15.5gs. So, I'll either need to rig an ejection test in the backyard or go find a high bridge.
 
On my Teensy 3.6 logger I skipped using a FAT file system and just have 32MB blocks of data. I write data to that continuously in a loop. (A bit more than 2 minutes.) When launch is detected that file position is recorded. Writing continues but stops leaving several seconds of pre-launch data.

You can do something similar even with a FAT file system. Pre-allocate the entire file and then write it in a loop.
 
Yeah, I looked at a few different ways to loop to minimize storage, but still capture the launch in high resolution. I actually prefer CSV FAT files on the SD, because it is so convenient to swap between the rocket and a laptop w/Excel for graphing and analysis. I’m also logging to 3-4 other files (gps, radio, etc). What I settled on was a two file system for the high resolution logging. I toggle between logA.txt and logB.txt. If I’m at full resolution I’m logging 1Mb/sec. So, after 20 seconds I flip the file name, delete the old file, and start logging to the second file. If we launch then that second file becomes the primary and the first log file has the previous 20 seconds. The switch takes about 50ms, but that’s only a .25% chance of bad timing with launch.

The other thing I’ve found is that the speed of the SD card really matters. I tested four SD cards today and write Times were 3X slower on the slowest compared to the fastest with SD Fat.
 
I got the 200G accelerometer board from Adafruit (ADXL377). This is the analog version. I've also ordered the digital version (ADXL375 noted above), but it has not arrived. I hooked it up to my rig today on the ESP32. It has a +200G to -200G range on each X,Y,Z axis, so on the ESP32 with ADC it is a value range of 0 to 4096. That means each G should calibrate to around 10, only providing a resolution of .1G. On initial bench testing I found it to be noisy, bouncing around about 3-4 points, even with samples/averaging of about 30. This won't be your precision Accelerometer :) In theory, a value of 2048 would be zero (no gravity), but in practice each unit is different. Analog on the ESP32 is also a mess, so calibration requires a lot of work.

After figuring out the calibration values for zero and gravity, I did a few drop tests from 15 feet with both of my accelerometers logging >800 times/second. My 16G accelerometer maxes out around 15.38G (gravity removed).

On the first drop test, I left about 6 inches clearance to the tile floor below. Using nylon line stretched and tied tight, it turns out I needed about 6.5 inches, so the bottom of the rig hit the tile hard. On that test I got a recording of 67G and the max of 15.3G on the other. On the second test, I used shorter line, but gave it a good shove. The second test recorded 96G's on the big accelerometer. Below are graphs of both tests. The 16G unit is an MPU9250 in an EM7180 package with sensor fusion. For this test I'm just looking at the Z axis on both. The 16G is highly precise within its range and sampling around 800hz.

The odd thing about the ADXL377 is that it does not report negative G's very well. In some cases not at all. The analog values should drop below the zero value, but they don't or rarely do.

I'll do a bit more testing with this one, but I'm more interested in how the digital version responds. At best, this one could be used to gauge max G's during flight, separation, etc. I am suspect of the accuracy (highs and lows), so will need to do more testing.

Screen Shot 2019-08-24 at 7.10.54 PM.png


Screen Shot 2019-08-24 at 7.10.07 PM.png
 
I looked at the ESP32 ADC documentation and wasn't impressed with the specifications or the documentation. The linearity was poor and lots of useful information was missing. Things like sampling time, input impedance, and sampling capacitance. ADC noise isn't mentioned except to recommend adding external capacitance and average samples.

You need to know those things to see if your sensor is compatible with the ADC input or if you need a buffer amp to lower the impedance.

Other problems are a not very accurate voltage reference (hope that it is at least stable!) and the need to attenuate the input signal if it exceeds Vref. (about 1.1V) Does attenuation interact with the output impedance of the sensor? As an added bonus, using the 11dB attenuation setting (to work with a 3.3V sensor) you get worse linearity at the upper end.

Better than no ADC I suppose.
 
I use the ADXL377 in conjunction with the ADS1115 and get great results. Add a 10-point moving average on the data stream and its better than the LSM303 16G 12-bit digital accelerometer.

I now am using the ADC from the Teensy3.5 to read the ADXL377. Not as good as the ADS1115, but it looks good enough so far. Flight testing will tell.
 
Make sure you have a capacitor on the ADC input pin on your microcontroller. Most ADCs benefit greatly from a little capacitance there. Your averaging will do the rest and provide you decent resolution.
 
Yes, great point on the capacitors. The Adafruit board has them and I found out this weekend how important they are. The Teensy3.5 ADC can sample very rapidly, which will drain the capacitor and give erroneous readings. I found I could exceed the 500hz max bandwidth, but after about 1500hz the readings start to degrade significantly. That’s probably technique dependent.
 
The capacitors are less than optimal way of dealing with the problem. Which is the result of needing to charge the internal sample and hold capacitor. The more usual way is to add a buffer amp. As a bonus with the buffer amp it is then easier to add a better presample filter.
 
For any serious ADC work we do we add the buffer amp and an RC filter it into the ADC pin. The earlier part of the analog chain is kept with very high frequency response, with the system frequency response determined by the last RC before the ADC. Works a treat...
 
I got tired of soldering breadboards, so I thought I'd try a custom PCB. I downloaded EasyEDA for the Mac (free) and whacked out the schematic in about an hour. I needed to define/create a few of my own components, since I am using a lot of stock boards (the ESP32, SD card, EM7138, etc) but once I figured out how to do one, the others only took a few minutes each. After doing the schematic, the board layout took another hour or so, although the connection routing was all auto-magical. I was surprised at how easy it was to design and then layout. The software allows you to order the board directly in the app. The custom board was only $1.34, but a minimum order of ten, so $13.40. I chose expedited DHL shipping from China for another $8, so all total about $22 for 10 boards -- albeit I only need one. I placed the order last Sunday and had them in hand in California today (5 days later). It would have taken me a minimum of 2-3 hours to solder a breadboard with all the connections. I won't be doing that again. This was super easy and fast.

IMG_8892.JPG
 
I got the ADXL375 200G digital accelerometer and I've been playing with it. I want to run it on I2C but I couldn't find an I2C library for it, so I ended up hacking together my own. Now I've got it on the same I2C bus with my 16G accel on a EM7180 package. The EM7180 is a lot more precise and has onboard filters, so the lines are really smooth. Reading the ADXL raw is pretty noisy, but it tracks really close to the 16G accelerometer. I only want the ADXL to catch the big spikes over 16G, so noise is ok. I've only done shake tests. Now I need to go drop it off the roof to see what kind of G's I can get. The graph below shows the Z axis of both reading and logging at 500Hz. The blue is the 200G and orange the 16G. The peak on this test was only about 4g's.

Screen Shot 2019-09-08 at 10.07.19 PM.png
 
The capacitors are less than optimal way of dealing with the problem. Which is the result of needing to charge the internal sample and hold capacitor. The more usual way is to add a buffer amp. As a bonus with the buffer amp it is then easier to add a better presample filter.

True, but it is dependent on the situation. Our strategy in my earlier post is quite applicable to most situations. The earlier amplifiers, including PGA, provide the opamp, RC limits the overall response. Buffers are mostly not needed. We have another design team we collaborate with that also has the buffer-amp dogma. We are convincing them across to our side.

We spend about $4million per year just on op-amps, so keeping the numbers down helps ;).
 
I'm not surprised that you get a "better" graph out of the lower-G accelerometer on a 4G test... the steps are smaller, so the filtered output will be cleaner. That's a problem with using a high-G accelerometer in a low-G application... the resolution dictates that your steps will be higher, so it will look noisier. Of course, once you hit 17G all bets are off with the low-G accelerometer, so some altimeters use both a low-G 3-axis accelerometer and a high-G z-axis accelerometer. You use the low-G one for calibration on the ground, and in flight you use the z-axis high-G accelerometer along with the low-G for x-y readings.
 
How about filtering the data by normally using the lower rated device and then take the feed from the high-g device when limits are exceeded? You may need to watch out for discontinuities when blending the two and have some sanity checks in place on the data.
 
How about filtering the data by normally using the lower rated device and then take the feed from the high-g device when limits are exceeded? You may need to watch out for discontinuities when blending the two and have some sanity checks in place on the data.

That is my plan. I want to fly with both. I'll use the 16G for regular flight monitoring (tilt, apogee, etc), but I'll also log the 200G x,y,z, so I can see the extremes in the post flight data. The processor I'm using can easily read both at 500Hz (likely 3X faster) and log to SD card, so there is not much overhead.
 
I've not read all the post from top to bottom but coming from a scratch building drone background there are a lot of drone flight computers on the market that are cheap and have inputs for GPS telemetry etc. Might be worth looking at a few of those.
 
The MTK3339 was mentioned early in this thread, has anyone flow these in a rocket and got good results?

A few flights of our RocTrak board that uses these has shown the altitude to be unreliable with lat and long to be pretty good, even in Avionics mode.

Wanted to get some feedback from others before we commit to another GPS module (probably one from Ublox)

details of the project here: RocTrak thread
 
Some people claim the MTK works all right. I've had bad experiences and will never use them again; no reason not to use Ublox IMHO.
 
Some people claim the MTK works all right. I've had bad experiences and will never use them again; no reason not to use Ublox IMHO.
Thanks mikec, Performance on the ground seems very good but in the air lock seems to be lost earlier and altitude upon landing is often at least 1000ft off and hence causes me to lose confidence in altitude at other times in the flight....
 
I haven't updated this thread in a long time, but my son and I continue to plod along iterating and updating our telemetry flight computer project. My plan has always been to open source this for students and hobbyists, but no matter how much progress we make, it always seems like it is in a massive state of work in progress and it keeps getting more complex -- defeating our original "cheap and easy" intent. Eventually, we'll reach a point where we can take a snapshot and share a version.

As a recap... we have a flight computer that is based on an dual-core ESP32, running Arduino code, that integrates a GPS, IMU, 200G accelerometer, barometer, SD logging, and transmits (bi-directionally) to a handheld base using high power serial radios. It has other bells and whistles, like hall sensors to detect fore/aft separation and remotely turns on/off cameras. At this point, we are just using it for flight data, event data, and tracking, but the next step is to also use it for staging and firing events.

Originally, we had a handheld Arduino with a TFT display and serial radio, acting as the base station. This served us well -- with a pretty common code base between the rocket and the base, but in the last year we decided to port the base application to an iPad mini to vastly improve the tracking, weight, and overall experience. Surprisingly, creating the app on the iPad (using iOS Swift) turned out to be much easier and far more powerful than we thought. We interface the iPad to the serial radio/modem using a Redpark serial cable and we mount the whole thing on a pistol-grip plate with a Yagi antenna. We've tested it to 14 miles line of sight and flown it dozens of times. Using the iPad gave us native access to the device GPS, magnetometer, maps, voice synthesizer, and dozens of other bells and whistles that you can't get using an Arduino and LCD display. But... at a cost of the iPad mini and the $100/year developer fee to Apple, so not the low cost option.

That said, the new version on the iPad has been amazing and fun to work with. It has been simple to add things like spoken warnings if the rocket is descending directly overhead or spoken warnings if the descent air speed is too fast (e.g., no drogue). We get to see all the telemetry data live, including the direction bearing and horizon angle, and distance, along with the speed. Additional screens on the iPad show the rocket location(s) on a satellite map, allow us to send the rocket commands, see radio streaming data, view log files real-time, etc.

This project for us has gone way beyond our original "quick and easy" for students, but my lesson learned is that if I had to do it again from scratch I would have used an iPad or Android tablet (or phone) to as the base station. There is so much power and capability in the device and very little incremental effort, once you master how to code "hello world" in the device IDE.

We are going to keep iterating and improving it, but in the meantime, here are some photos:

Here is where we started - the old base station:
IMG_5535.jpg

Here is the current rocket board in a 3" package (board, radio, battery, GPS):
IMG_5532.JPG

Here is the new iPad "base station":
IMG_5364.JPG IMG_5365.JPG

IMG_5558.jpg IMG_5569.jpg

screen shots:

IMG_5753.JPG IMG_5568.jpg

And here is a quick one minute video overview of the base station screens:

 

Attachments

  • IMG_5754.JPG
    IMG_5754.JPG
    148.1 KB · Views: 23
We are working with a university team to assist with their telemetry solution, so we finally took the time to create a snapshot of our vehicle board code and iPad code and put it up in GitHub.

For anyone else crazy enough to jump into the deep end with their own telemetry project, here is the link to our solution and source code:

https://github.com/AllDigital33/RocketTalk
 
Glad to see that I am not the only one going opensource. This is the best approach to get improvements.
 
Back
Top