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.

AllDigital

Well-Known Member
TRF Supporter
Joined
Jun 14, 2013
Messages
616
Reaction score
751
Location
SoCal
I have been thinking about building a radio based telemetry setup for a while and I finally decided to take the plunge with my son. Previous posts have provided a lot of good insight, but I haven’t seen any exactly like what I am considering. I was inspired last weekend from watching a few student groups struggle to get telemetry from a laptop station (in the dirt), while launching big rockets for the NASA challenge.

The initial plan would be to have a package on the rocket tracking all significant activity using an Arduino, GPS, barometer, accelerometer/gyro (MPU6050), logging everything to memory and SD, and transmitting via radio to a hand-held Arduino base station box. The first version wouldn’t be used for dual deploy, but as I got more confident in the system it could be used for dual deploy charges and other sensing (e.g., mag switches to detect separation).

The handheld unit would also utilize an Arduino, TFT display (or something faster), a serial radio, SD card, GPS, and I’m considering speaker/MP3 player output for voice notification (similar to “Kate”). An Arduino might not have the power for the ground-based handheld, so I might switch to a Raspberry Pi, but I’ll take a run at using a fast Arduino first.

At a minimum, I want to capture all the basics: launch detect, periodic altitude, speed intervals, top speed, top g’s, apogee, deploy detect, descent rate, GPS location, distance, etc. The idea would be to capture locally on the rocket at a high resolution and send packets down at intervals during launch (e.g., every x thousand feet) and then on descent transmit more data, so the hand-held has everything before it lands. The local Arduino on the rocket would log to memory and then to SD card. The hand held Arduino would display critical information on a screen and log radio traffic to the SD card. The handheld could also graph the flight data, provide simple map/direction tracking, etc.

I have a lot of experience with Arduinos, various screens/output, SD cards, etc. I have also bench tested a few different 433Mhz radios with serial transmission. I’ve also put a barometer, MPU6050, and GPS through code unit testing, but I haven’t started putting things together yet.

I don’t need the package to be super tiny. I don’t plan on flying it on anything less than 4”, but it would be nice to keep things as small and light as possible.

Any advice on the following would be appreciated:
1) GPS - I recall that GPS units are either fast or high, but not allowed to be both. Any recommendations on devices, antennas, or placement? I have had failures on space balloons with GPS units turning over. Any thoughts about using two GPS devices - one up one down for descent?
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.
3) Sample code - if anyone already has good sample code that integrates the logic across the devices (e.g., compare accelerometer data to barometer for apogee detect).

I’m happy to open source and share the learnings when I have something complete. Given how cheap the components have become, this should be a relatively inexpensive way to have streaming flight data.

Thanks,

Mike
 
Mike-sounds ambitious and doable. I and some friends have just started to play with a 2 meter 300 mw APRS transmitter (Radiometrix HX1) as a transmitter for a Ublox Max M8Q GPS receiver/breakout board with an Arduino Nano; however other GPS units with larger receiving antennas will also be tested. If you view web site #3 listed below-Uptronics will describe their products including a complete system utilizing an Arduino uno. Also, on their site LoRa 430 MHz suitable transmitters are shown. If you decide to purchase a Radiometrix APRS transmitter-they have a subsidiary in Providence R. I. -so no need for shipping charges from the U.K. Another potentially good source is a very talented Dutch amateur rocketeer, Leo Deelman, who has designed and utilized a "talking" telemetry/GPS unit that would compete with Kate. His web site is listed as # 1 below and it includes a YouTube link where his "talking GPS" unit is demonstrated in flight. I've exchanged some emails with him previously and he seems to be friendly and very knowledgeable. He utilizes an older version of a Ublox unit with the DRA818U (440 MHz) APRS capable transmitter which emits 1 watt of RF. There is also an equivalent 2 meter version available. There is a blog site where a DRA818 U based transceiver schematic and PCB board design are shown and discussed (see reference #2 below). The DRA818U was listed at a price below $13. Finally, Byonics makes great 2 meter GPS units. I'm using their MT-2000 (in association with a GPS unit) and it transmits 2 watts via APRS. Its small enough to be accomodated on a sled into a smallish 2 and 1/2 inch diameter nose cone along with a sizable Lipo battery. Byonics also offers 10 watt and 40 watt APRS transmitter units for GPS NMEA transmission purposes (see reference #4 below). Good luck with the development of your telemetry units, I'll be subscribed.

References:
1. https://deelmanl.wordpress.com/talking-gps/
2. https://hamgear.wordpress.com/2015/02/03/make-your-own-transceiver-with-a-dorji-dra818u-or-dra818v/
3. https://store.uputronics.com/index.php?route=product/product&path=62&product_id=57
4. https://www.byonics.com/downloads/MTT4B_Manual_v1.0.pdf

Fred, L2
member of ICBM
Camden, S.C.
KG4YGP
 
Mike-I've been experimenting with a 2 Meter APRS based system called "Tracksoar" which I'm pretty happy with, but your proposed Arduino system sounds much more ambitious. Telemetry is one of the primary reasons why I've gotten back into rocketry. Want to combine my love of rockets with my love of radio. I'll be subscribed to this thread to see how you make out. If you have RF based questions, I'll be happy to help. Unfortunately no experience (yet) with Arduino.
 
Sounds like a cool project!
I'm working on an Arduino based deployment altimeter as well, just without telemetry- if you shoot me a PM I can send you some code samples.

Good luck with your project!

Sent from my LGL44VL using Tapatalk
 
Here’s the code for a project I’ve been working on... I’ve flown this a couple of times and it works. My goal was to build an altimeter that could do dual deploy with a locator alarm for under $10.. I have a second version of this that uses an SD card to log telemetry and can interface with an iPhone over Bluetooth but haven’t had the opportunity to build and fly it yet. That version is getting pretty close to the limits of what an Arduino can do as well.

I’m not using the accelerometer for much. Have to fly a a bunch of test flights in the spring to see how accurately I can determine velocity, burnout, etc. The nosiness of the accelerometer and gyro data makes me a bit nervous. The pressure sensors are inexpensive and remarkably accurate though.

https://github.com/barnstar/SimpleAltimeter

I also just started playing around with Raspberry Pi micros... they’re not much bigger but you get wifi, SD, Bluetooth, HDMI and several orders of magnitude more computing power in a about the same size package - at 10x the price of an Arduino nano.





Sent from my iPhone using Rocketry Forum
 
Two other devices but the GPS chipsets are terrestrial only the AP510 they say can go above 60k but the PicoAPRS cannot.

https://www.hamradio.com/detail.cfm?pid=H0-015928 and https://www.db1nto.de/index_en.html

https://oh2fxd.wordpress.com/2014/12/19/into-to-the-wild-with-sainsonic-ap510-aprs-tracker/

Ap510 has a stupendously high learning curve but this video helps: https://www.bing.com/videos/search?...BA6D7C4250B1F45CC468BA6D7C4250B1F45&FORM=VIRE

Some of the devices also posted above look promising. Remember, higher power output has the potential for farther range and a larger ground footprint.
2 meters would be better with a 1/4 wave antenna if one has the room. Also, some flight controllers don't play well in high powered > 1 watt Rf output.
The newer controllers with opto-isolators are more resistant to the effects of Rf and of course the developers of combined controllers/trackers have that
thoroughly worked out before they offer their devices forsale.

Also, remember balloon flights are sedate affairs and not nearly intense as a rocket flight. For instance, a balloon flier wrote me and said he flew an
AP510 next to a Beeline GPS 2m. The Beeline of course has a high altitude GPS and the AP510 a sirfIII or sirfIV chipset. He compared their outputs and altitudes
and there was no difference in them. With a rocket flight Sirf chipsets don't do so well with altitude reporting but they do fine on positioning. Kurt
 
Thanks for the quick feedback and input.

@Lithosphere, I read your whole thread yesterday and am very impressed with what you are doing. There is a lot of overlap, although I would like to try and do it all with off-the-shelf components, instead of a custom PCB, so that student groups and others can replicate it easily. That said, I will probably want to shrink it down when done. It looks like you are tackling a lot of the same concerns I've got regarding memory/sampling, storage, and the dreaded accelerometer/gyro. I will follow-up separately to compare notes.

Jonathan, thank you for the code samples. It looks like you are putting a lot of trust in the barometer. Is it really that stable that you don't need multiple samples for launch detect? I figured I would be doing multiple samples and triangulating with the accelerometer at launch and apogee.

My biggest concern right now is how much is going on between launch and apogee. That could be a very short time (e.g., as little as 20 seconds) with the window of time to capture max velocity much smaller. So, I am thinking sample rates need to be a minimum of 1/10 sec with higher being better. This is even more critical if the unit will be used for stage or ejection in the future. On an Arduino that doesn't leave much time to check very many sensors, transmit data, or log the output. I need to get all the sensors hooked up and time stamp them to better understand options. I am thinking I might need to upgrade to a small footprint ATmega2560 processor to get 256Kb and more IO capability. I'm also thinking that my serial radio might have its own Arduino nano, so it can transmit telemetry down during ascent. The primary cpu would be busy sampling, but could raise a few pins to indicate altitude without losing many cycles. Once Apogee is reached, assuming good chutes, then sampling rates can drop and the CPU has lots of time to communicate over the radio, check GPS, dump data to an SD, etc.

Mike and Fred, the radios seem like the easiest and the hardest at the same time. On the one hand, there are a lot of high power serial tty radios that can plug directly to an Arduino. A few lines of code can send any message back and forth. They work really well, but wattage, frequency, and content (data vs voice) is FCC restricted. So, a low-med power solution could be easy on a public use frequency, but would suffer from potential interference and range. APRS frequencies could be used at higher wattage, but getting all the other telemetry data I want (beyond GPS) packed into the short burst APRS format is really messy and seems inefficient. Are either of you aware of an Amateur licensed frequency that can be used for data (not voice) and not APRS with reasonable wattage (2-3W)?

Again, thanks for all the feedback.
 
I think you'll have plenty of space for everything you need on a stock Arduino. Since I2C and SPI both stack relatively well, you can have a lot of sensors on one set of pins. If you have to you can repurpose analog pins as digital outputs as well.

I don't think speed will be much of an issue either. Arduinos may be slow but you don't need much, especially with the MPU6050 that does the hard calculations onboard.

I'm just using barometer data for altitude, but it's being run through a smoothing algorithm, so I have a bit more faith in it. You can get altitude with the accel but it's much more susceptible to small errors- what most people seem to do is use the barometer for altitude and accel for velocity.

I'm looking forward to seeing your results!

Sent from my LGL44VL using Tapatalk
 
Mike and Fred, the radios seem like the easiest and the hardest at the same time. On the one hand, there are a lot of high power serial tty radios that can plug directly to an Arduino. A few lines of code can send any message back and forth. They work really well, but wattage, frequency, and content (data vs voice) is FCC restricted. So, a low-med power solution could be easy on a public use frequency, but would suffer from potential interference and range. APRS frequencies could be used at higher wattage, but getting all the other telemetry data I want (beyond GPS) packed into the short burst APRS format is really messy and seems inefficient. Are either of you aware of an Amateur licensed frequency that can be used for data (not voice) and not APRS with reasonable wattage (2-3W)?

If you want more data (bandwidth) you need to go up into the UHF ham bands. You should be able to send all the data you want in the 70cm ham band. This is what the Altus Metrum units use and they send lots of data. You will need to look at the ham radio rules and regs to see exactly what bandwidths are allowed on each band.

You can also use compressed APRS to send more data in smaller packets in the 2M band if you need. I believe it is often refered to as Mic-E.

Terry
 
Regarding the barometer - the bmp280 units are remarkably stable. I set some fairly safe thresholds - on the order of 20m to detect apogee and launch. I’m finding the sensors are accurate on the order meters easily (at least in relative terms). I will likely average a window of samples and throw out spurious readings for deployment though. For now, I’m just flying and logging when deployment would have happened to validate the design. The bmp280 units are only $2 each and they’re small so I’m also considering running a pair of them.

The accelerometer/gyro is less useful, the data is very noisy and I don’t trust it yet. Also much more difficult to statically test and it’s the middle of winter here so I haven’t been flying much. I do want to incorporate it, but I need to gather more data in real flight situations.




Sent from my iPhone using Rocketry Forum
 
Thanks for the quick feedback and input.

@Lithosphere, I read your whole thread yesterday and am very impressed with what you are doing. There is a lot of overlap, although I would like to try and do it all with off-the-shelf components, instead of a custom PCB, so that student groups and others can replicate it easily. That said, I will probably want to shrink it down when done. It looks like you are tackling a lot of the same concerns I've got regarding memory/sampling, storage, and the dreaded accelerometer/gyro. I will follow-up separately to compare notes.

Jonathan, thank you for the code samples. It looks like you are putting a lot of trust in the barometer. Is it really that stable that you don't need multiple samples for launch detect? I figured I would be doing multiple samples and triangulating with the accelerometer at launch and apogee.

My biggest concern right now is how much is going on between launch and apogee. That could be a very short time (e.g., as little as 20 seconds) with the window of time to capture max velocity much smaller. So, I am thinking sample rates need to be a minimum of 1/10 sec with higher being better. This is even more critical if the unit will be used for stage or ejection in the future. On an Arduino that doesn't leave much time to check very many sensors, transmit data, or log the output. I need to get all the sensors hooked up and time stamp them to better understand options. I am thinking I might need to upgrade to a small footprint ATmega2560 processor to get 256Kb and more IO capability. I'm also thinking that my serial radio might have its own Arduino nano, so it can transmit telemetry down during ascent. The primary cpu would be busy sampling, but could raise a few pins to indicate altitude without losing many cycles. Once Apogee is reached, assuming good chutes, then sampling rates can drop and the CPU has lots of time to communicate over the radio, check GPS, dump data to an SD, etc.

Mike and Fred, the radios seem like the easiest and the hardest at the same time. On the one hand, there are a lot of high power serial tty radios that can plug directly to an Arduino. A few lines of code can send any message back and forth. They work really well, but wattage, frequency, and content (data vs voice) is FCC restricted. So, a low-med power solution could be easy on a public use frequency, but would suffer from potential interference and range. APRS frequencies could be used at higher wattage, but getting all the other telemetry data I want (beyond GPS) packed into the short burst APRS format is really messy and seems inefficient. Are either of you aware of an Amateur licensed frequency that can be used for data (not voice) and not APRS with reasonable wattage (2-3W)?

Again, thanks for all the feedback.

Mike- look at https://www.gpo.gov/fdsys/pkg/CFR-2009-title47-vol5/pdf/CFR-2009-title47-vol5-part97.pdf - that is an FCC site which explains all applicable ham frequencies. Look at the table on page 612 and you'll see in part the following for data transmission (i.e. telemetry):

VHF 2 meters-- 144.1 to 148 MHz (data transmission; however, also cw, ssb, repeater, and for the old timers-AM, also digital)

1.25 meters -- 219 to 220 MHz (mostly preserved for data which would also include digital)
22-225 MHZ (data and all other forms of transmission)

70 cm Entire Band-data and other modes of transmission.

Depending in the area you plan to launch, you should check local repeater frequencies and heavily populated APRS frequencies in order to not interfere with others and to also maintain a peaceful arrangement with others using that band.

The references I sent about the LoRa transmitters and the DRA818 U or V transmitter can utilize modes of telemetry transmission independent of APRS.

Good luck!

Fred
 
Fred, thanks for the FCC link. This is very helpful. I also looked at the DRA818 and the other LoRa radios. So, I am partial to 70cm band, but also know that it can get busy. I've got a few cheap serial TTY radios hooked up now for a proof of concept, but the ones that I am looking at are these: https://www.nicerf.com/product_148_61.html - These look very configurable in terms of frequency (70cm), power output, they are +5vdc, and they support serial TTL (vs RS232, RS485, etc.). They are also bi-directional, so I can send commands up. They are expensive ($100/pair), but they are high wattage. I'll keep researching.

In the meantime, I did some time trials and additional testing with each of the components I have that will go in the rocket. It turns out that reading the barometer, the accelerometer, sending data on the radio, and writing to the SD card are all screaming fast, but reading the GPS is dog slow. Here are a few rough benchmarks. These were taken on an ATmega2560, but I will re-run them on a Nano to see the difference.

--Barometer I2C - it has sensitive settings 0-3. On a setting of 3 it is incredibly stable (1 ft), but it takes 30ms a read. At setting of 1 it is stable to 2-3 feet, but only takes 15ms to read.
--Radio UART TTY serial - I ran a loop reading the barometer and did a transmit of data every ten reads on the radio and it only added 1ms per transmit. More testing needed with more data, but very encouraging.
--SD Card SPI - I ran the barometer in a loop and wrote out results to an open file on the SD card. With each read I did a write to test continuous logging (versus using memory). I was surprised that it only added 1 ms per cycle to write to the SD.
--MPU6050 Accelerometer / Gyro on I2C - I did not do extensive testing, but reading data from the accelerometer is also screaming fast. I'll need to work on compute time later.
--GPS on UART - Reading the GPRMC and the GPGGA on my GPS is dog slow. With a fix it takes about 600ms to read. That is way too much time to stop checking/logging the barometer and other sensors on the way up. I really want to be able to log the GPS a few times before apogee, because after apogee it could be upside down or in a mountain. @Lithosphere, have you found a GPS that uses I2C or provides a faster read?

I've also started looking at the handheld base station components. I still want to make it work with an Arduino and not upgrade to a Raspberry Pi. The handheld box will be a 10"x7"x2.5" and I ordered a 5" 800x480 TFT screen for it, so I will have lots of real estate to present data. Adafruit has a unique display/driver that allows all those pixels to work with an Arduino at a good refresh rate (I hope). The base will also have a GPS and magnetometer for tracking to the landed rocket and calculating distance, an SD card for logging telemetry, and I've got an Arduino MP3 player and a small amplified speaker to add voice to announce launch, altitude, top speed, apogee, and descent speed.

I'll be traveling for a few weeks, so away from the bench, but I'll provide updates as things progress.
 
Fred, thanks for the FCC link. This is very helpful. I also looked at the DRA818 and the other LoRa radios. So, I am partial to 70cm band, but also know that it can get busy. I've got a few cheap serial TTY radios hooked up now for a proof of concept, but the ones that I am looking at are these: https://www.nicerf.com/product_148_61.html - These look very configurable in terms of frequency (70cm), power output, they are +5vdc, and they support serial TTL (vs RS232, RS485, etc.). They are also bi-directional, so I can send commands up. They are expensive ($100/pair), but they are high wattage. I'll keep researching.

In the meantime, I did some time trials and additional testing with each of the components I have that will go in the rocket. It turns out that reading the barometer, the accelerometer, sending data on the radio, and writing to the SD card are all screaming fast, but reading the GPS is dog slow. Here are a few rough benchmarks. These were taken on an ATmega2560, but I will re-run them on a Nano to see the difference.

--Barometer I2C - it has sensitive settings 0-3. On a setting of 3 it is incredibly stable (1 ft), but it takes 30ms a read. At setting of 1 it is stable to 2-3 feet, but only takes 15ms to read.
--Radio UART TTY serial - I ran a loop reading the barometer and did a transmit of data every ten reads on the radio and it only added 1ms per transmit. More testing needed with more data, but very encouraging.
--SD Card SPI - I ran the barometer in a loop and wrote out results to an open file on the SD card. With each read I did a write to test continuous logging (versus using memory). I was surprised that it only added 1 ms per cycle to write to the SD.
--MPU6050 Accelerometer / Gyro on I2C - I did not do extensive testing, but reading data from the accelerometer is also screaming fast. I'll need to work on compute time later.
--GPS on UART - Reading the GPRMC and the GPGGA on my GPS is dog slow. With a fix it takes about 600ms to read. That is way too much time to stop checking/logging the barometer and other sensors on the way up. I really want to be able to log the GPS a few times before apogee, because after apogee it could be upside down or in a mountain. @Lithosphere, have you found a GPS that uses I2C or provides a faster read?

I've also started looking at the handheld base station components. I still want to make it work with an Arduino and not upgrade to a Raspberry Pi. The handheld box will be a 10"x7"x2.5" and I ordered a 5" 800x480 TFT screen for it, so I will have lots of real estate to present data. Adafruit has a unique display/driver that allows all those pixels to work with an Arduino at a good refresh rate (I hope). The base will also have a GPS and magnetometer for tracking to the landed rocket and calculating distance, an SD card for logging telemetry, and I've got an Arduino MP3 player and a small amplified speaker to add voice to announce launch, altitude, top speed, apogee, and descent speed.

I'll be traveling for a few weeks, so away from the bench, but I'll provide updates as things progress.

Mike- If you get a chance, review the Uputronics site- https://store.uputronics.com/index.php?route=product/product&path=62&product_id=57- they send GPS by APRS and RTTY in part using the UKHAS format. Also-if you navigate thru-you'll find links to their Arduino code. In addition, the Track Soar Arduino code (other Mike's platform, it also utilizes APRS)) is also on the web as is various track or tinytrack duino platforms. Given restrictions of GPS, APRS transmission is usually every 5 seconds for rocketry ; however, non-APRS transmission can be more often. I'm just starting Arduino projects, so I'll defer to your experience and opinion. I think you'll have a sizable following given the parameters of your project.

Fred
 
Speaking of Uputronics, take a look at their Neo8 GPS mated to a Sarantel antenna. It's ideal for keeping a lock inside a rocket. I had a Neo6 chipset with an amplified Sarantel circumfiler antenna I unfortunately dropped before I was able to put it in a rocket. Since Sarantel was sold, it's hard to get these antennas anymore for GPS reception without ordering 10,000 units. Kurt
 
--GPS on UART - Reading the GPRMC and the GPGGA on my GPS is dog slow. With a fix it takes about 600ms to read. That is way too much time to stop checking/logging the barometer and other sensors on the way up. I really want to be able to log the GPS a few times before apogee, because after apogee it could be upside down or in a mountain. @Lithosphere, have you found a GPS that uses I2C or provides a faster read?

You can configure the baud rate to as high as 460,800. That ought to speed things up considerably.

https://www.u-blox.com/sites/defaul...8-M8_ReceiverDescrProtSpec_(UBX-13003221).pdf

Start in section 10.3.

Terry
 
Fred, thanks for the FCC link. This is very helpful. I also looked at the DRA818 and the other LoRa radios. So, I am partial to 70cm band, but also know that it can get busy. I've got a few cheap serial TTY radios hooked up now for a proof of concept, but the ones that I am looking at are these: https://www.nicerf.com/product_148_61.html - These look very configurable in terms of frequency (70cm), power output, they are +5vdc, and they support serial TTL (vs RS232, RS485, etc.). They are also bi-directional, so I can send commands up. They are expensive ($100/pair), but they are high wattage. I'll keep researching.

In the meantime, I did some time trials and additional testing with each of the components I have that will go in the rocket. It turns out that reading the barometer, the accelerometer, sending data on the radio, and writing to the SD card are all screaming fast, but reading the GPS is dog slow. Here are a few rough benchmarks. These were taken on an ATmega2560, but I will re-run them on a Nano to see the difference.

--Barometer I2C - it has sensitive settings 0-3. On a setting of 3 it is incredibly stable (1 ft), but it takes 30ms a read. At setting of 1 it is stable to 2-3 feet, but only takes 15ms to read.
--Radio UART TTY serial - I ran a loop reading the barometer and did a transmit of data every ten reads on the radio and it only added 1ms per transmit. More testing needed with more data, but very encouraging.
--SD Card SPI - I ran the barometer in a loop and wrote out results to an open file on the SD card. With each read I did a write to test continuous logging (versus using memory). I was surprised that it only added 1 ms per cycle to write to the SD.
--MPU6050 Accelerometer / Gyro on I2C - I did not do extensive testing, but reading data from the accelerometer is also screaming fast. I'll need to work on compute time later.
--GPS on UART - Reading the GPRMC and the GPGGA on my GPS is dog slow. With a fix it takes about 600ms to read. That is way too much time to stop checking/logging the barometer and other sensors on the way up. I really want to be able to log the GPS a few times before apogee, because after apogee it could be upside down or in a mountain. @Lithosphere, have you found a GPS that uses I2C or provides a faster read?

I've also started looking at the handheld base station components. I still want to make it work with an Arduino and not upgrade to a Raspberry Pi. The handheld box will be a 10"x7"x2.5" and I ordered a 5" 800x480 TFT screen for it, so I will have lots of real estate to present data. Adafruit has a unique display/driver that allows all those pixels to work with an Arduino at a good refresh rate (I hope). The base will also have a GPS and magnetometer for tracking to the landed rocket and calculating distance, an SD card for logging telemetry, and I've got an Arduino MP3 player and a small amplified speaker to add voice to announce launch, altitude, top speed, apogee, and descent speed.

I'll be traveling for a few weeks, so away from the bench, but I'll provide updates as things progress.
I'm not using GPS for my altimeter, mainly because I'm not sending data back anyway.

What bus are you interfacing with the BMP280 on? I've never gotten mine to work over I2C and I'm having plenty of problems with both on SPI.

By the way, I assume RocketTalk won't be at NSL? I'm in New England so it's the closest big launch for me... I'd love to take a trip out there for LDRS but that's probably not happening this time around.

Sent from my LGL44VL using Tapatalk
 
@Fred and @KSaves2, I looked at all the Uputronics hardware, but nothing fits the bill. I need a radio that is independent of the GPS that I write to directly and it needs to be higher wattage than what they are selling. I've got a few others on order to try out.

@W7AMI, good suggestion on the baud rate. I've got another GPS on order that samples at 10Hz and allows me to easily set the baud rate. The problem with these GPS modules is that I'm not listening to them all the time. So, when you want a reading you open up serial listening and you come in "mid conversation" and sometimes need to wade through two cycles to get what you need. At 10Hz I am hoping I can get readings in the 150ms range.

@Lithosphrere, the MPU6050 I am using is here: https://a.co/27cdnhi It works on I2C, but I have only done basic bench testing. I'm not sure when this project will be done, but most likely not at LDRS. Getting the pieces together won't be a big deal, but finding the time to flight test and tune it will take many months.
 
I had some long airplane rides, so I started to detail out the features, functions, and design for the handheld base station and some of the logic for the onboard system. I'm thinking the "base station" will be a 11" x 7" x 2" handheld box with a 5" TFT display and switches/controls. Below is a preliminary list of features and functions. Let me know if you think there is something missing and/or other data that would be important to capture during or after flight.


Key features:
- 5" TFT Display 800 x 480 resolution
- Voice speaker module for "speaking" key events like launch detect, altitude, apogee, etc.
- (future) Radio back-up ejection charge (safety key and encrypted message)

Five Modes for base station:
- Launch mode (active for prep, launch, and land of rocket)
- Tracking mode (used for GPS directional tracking for recovery)
- Analyze mode (to analyze details and graphs of past launches)
- Test mode (base to vehicle communication testing)
- Local diagnostics (self-test and GPS status of the handheld base station)

Launch Mode
- During launch the vehicle moves through five phases reporting to the handheld:
1. Warming (vehicle initialization, GPS satellite acquisition, barometer warm-up, etc.)
2. Waiting (waiting to launch)
3. Launch (launch detect through Apogee)
4. Descent
5. Landed
- In launch mode the handheld is capturing and displaying the following telemetry:
o Phase and status
o Altitude - current and max (barometer)
o Speed - current and max (barometer? Accelerometer?)
o Acceleration - current and max (Accelerometer)
o Temperature - current and max (barometer)
o Tilt - current and max (gyro)
o GPS Data
- Longitude
- Latitude
- Altitude
- Distance
- Quality/Satellites
- Temp
o Events (launch detect, apogee detect, landing detect)
o Events (aft separation, forward separation)
o Current time, last transmission time

Tracking Mode:
1. Select vehicle coordinates from GPS log (usually current or last, but could older airborne transmissions might be more accurate)
2. Map display - display vehicle relative to base relative to North with distance, bearing, altitude.
3. Tracking display - display arrow pointing to vehicle GPS coordinates with interval (20 second) refresh - using magnetometer compass and base GPS data.

Analyze Mode:
1. Select from list of previous launches
2. Pg Up / Down for the following:
a. Summary details of flight (everything captured during launch mode)
b. Log of telemetry transmissions from vehicle
c. Log of GPS transmissions from vehicle
d. "Instant replay" - replay flight on graph (e.g. like a launch simulation)
 
I did a few tests last weekend to see if I could get an Arduino to talk. I created a vocabulary of about 50 words using an online text to MP3 converter and then placed them on an SD card. Then I used a small Arduino MP3 player module and speaker to demonstrate how words and numbers can be strung together to "talk". This is still a bit crude in terms of timing and quality, but looks like a great way to have very low cost talking telemetry.

https://vimeo.com/257903939/284287aa1f
 
Exciting to see all of the new projects, I hope they all choose to be open source.
I also have thought about it and a very rough scale. some things I have found or decided for a tracker
A. Using Lora 433Mhz for transmission, Xbee 900 or 868 is another choice and is what missleworks uses, Xbee would probably be easier to integrate but Lora would be longer range. "IMO"
B. My goal would be as small as possible so I would base it on Arduino Pro Mini 3.3V "that and I have a dozen of them from other projects"
C. Have not done much research on GPS but would start with MTK3339 its widely known in Arduino community so a good start anyway.

I want to get a nice working tracker before I tackle doing anything related to rocket safety.
Long term goal would be custom pcb to get it as small as possible.

Something you might also want to look into this
https://www.electrodragon.com/product/atmega328p-arduino-plus-lora-sx1278-board-loraduino/
Its basically a arduino pro with lora board installed on back side. Its not perfect but might be a nice starting point for someone.
 
For the bmp 280 on i2c, I’ve found that the i2c address is often often not what the library uses as the default. You can specify it in the constructor. Some units use 0x77, some use 0x76 (iirc).


Sent from my iPhone using Rocketry Forum
 
@W7AMI, good suggestion on the baud rate. I've got another GPS on order that samples at 10Hz and allows me to easily set the baud rate. The problem with these GPS modules is that I'm not listening to them all the time. So, when you want a reading you open up serial listening and you come in "mid conversation" and sometimes need to wade through two cycles to get what you need. At 10Hz I am hoping I can get readings in the 150ms range.

Not sure why you need to turn off the serial port? Are you using interrupts and a buffer to capture your serial data?

It might also help if you could turn off all the report strings except $GPRMC and $GPGGA to save more time parsing through the data.

Terry
 
Last edited:
My design goal is to use off the shelf modules with breadboards, instead of raw components and a custom pcb, so student groups and others can easily replicate. That will probably limit the package to 3” airframes and bigger and designed to go very high (50K+). That doesn’t preclude anyone from shrinking the footprint later.

@Terry, the new GPS allows me to disable all but GPRMC and GPGGA and speed up baud rate, so I expect much better results. I am not using interrupts and buffers, since there is too much going on during ascent for the single threaded arduino and I only need to check the GPS infrequently (every ten seconds). I believe it is outputting at 10Hz, so I’ll skip 100 readings and then come in to read, but I want the read to take sub 100ms. I noticed on my old gps that I’d often come in to read at different points of the NMEA output.
 
Here are a few updates...

GPS: I got a new GPS module (Adafruit Ultimate GPS) and I am able to get the GPS reading down to <100ms. This requires setting the sample rate to 10hz, setting baud to 57600, and limiting NMEA output to RMC and GGA. With the new configuration I can read the GPS, write to SD, and transmit the data in about 100ms. That is a reasonable amount of time to stop monitoring every 5 seconds or so.

CPU: I upgraded to a MEGA 2560 Arduino board for the rocket. I found a very small PRO version that is only 2.1" x 1.5" with built-in voltage regulators. It is sold by RobotDyn and so far checks out well. It gives me a lot more memory and I/O to work with.

Base Station Display: I got a 5" TFT display (800 x 480) from Adafruit with their RA8875 driver board. The display is fast and very high resolution, so I'll have a lot of real estate for the telemetry data and I'll still be able to use an arduino in the hand-held. That will simplify the build considerably (vs. using a Raspberry Pi or more powerful CPU).

I am still waiting on some radios I ordered and the only thing left to bench test is the accelerometer / gyro. Filtering the GPS and barometer seems easy compared to the accelerometer. I have been playing with Kalman code, but I've got a lot of work to perfect it. I think I might build a small rig to test and try various physical models. If anyone has solid Arduino code with filters for an MPU6050 I'd appreciate it.

Here is a photo of the PRO Mega 2560 board:
IMG_5391.jpg
 
FWIW, I've found that the Adafruit module takes a while to lock up after boost. If you can, using a ublox GPS is probably going to produce better results. You're unlikely to get usable GPS from anything during boost.

I've made quite a few flights with a Sparkfun Razor IMU (which has an integrated Arduino) and an Xbee 900 MHz Pro XSC radio. Software sends the IMU data including integrated altitude and velocity down at 10 Hz until apogee, then switches to the GPS data. Typical flight results are graphed below.

imu-exw-mar2018.jpg
 
Here are a few updates...
Base Station Display: I got a 5" TFT display (800 x 480) from Adafruit with their RA8875 driver board. The display is fast and very high resolution, so I'll have a lot of real estate for the telemetry data and I'll still be able to use an arduino in the hand-held. That will simplify the build considerably (vs. using a Raspberry Pi or more powerful CPU).

Make sure to test the display in the bright sun before you commit to it. Most TFT displays suck in the bright sun.
Terry
 
@mikec, thanks for the tip on Adafruit. After additional research, it sounds like ublox is the gold standard for rockets, given their high dynamic motion settings. I've ordered a new GPS based on the Ublox NEO-8 chipset. It looks like it can respond up to 4g's of acceleration at 300 ft/sec. If I am reading the manual right it looks like it has programable "platform settings" that could be adjusted on the fly depending on the phase (launch vs descent). The Sparkfun IMU is also a good tip. There is a lot packed onto that little module. I like that it has an integrated CPU to analyze and filter without putting that load on my main CPU. It might be overkill, but I ordered one to play around.

@Terry, I did a sun test on the TFT. As long as I am using high contrast white and yellow, it is acceptable even at a very small font. It isn't iPhone X bright, but it is pretty good. I looked at using eInk and I have a 4.3" display on order, but the refresh on those is painfully slow and there is no back light. I'm open to suggestions, but there aren't many options that provide the resolution and the refresh rate.
 
Back
Top