Quantcast

Rocket Talk - Arduino-based radio flight data

The Rocketry Forum

Help Support The Rocketry Forum:

OverTheTop

Well-Known Member
TRF Supporter
Joined
Jul 10, 2007
Messages
4,310
Reaction score
1,516
Location
Melbourne Australia
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.
 

AllDigital

Well-Known Member
Joined
Jun 14, 2013
Messages
190
Reaction score
95
Location
SoCal
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
 

AllDigital

Well-Known Member
Joined
Jun 14, 2013
Messages
190
Reaction score
95
Location
SoCal
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.
 

UhClem

Well-Known Member
Joined
Feb 6, 2009
Messages
1,641
Reaction score
169
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.
 

AllDigital

Well-Known Member
Joined
Jun 14, 2013
Messages
190
Reaction score
95
Location
SoCal
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.
 

AllDigital

Well-Known Member
Joined
Jun 14, 2013
Messages
190
Reaction score
95
Location
SoCal
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
 

UhClem

Well-Known Member
Joined
Feb 6, 2009
Messages
1,641
Reaction score
169
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.
 

SparkyVTFlyer

Senior Member
TRF Supporter
Joined
Feb 8, 2009
Messages
169
Reaction score
17
Location
Yorktown, VA
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.
 

OverTheTop

Well-Known Member
TRF Supporter
Joined
Jul 10, 2007
Messages
4,310
Reaction score
1,516
Location
Melbourne Australia
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.
 

SparkyVTFlyer

Senior Member
TRF Supporter
Joined
Feb 8, 2009
Messages
169
Reaction score
17
Location
Yorktown, VA
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.
 

UhClem

Well-Known Member
Joined
Feb 6, 2009
Messages
1,641
Reaction score
169
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.
 

OverTheTop

Well-Known Member
TRF Supporter
Joined
Jul 10, 2007
Messages
4,310
Reaction score
1,516
Location
Melbourne Australia
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...
 

AllDigital

Well-Known Member
Joined
Jun 14, 2013
Messages
190
Reaction score
95
Location
SoCal
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
 

AllDigital

Well-Known Member
Joined
Jun 14, 2013
Messages
190
Reaction score
95
Location
SoCal
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
 

OverTheTop

Well-Known Member
TRF Supporter
Joined
Jul 10, 2007
Messages
4,310
Reaction score
1,516
Location
Melbourne Australia
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 ;).
 

cerving

Owner, Eggtimer Rocketry
TRF Sponsor
TRF Supporter
Joined
Feb 3, 2012
Messages
3,887
Reaction score
1,084
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.
 

OverTheTop

Well-Known Member
TRF Supporter
Joined
Jul 10, 2007
Messages
4,310
Reaction score
1,516
Location
Melbourne Australia
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.
 

AllDigital

Well-Known Member
Joined
Jun 14, 2013
Messages
190
Reaction score
95
Location
SoCal
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.
 

Robz82

New Member
Joined
Oct 1, 2019
Messages
4
Reaction score
2
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.
 

strud

Active Member
Joined
Jul 1, 2019
Messages
26
Reaction score
36
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
 

mikec

Well-Known Member
Joined
May 9, 2009
Messages
2,423
Reaction score
337
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.
 

strud

Active Member
Joined
Jul 1, 2019
Messages
26
Reaction score
36
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....
 

Latest posts

Top