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.
Nice project. Good luck.

A few comments:
2) Radios - I have my Amateur Radio license, but good (high wattage) options are still limited. Small TTY serial radios in the 2M or 70cm bands around 2W would be ideal.

Be very aware of the increasing power interfering with other components on the hardware if you use the higher power transmitters. I have noticed much slower GPS lock when I dialed the power up to 100mW on an experimental plug and play GPS/telemetry system. At times it will not obtain fix at all. That indicates that the front end is being swamped by the local telemetry Tx. I dialed the power back down and the situation improved markedly, although it still would have been affecting the time to lock and possibly the DOP.

Also, I have had an on-pad deployment event occur when some telemetry keyed up a 1W transmitter. The RF got into the deployment electronics and triggered it as I walked away from the pad :(

I would suggest getting the telemetry antenna well away from the GPS if using higher power. If it were me I would probably run a skinny coax for the Tx (or you could do something with the GPS antenna/receiver) to get the separation up.

Here is a suggestion also. Please provide some extra channels for inputs from other electronics. The TeleMega I use has four extra inputs and I can use them to monitor the battery and pyro voltages on my other altimeters. That means there is no guessing when it is on the pad if there is enough juice for the flight, especially after an unplanned extended pad time. Also provides direct indication of nosecone separation :).
 
Ditto that on rf interference . I had 2 rockets deploy on the launch pad before I realized what was happening. Also, one rocket deployed on ascent. Some electronics are more resistant to rf effects than others. The egg timer flight computer is quite resistant to external rf effects whereas I've seen a situation where two adept 22's were shut down by a Garmin dog tracker that puts out 2 watts on the.150 mhz MURS frequencies. The result was a ballistic flight in a very large rocket that made the flyer rather unhappy.
The aim 2 usb USB altimeter plainly states in the instructions that the altimeter does not work well in rf environments.

I will suggest that if anyone doesn't know whether or not their flight electronics work in rf fields, either ask the manufacturer or ask your buddies and fly the same devices. The alternative is all up testing with contained ematches and let everything run for 30 minutes to an hour and see what happens. If the matches don't blow or the altimeters don't reset one should be in good shape to fly with a given tracker. Kurt
 
I had some time to tinker this weekend and I've got a few updates.

GPS: I got a UBLOX NEO-M8N (https://a.co/iopgwIs) GPS unit and it is rock solid. It took a lot of work to figure out how to configure it with Arduino code and parse everything I need, but it is a great little GPS loaded with capabilities. I like that I can switch modes dynamically to handle launch (up to 4g) vs. descent or landing. After increasing the baud rate, the sample rate, and filtering all but two NMEA codes, I got the read timing down to about 80ms. It is so good it locks with 12 satellites inside my house, where with my other GPS units I needed to take them outside to lock. The manual for the NEO-M8N is huge and verbose, but isn't always clear regarding the payload values for programing. The trick was to use the Windows software to create the configuration and see the messages (payload) and then copy them into the Arduino code. I also ended up writing my own parser. I tried four different NMEA parsers, but none of them had every field I wanted and/or some just didn't work. The NMEA parser really isn't that much code.

Radios: I got my new radios programmed and working on the bench. They also seem solid, but will need a lot more testing. They are serial TTY and work great with Arduinos. Once I am further along, I'm going to do a 5mi, 10mi, and 15mi line of sight test using my son in a lawn chair and the local mountains for height. If anyone has a favorite hand-held Yagi antenna in the 433 Mhz range let me know.

Display: I put my 5" Adafruit 800x480 display through a lot of testing and I really like it. It has an additional current setting that really pumps up the brightness, albeit at a total current draw of 700ma. I've got lots of room for batteries, so I'm not too worried about the extra power required. I did a quick layout of the telemetry screen and it looks good. The hardware controller driving the display makes refresh almost instant -- something you don't usually see with an Arduino. My hand-held base station is also using a Arduino DUE, so there is lot of extra compute power.

Here is a photo of the display with a mock-up of the telemetry screen:

IMG_5478.jpg
 
Mike,

You're making great progress, and I'm really jealous of your skills. I'd like to recommend the Arrow Antenna model 440-5, a five element handheld Yagi for 433 Mhz. The antennas are named for the aluminum archery shafts that they're made from. They compact down to a very small size for transport, and then literally screw together in minutes. They're lightweight, rugged, and just work.

I use the 7 element model with my Big Red Bee 433 Mhz tracker, where a bit more gain can be required sometimes.

https://arrowantennas.com/arrowii/440-5ii.html
 
A patch antenna on the ground is probably your best bet for extended range telemetry, maybe switching over to a yagi if it gets REALLY high and you know which way it's going. Yagi's have a very narrow beamwidth, so you don't get any signal if you're not pointing directly at the object of interest. A patch antenna is still directional, but has a comparatively wider beamwidth, so if you're off +/- 30 degrees you'll typically be OK. Of course, with winds aloft they have a way of drifting off in directions that you don't anticipate...
 
That is why I recommended a four element Arrow Yagi. The pattern of the antenna is directional, but not super narrow. I actually use a 7 element Yagi, and have no trouble with losing the signal while the rocket is in flight. It just takes a little practice.

The best analogy for what we're doing is probably low-earth orbit satellites, which can move very quickly across the sky, and rapidly change polarization. Rocketeers experience loss of signal (LOS) frequently and I think many attribute this to the transmitter being outside the pattern of the receiving antenna but in reality they're experiencing a change in the polarization of the signal which can cause huge swings in signal strength.

The Arrow Antennas are very popular with amateurs who operate low-earth orbit satellites. Patch antennas--not so much. Patch antennas do have the advantage of being inexpensive--and they leave your hands free to do other things.

YMMV. It would be a fun experiment to test several receive antennas using LPR.
 
I’ve just started playing with ESP8266 based controllers. These are getting more and more common and have a very small (Arduino Nano sizes) footprint.

These are mostly Arduino compatible (there are a few quirks but most Arduino code just works). You can use Lua or Node with them too. These give you MB instead of KB or RAM, Wifi, Bluetooth, and enough onboard flash for decent logging or to play the “Highway to the Danger Zone” MP3 right before takeoff. The power draw is reasonable and they’re up to an order of magnitude faster.

Love the fact that you don’t need external SD storage and with Wifi, you can interface with them cable-free using standard protocols from ~hundreds of feet.

I haven’t launched one yet though.




Sent from my iPhone using Rocketry Forum
 
Mike,

Two weeks ago I flew my NEO-M8N in my Teensy3.5 based project. I configured it to the 4G settings via code, but found that it wasn't stable. I got a good GPS fix and great data all the way to apogee, but shortly after apogee the unit lost the GPS fix and never got it back......for the rest of the entire day. It never regained a GPS fix on either of the two subsequent flights. I ended up doing RDF fox-hunting with my backup system for all three flights. I never figured out what happened, but when I restored the factory defaults, the unit immediately perked back up.

As a result, I recommend two things:

1) Always have a backup tracker that is simple and reliable
2) In your code, constantly check for the GPS fix, and if you lose it for an unacceptable amount of flight time, then reset to the factory settings.
 
I decided to get the base station fully assembled and working, so that testing the vehicle hardware/software would be easier. The hand-held base station hardware turned out to be a lot more work than I anticipated, but I am very happy with how it is coming along. The Arduino DUE is going to be pushed to the max to hold all the code for the functionality I want. So far, I've got everything together, except a smaller arduino nano/mp3 player for the voice (built, but not installed) and a magnetometer for a compass bearing.

I ran into a snag between the 5" Adafruit TFT display and the SD card. I LOVE the display so far, but the controller for it does not allow for multiple SPI devices without a special buffering chip in between (buffer chip ordered). So I can't use the SD card on the base yet. I want to log all radio data to SD card at the base station and higher resolution logging on the rocket.

Using a magnetometer to get a simple compass heading is also turning into a major project. I need a compass heading, combined with my local base GPS, for accurate tracking after the rocket has landed. I tried a number of basic 3-axis (HMC5883) modules, but they are all very unreliable, due to tilt. So, I am now playing with a 9-axis MPU9250 to get tilt adjusted headings. It seems like there would be better off-the-shelf examples of this, but none so far.

Sparky, I am not sure what happened to your NEO-M8N. Let me know if you figure it out. I am now using two of them. One on the rocket and one on the base station. I really like them so far, but I haven't flown one yet. I wonder if an ejection charge at Apogee did some type of damage to the unit or antenna? It seems odd that defaulting settings would correct it. I am not burning in any of my settings. Each time the unit powers down the settings go to default and then I set them on power up (arduino code) and dynamically during the flight. Having a radio command to reboot everything might be a good idea, but I'm not there yet.

Here a few progress photos of the base unit:

IMG_5535.jpg

IMG_5537.jpg

IMG_5538.jpg
 
I've been putting my radios through some basic tests to get them ready for a long distance test "on top of the mountain". I cranked the output up to the max (2W / 33 dBm) and things got messy, as raised in earlier posts. In the base station a single transmit (50Kb packet) is generally ok, but for testing purposes I ran a constant cycle of transmitting 50Kb every 500-1000 ms. The first issue I ran into was power. I'm running a lot of components, including the radio, through a single 5v step down (buck) to go from a 7.4v (8.4) lipo battery to 5v. When the radio is cranked up its average current is probably around 900ma, but the spikes were pulsing everything else connected. I gave the radio its own isolated regulator and now it is happy. The buck circuit I'm using is here: https://a.co/dBpB8if It says it is rated at 5A, but when the radio is transmitting there is significant voltage drop and visible pulsing of other components (drawing less than 500ma) that are connected.

The bigger issue with the radios turns out to be the radio transmission. In the constant transmit mode (every 500-1000ms) the nearby Arduino and display get their brains scrambled, freeze, reset, think pins are high or low, or run unelated code. That is not good, but as previously raised in this thread, not completely unexpected with high power radios. The constant transmission also hoses the GPS reception, although at a slower 3 second Tx intervals the GPS seems to be Ok. On the base station, if I move the antenna at least 8-10" from the box then all is good and there is no interference with the CPU or other components. This is very manageable on the base station, since I will likely use an external Yagi or patch antenna, but for the vehicle it means getting the antenna a safe distance away and thoroughly testing the altimeters under all possible scenarios. For smaller rockets and lower altitude the power levels can easily be dialed down and larger rockets will have more room to relocate antennas, so I'm optimistic the power to interference can be managed.

Anyone have suggestions for the rocket antenna? I know options will vary considerably with the size of the rocket, separation points, etc. Has anyone done an external dipole on the outside of the airframe? I'm thinking of using copper tape directly on the outside airframe spec'd to frequency, but I haven't given the design much thought. My default was to use a simple whip antenna and relocate it far from the electronics and/or relocate the entire radio.
 
"It says it is rated at 5A"

The data sheet for the LM2596 says it is rated at 3A not 5A and needs a heat sink to handle that much current.

"The TO-220 package requires a heat sink under most conditions.
The size of the heat sink depends on the input voltage, the output
voltage, the load current and the ambient temperature."

Terry

Oops. I see now that this module no longer uses the LM2596 regulator. Never mind.
 
The bigger issue with the radios turns out to be the radio transmission. In the constant transmit mode (every 500-1000ms) the nearby Arduino and display get their brains scrambled, freeze, reset, think pins are high or low, or run unelated code.

Welcome to internal EMC (electromagnetic compatibility) issues :). I have been known to do this for a day job and sometimes solving them can be "interesting" shall we say.

Distance is your friend, as you already know. A nice solid ground-plane (maybe some unetched PCB material) between your electronics and your Tx will help. Toroidal ferrites on the power supplies and communicatoins leads to each module can also help keep the EMC worms at bay. You could even make your avionics sled out of PCB material :wink:

I suspect the high Tx power causes jitter on the logic in the GPS, interfering with the correlators and of course the final position solution. It could desensitise the front end as well, but I suspect this is less of a problem. Not sure though. Distance from GPS antenna to the RF will help, as will keeping it in an antinode of the Tx antenna radiation pattern to keep the field strength down.

Capacitive coupling between wires also couples signals unintentionally. If it were me I would probably put the regulator for the Tx close to the Tx, to try to limit the wires coupling RF out of the transmitter to other places. Try to keep the wiring for the Tx separated from the other wiring where possible. Toroid around the comms cable from the 'puter to the Tx might help also.

Share and enjoy.
 
I was messing with 3DR radios and found out if I laid the GPS antenna/chipset on top of the 3DR transceiver as if I was going to shrink wrap them together, the signal strength of the incoming GPS data dropped quite a bit. Put the GPS 4 inches away from the radio and it increased back to a healthy baseline. Thing I don't like about the 3DR is the two way requirement. I never got around to testing a one way setup to see if it got better range. The initial enticing promise was to have a $35.00 GPS tracker which to me at that price range is nearly disposable if something goes wrong. The disadvantage was having to dink like crazy with the software and the fact I couldn't get my Ham callsign into one of the NMEA strings to be legal on 70cm. I was able to get a "Comment" string in there but couldn't get the letters/number to go out. Also the Chinese lied like heck about the power output of their units. A 1 watt or more power output setup cost quite a bit and as much or more than some of the dedicated rocket trackers out there so that threw ice water and the kibosh on the whole experiment for me.

Was even able to modify a 3DR receiver with a bluetooth module and I could get the setup to display positions with the Android program "GPS Rocket Locator". Was even able to use a combined GPS/GNSS GPS chipset and get much better positioning with GPS Rocket Locator as is going to be done with the new Featherweight project. I just ran the data strings through the "B/T GPS" Android program, allowed mock GPS locations in the setup of my device and the blue dot became the rocket (instead of the local position) and I paired up a cheap external B/T GPS I could velcro to a ball cap and have "GPS Rocket Locator" pair with it as the "rocket" so the red pushpin would now be the local location. It was reversed from stock. I found GPSRL couldn't decode the combined GPS/GNSS strings "natively" but could handle them when run through the "B/T GPS" program.


Here are some threads: https://www.rocketryforum.com/showt...etry-discussion-and-help&highlight=3DR+radios

https://www.rocketryforum.com/showthread.php?141685-25-GPS-Solution

Yeah, I spent a lot of time with this stuff and because of that, I was able to find some commonalities so I could combine programs. If someone could figure out how to get a ham callsign into the NMEA strings with the "cheap" GPS
chipsets that have limited programming ability that would help along with whether or not a one way link can be used/setup with a 3DR radio and allow for an increase in range. Cripes, a 3DR receiver is so small that with a B/T
board connected to it, one could duct tape it to a 10 foot or more pole and can get it up in the air for better receive capability. Kurt Savegnago
 
Last edited:
I've been spending a lot of time on the radios. After figuring out how to isolate the radio from the Arduino and other electronics, I did my first long distance radio test about a week ago. The first test was simple without a lot of prep, but the results were bad. At 4 miles line-of-sight between mountain/hills I was only able to get about 50% of my sentances transmitted and received. So, I went back to the shop and I have been aggressively working on antennas and a custom serial transmission protocol.

Antennas:
My first test was using an Arrow II 440-3 (3 element) Yagi on the base and a cheap 433 mhz whip on the rocket rig. The Yagi did good on the Tx/Rx side, but the cheap whip antenna could barely transmit. I tried to us an SWR meter with the serial transmitters, but the packets are so fast (even long continuous sentences) that my SWR meter couldn't get a real reading. So I used a HT tuned to my radio frequency (435.9Mhz) to check and tune the antennas. The Yagi was off quite a bit, but easy to get back to 1.0x SWR. The whip was worthless, so I started researching and building a few different options. The rocket antenna that seems the most efficient is an inverted vee dipole. On smaller rockets I'll try an external mount and larger rockets can go inside. I also tried a straight dipole (bad radiation alignment for a rocket) and a quarter wave ground plane. I got an inverted vee tuned to 1.01 SWR and the right impedance on my HT.

Software protocol:
Since this is arduino-based on both ends, I have 100% control over the messages, content, and serial protocol. The radios take care of packet integrity, confirming that the packets come from another radio with the same encrypted ID and buffering, but the radios don't do anything for signal loss or retries. So, I built into my arduino communication two "bulletproofing" additions. 1) Bursting messages. When I send a sentence (an event, GPS data, etc.) in either direction I can now burst the same message X number of times and the receiver will ignore anything it has already processed. For example, if I hit apogee and want to send altitude, GPS info, etc. I can rapid send the message 3 times increasing the likelihood that the receiver will get one of the three perfect. 2) Request Ack - For important messages I can require an acknowledgment be sent from the receiver and specify a number of retries if no ack is received. Retries happen every 5 seconds for X times.

In addition to the antennas and software, I lowered the radio baud rate from 9600 to 4800 to put more power behind each bit transmitted. I did another test this afternoon at 3 miles line-of-sight (ground/hill test) and I got 100% of the transmissions in both directions. In the next few days I'll test at ten miles. With 2 watts, the right antennas, the right protocol, and the right configuration, I'm pretty sure I can get ten miles.

Kurt, thanks for the reminder to put my call sign into my radio sentences. Luckily for me that is a simple add with control of the code on both ends. The 3DR radios look like they are just smaller versions of what I am using (100mw vs 2000mw). They will take as input any serial TTY signal. You can connect any serial GPS directly or you could put a tiny arduino nano in-between the GPS and the radio and hack the input and output as much as you want to get a call sign in the NMEA sentence.
 
Mike,

Your testing is fascinating, but I think you need to have realistic goals about transmission range. 4 Miles in mixed terrain on 433 MHz is about the absolute max for a link budget. A J-Pole antenna might be a better choice for the transmitter (rocket side). If you really feel like you're going to need 4 miles of range, then switching to 2 Meters probably makes more sense.

10 Miles? My immediate reaction to that kind of range need is that you shouldn't have flown the rocket at all. Perhaps for some really, really serious level 3 flights--but even then 2 Meters is the better choice, and probably you'd want/need redundant trackers.

But please don't let me discourage you. If you can figure out a way to make it work reliably, then we all benefit. My experience with RF though is pretty simple-- "Physics don't give a damn." If you want more range, you need a bigger antenna or more power, or both. For decades people have been trying to figure out a way to change that equation with modulation schemes. With the exception of Joe Taylor, I haven't seen anyone figure it out. Even then, it's hardly a modulation scheme that I'd want to trust life, limb, or the recovery of an expensive rocket on.

YMMV.

73,
 
My son and I went out this afternoon and did a "ten mile test". More specifically, it was 9.75 miles peak-to-peak with him on a hill at 1100' and me 9.75 miles away (across Orange County business/residential) at around 800' with good visibility between both peaks. I checked the frequency before we began and it sounded clear.

At ten miles we transmitted over 50 sentences in both directions. We got 100% of the messages we expected to receive on each side. I only got four malformed sentences and they were consistently with the same event and the same send condition -- A burst of the same message sent 6 times 50ms apart with ack request. That sequence seemed to always drop some packets in #6, although the first 5 were received fine and processed (only one gets processed). An overkill to send the same message six times in a row rapidly, but a good test.

Again, this is using 2w serial TTY radios on 70cm (435Mhz) at 4800 baud. The antennas used were the Arrow 440-3 on the base and a homemade inverted vee dipole on the rocket package. Both precision tuned to 1.01 SWR and 50 ohms.

Les, I hear your concern, but my experience with radios in open air conditions is more optimistic. A number of years ago, my son and I successfully launched and recovered three high altitude balloons to over 100K feet. We used 2 meter 2w APRS as the primary radio and got nearly 100% packet transmission. We also had a 1w 70cm beacon and, surprisingly, we were able to pick up the beacon about 50% of the time at 110K feet using a Yagi on the ground. Now, a rocket has a lot different profile, but I am optimistic we can get reliability at 50K feet with our current setup. Only real world testing on a rocket will tell us for sure.

The design point for this project is to support local student groups from USC, UCLA, and a dozen other schools that fly at FAR and Black Rock. These are L3, but mostly experimental. Having a cheap open source arduino option will keep them from lugging laptops all over the Mojave desert. FAR has a waiver to 50K feet and many projects go that high. I'm only concerned about vertical feet and not so much horizontal/ground distance -- although rockets ending up five miles away is not unheard of. The use of 70cm instead of 2M is for versatility. I think antenna options with 70cm can work better in a 3" rocket to a giant 10" rocket. For a bigger project the radios can easily be swapped out with no code change to 2M, higher wattage, or any other serial TTY transmitter. When I go to 100K feet at Black Rock I'll do more testing :)
 
Mike,

Congratulations on the test today. Unfortunately, it doesn't really address any of the concerns. A test on mountain peaks is really only testing line of sight. In theory, line of site transmission on 433 Mhz might be out to the horizon--20 or 30 miles. But that's kind of like the claims made on GMRS/FRS radios at Wal-Mart. One unit touts it's 18 mile range, while another brags about 20 miles. True enough, if you're testing mountain peak to mountain peak--but under mixed terrain, in real world conditions, you'll struggle to get a mile or more. It's just basic RF and physics.

What are the design objectives? Do you want to recover position data for the rocket during flight or is your primary concern in recovering the rocket itself?

A balloon at 100K has line-of-sight to a good portion of the continent but that won't aid you in finding the payload package once it's back on earth.

A rocket under chute has a far worse RF environment to contend with than the ballon. First of all, the rocket will swing wildly, causing polarity shifts with wild swings in received signal strength. On the magnitude of 20db or more.

It really depends on what you're trying to accomplish, and how you define success. Maybe getting the rocket back isn't much of a concern--you'd got lots of room. In that case, then accomplishing your mission objectives cheaply makes sense. As a minimum, I'd consider using two receivers--one with a vertically polarized Yagi, and another with a horizontal or circular polarization. That would give you the best opportunity for reception. It's possible to combine antennas and use diversity reception as well--easy these days with SDR receivers.
 
It really depends on what you're trying to accomplish, and how you define success. Maybe getting the rocket back isn't much of a concern--you'd got lots of room. In that case, then accomplishing your mission objectives cheaply makes sense. As a minimum, I'd consider using two receivers--one with a vertically polarized Yagi, and another with a horizontal or circular polarization. That would give you the best opportunity for reception. It's possible to combine antennas and use diversity reception as well--easy these days with SDR receivers.

Good points. Our design consideration is to capture GPS data on descent without much expectation that the radio (or GPS) will have reliable range in the dirt. The base station will keep a running log of GPS positions and the "track mode" will allow you to choose from any of the past good transmissions, assuming that contact is lost or GPS fix is lost. This isn't precise, but should get you in the neighborhood of the rocket, unless it goes sideways deep into or over mountains (happens) or lost behind clouds. This is a similar situation to the HAB balloons. They went up 120K feet and landed 80-100 miles away. We lost APRS about 3000K feet AGL, but the last known GPS put us pretty close. We also had a foxhunt beacon for the "final football field" tracking. I will experiment with different antennas, but the need is valid to have wider reception if you have no idea where the rocket landed. As a side note, the base also has a GPS in it and the software is (will be) designed to calculate and point you in the heading and give distance to the last good GPS signal from the vehicle. At least that is the ambition. As you said, the real world environment is complex, so a lot of testing will be needed.
 
Mike,

Thanks for articulating your mission goals so well. With that in mind, I think there are three things that you could do to help ensure success. The good news is that all of them are relatively low-cost.

1.) Add a 2nd receiver utilizing an antenna with different polarity. If you're using a vertically polarized Yagi on the main receiver, then use a horizontally polarized antenna on the 2nd receiver. Even better a circularly polarized antenna.

2.) Instead of thinking about your high altitude ballon experience, I'd recommend getting some tracking experience with amateur low-earth-orbit (LEO) satellites. Like rockets, these fast moving spacecraft can pitch, spin, yaw, etc. all at the same time. Obtaining reliable telemetry from these birds can be tricky, but it is a skill that can be practiced and learned.

In contrast, a balloon is generally a slow moving target with limited ability to rapidly change antenna polarity. Many HPR flyers discount this factor, but it's actually the most significant one. Polarity shifts can cause the antenna to lose strength rapidly by 20db or more due to cross-polarization loss between the antennas. The higher you go in frequency, the greater the affects. So you'll notice this much more at 433 than at 144 MHz.

If your team has some experience in getting telemetry from LEO birds as they move through the sky, it will be much easier for them to learn to do the same with rockets. Balloons and rockets share only altitude in their flight profiles--everything else will be different.

3.) For ground recovery, I share your desire to add a 2nd fox hunting transmitter. My recommendation would be the Big Red Bee 70 CM (433 MHz) tracker. It's simple, reliable, runs a long time on the battery, and has proven success in high power rockets.

https://www.bigredbee.com/BeeLine.htm

Read a review in Rockets magazine:

https://www.bigredbee.com/docs/RocketsBLReview.pdf

I share the reviewers recommendation of also bringing along a good mobile 440 MHz transceiver and omni-antenna. A good quality mobile rig is usually much more sensitive than a handheld receiver, and will allow you to get in the ballpark of the rocket once it's one the ground. From there, you can deploy with your HT and Arrow antenna to find the bird.

Considering the investment in these large level 3 projects, it's worth it to have redundant trackers and base stations. Anything is better than losing that rocket. Can't wait to hear how the flights go. Sounds like a great system.
 
I finally dug into my IMU (a 9DOF MPU9250) and mastered the accelerometer, gyro, and magnetometer. This was a lot of work to get the filters right, get the magnetometer calibrated and working as a compass, and get the Euler angles and quaternions calculated correctly. I built a small rig with two boards in a cross with the Arduino on top, so I could experiment with roll, pitch, yaw and I used it for rotating the magnetometer to test my bearing calculations. The result is that I've got an accelerometer with stable readings and configured to 16G, a way to accurately measure tilt angle of the rocket, and a compass that will give me a bearing in the base station for tracking against two GPS positions.

Now that I've got all the components mastered and (mostly) tested, I've started to think more about the code logic and timing for the software running on the rocket. I've got four distinct phases that the rocket will go through that impact the rate of checking, logging, and transmitting data. The four phases are 1) Waiting 2) Launch 3) Descent and 4) Landed. I am not using the this tech for dual-deploy or separation (only telemetry data for now) and I know I'll need a lot of real-world testing to inform the logic, but I am looking for a starting point. I know there are a lot of you that have built DIY altimeters or even commercial designs, so I'm looking for input. Here is my rough swag at the logic for launch detection, apogee detection, and landed. I'd like to catch the events as early as possible, so I don't lose important data, but without false positives. Let me know what you think? Also, what is real world experience with barometers and wind/heat/g-force?

Launch detect: (note Barometer is stable to 3-4' in "kind" conditions and accelerometer is stable to 1G +/- 1%)
=========
1) Barometer altitude (pressure) indicates +10 feet --> confirm with second read of barometer and check accelerometer for 10% increase
or
2) Accelerometer increases 10% (1.1G) on Z axis. --> confirm with two reads of the barometer pressure for > + 10 feet


Apogee Detect -- assume multiple reads and filtering of all measures
=========
Any two of these three would be a positive Apogee event
1) Tilt angle > 20 degrees
2) Barometer pressure/altitude < 10 ft gain in 1 second
3) Accelerometer Z axis < 1G

Landed detect - Barometer stable to 1% for ten seconds
=========
(ignoring accelerometer, as the rocket could be dragging in the wind on the desert playa)
 
For tilt error I assume you are using the gyros and accelerometers? I have often wondered if there should be an option for tilt detection using the magnetic vector from the three magnetometers. This would get around the problem of they gyros being pegged if the roll rate of the rocket exceeds their physical limits. What do you think?
 
For tilt angle (and apogee or error detection) the MPU9250 has three integrated components. A gyro, accelerometer, and magnetometer. That gives 9 degrees of freedom (DoF). Using &#8220;sensor fusion&#8221; in the form of the built in digital motion processor (DMP) or you can use your own Quaternion algorithms and filters that use all 9 axis for error correction to calculate yaw, pitch, and roll. It seems solid in my isolated tests, but the proof will be in the air. It is an enormous amount of math happening in just a few ms to give me a single number back representing the angle of tilt.
 
Launch detect: (note Barometer is stable to 3-4' in "kind" conditions and accelerometer is stable to 1G +/- 1%)
=========
1) Barometer altitude (pressure) indicates +10 feet --> confirm with second read of barometer and check accelerometer for 10% increase
or
2) Accelerometer increases 10% (1.1G) on Z axis. --> confirm with two reads of the barometer pressure for > + 10 feet

Apogee Detect -- assume multiple reads and filtering of all measures
=========
Any two of these three would be a positive Apogee event
1) Tilt angle > 20 degrees
2) Barometer pressure/altitude < 10 ft gain in 1 second
3) Accelerometer Z axis < 1G


Based on my experience your launch detect criteria is way too tight. Something is likely to eventually happen that causes a false launch detect. I would suggest a criteria of several G’s sustained acceleration for say 0.5 sec or so. Otherwise, a disturbance, like for example a motor chuff, might trigger a launch detect when none occurred. I would also increase the barometer threshold to be at least 100 feet gain in a short time period in order to avoid having wind gusts trigger it. Personally, I would not even bother using the baro for launch detect. I think the accelerometer is sufficient and robust.

As for apogee detect, watching for < 1G will not work. Z axis acceleration goes negative as soon as the motor burns out. I suggest integrating Z axis net acceleration to derive Z axis velocity. Then watch for the velocity to go negative. That happens at apogee.
 
FYI, Eggtimer altimeters use baro for launch detect (since there's no accelerometer...), typically we trigger at 200' AGL although some models are adjustable. We take several initial readings and use an EMA filter on them, then we filter in a new reading every 3 seconds if the launch detect altitude has not been reached. This accounts for wind gusts, and changes in pressure due to temperature. The latter can be quite significant if your black CF rocket is sitting on the pad in the desert sun for 30 minutes...

For apogee detection, baro is the most reliable if you're within the range (about 60K for modern sensors). Beyond that, you need to use fused accel-gyro or GPS data.
 
I would ditch the Arduino and go with a more powerful micro controller - if only to make sure you’re not ending up processor bound. Even the Arduino Mega is very limiting. I have an ESP 8266 up and working now and it’s fantastic. Better, it’s just one pin wider than a Nano - so it fits into a bt-60 tube. All my Arduino code just works, but you get a few Mb of built in flash for logging, way more memory and they run at 10x the speed or more and boot instantly. For $10.

Even better, they have WIFI and can run a small web server and act as their own wifi base station. This means you can write a web based UI and control everything right from your phone or laptop from a safe distance. I can now use go to the browser on my phone, log into my rocket, change a bunch or parameters, look at nice graphs of the logged flight data, arm or disarm things, etc. You can even flash them over wifi. The wifi also gives you rudimentary radio tracking too. I have mine configured as it’s own base station and by looking at the signal strength, you can get a rough idea of distance - or even direction if you have the right antenna (though the range is only hundreds of feet)

I’m not yet sure how well it will handle 10g mind you.

For apogee detection, I keep track of the maximum alititude and assume apogee was reached if the current altitude is less than the maximum by some configurable threshold. still don’t fully trust those IMUs. The library I’m using (for the MPU6050) exposes interrupts to detect free fall, motion and no motion. I’m going to play with those, but the only good way to test them is to fly and log repeatedly.


Sent from my iPhone using Rocketry Forum
 
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.

jnobels, thanks for the heads up on the ESP8266. I've ordered one to play with, but I will likely stick with the small pro mega I have for now. I don't need the wifi radio and I've got a lot of diverse I/O going on. On my bench rig, I can read all the components (GPS, MPU, Barometer, radio, event sensors, voltage, etc) and log to SD card and transmit on high power in under 100ms -- that is plenty of resolution. I can also share most of the same code between my base and rocket rig for GPS, MPU-compass, radio, etc. Real-life testing might necessitate a faster processor, but I've got a good starting point, so far.
 
Back
Top