Help Plz. Arduino to calc rate of descent.

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Joined
Oct 8, 2018
Messages
20
Reaction score
0
Location
Hurricane, WV
I have a Nano, a Neo-6 GPS, an SD card, and BME-280. I'm wanting to measure rate of descent of different parachute designs I'm working on. What would be the calculations of the data gathered by the BME-080 (for altitude changes). Could I use the GPS for the rtc to timestamp each data sampling? I'd have to collect several per second for an accurate depiction of the rate. Should i just get a pitot tube and not do the calcuations?
 
I have a Nano, a Neo-6 GPS, an SD card, and BME-280. I'm wanting to measure rate of descent of different parachute designs I'm working on. What would be the calculations of the data gathered by the BME-080 (for altitude changes). Could I use the GPS for the rtc to timestamp each data sampling? I'd have to collect several per second for an accurate depiction of the rate. Should i just get a pitot tube and not do the calcuations?
I would just set up a timer interrupt every 100-200 ms on the Nano and sample the BME-280. You could convert rate of change of pressure to m/s or f/s directly. You don’t need a GPS time stamp - that’s overkill!
You can use the Adafruit_BME280 library to calculate the altitude, from which you can derive the rate of descent. There is an example program called ‘bme280test’ that you can open in the Arduino IDE. There is a routine called ‘readAltitude(SEALEVELPRESSURE_HPA)’ which you can call to calculate the altitude. You can pass the standard sea level pressure of 1013 hPa.
 
Last edited:
I did a very similar project with a group of my physics students last year and I'd agree with what Voyager1 says above.

Set up your Arduino to sample the pressure sensor at regular intervals....try to get 10 or 20 samples per second. You'll get a lot of data and this is where the SD card comes in. Write each sample to the SD card. When finished, remove the SD card and put it in your computer. Import the file into Excel and create a column for velocity. The instantaneous velocity is just the difference in altitude (between successive samples) divided by the time interval between samples. You can even add a column for acceleration by taking the difference in velocity divided by the time interval. If you create a graph of altitude vs. time while under parachute, it should almost be a straight line with little to no acceleration -- you've reached terminal velocity. The slope of the line is also your velocity.

We actually flew our computers multiple times and we were very pleased with the results. I'd be happy to share our sketches with you.... let me know.
We didn't use GPS, but this could be useful in assessing the (horizontal) drift of your different parachute designs in varying wind conditions.

Best of luck. It's a fun project.
--MARK
NAR 65148, L1
 
Thank you both! Yes, Mark, I'd like to see your sketches. What baud should I run it at to get enough samples? 115200? I was going to use the gps to plot it in 3D in Google Earth (like my drone does).
 
Is there a routine that I could put in with a pushbutton to record the pressure before I start a flight to set the reference pressure? Different flight fields will be a different altitudes.
 
Is there a routine that I could put in with a pushbutton to record the pressure before I start a flight to set the reference pressure? Different flight fields will be a different altitudes.

You don’t need a pushbutton; just read ambient pressure when first powered up and store it. If you’re concerned it could change slightly over time you could replace that value every five seconds until your software detects launch. Your flight data is stored in a huge array and compared to the zero reference.
 
You don’t need a pushbutton; just read ambient pressure when first powered up and store it. If you’re concerned it could change slightly over time you could replace that value every five seconds until your software detects launch. Your flight data is stored in a huge array and compared to the zero reference.

My experience with a BME280: the value will fluctuate slightly while sitting on the pad due to air currents, etc. I have my display (rocket sends readings via lora radio packet to separate device I’m holding) show a running average prior to launch. Then just before launch I trigger the display to record actual readings and determine after the flight the base to use.
 
My experience with a BME280: the value will fluctuate slightly while sitting on the pad due to air currents, etc. I have my display (rocket sends readings via lora radio packet to separate device I’m holding) show a running average prior to launch. Then just before launch I trigger the display to record actual readings and determine after the flight the base to use.

That's what I was thinking about. Thank you
 
My experience with a BME280: the value will fluctuate slightly while sitting on the pad due to air currents, etc. I have my display (rocket sends readings via lora radio packet to separate device I’m holding) show a running average prior to launch. Then just before launch I trigger the display to record actual readings and determine after the flight the base to use.

As you say, it’s constantly fluctuating. Being inside the av-bay will filter out much of that, but averaging it over a sliding window of the few minutes leading up to the launch is probably good enough; after all, it’s going to continue fluctuating during the flight so picking a single value is no better than any other.
 
Ken,

I will PM you and we can set up a way for me to get your our sketch. Instead of the nano, we used an Adafruit Feather Adalogger which has the SD card slot right on the same board. Saved us a little space/weight. But, the sketch won't change much.

If you're concerned about the small data fluctuations you will see, the moving average that Steve Shannon talks about is a good way to smooth the data. It's a very simple form of a filter in the realm of digital signal processing. Personally, I would not recommend trying to do this in your Arduino sketch. Use the Arduino to collect and save your raw data and then do the moving average in Excel or some other program. You always want to preserve your raw data.... you may decide later that you don't need to smooth it or even change the way that you smooth it. If you do set up the moving average, there is a trade-off to be aware of: if you do it with too few samples, then you may not see much smoothing. If you do it with too many samples, you can begin to skew your results.

--MARK
NAR 65148, L1
 
Ken,

I will PM you and we can set up a way for me to get your our sketch. Instead of the nano, we used an Adafruit Feather Adalogger which has the SD card slot right on the same board. Saved us a little space/weight. But, the sketch won't change much.

If you're concerned about the small data fluctuations you will see, the moving average that Steve Shannon talks about is a good way to smooth the data. It's a very simple form of a filter in the realm of digital signal processing. Personally, I would not recommend trying to do this in your Arduino sketch. Use the Arduino to collect and save your raw data and then do the moving average in Excel or some other program. You always want to preserve your raw data.... you may decide later that you don't need to smooth it or even change the way that you smooth it. If you do set up the moving average, there is a trade-off to be aware of: if you do it with too few samples, then you may not see much smoothing. If you do it with too many samples, you can begin to skew your results.

--MARK
NAR 65148, L1


Thank you. Are there issues with the BMP280 and GPS trying to write at the same time? I assume the baud would be set the same for both. What's fast enough, 9600 or shall I set it at 115200?
 
Ken,

I'm not real familiar with GPS unit you mentioned and I need to go do a little research. It looks like it has an asynchronous serial connection, but hopefully someone else will chime in. 9600 bps should be fast enough, but at the very short distances you're dealing with, it could probably be run faster.

I'm not sure where you got your BME280 sensor, but these are usually supplied on a board that supports synchronous serial communication with the Arduino. The two most common are SPI and I2C. Some boards will do both. If your board has connections labeled MOSI, MISO, and SCK then it has an SPI interface. If it has connections labeled SCL and SDA, then it is set up to support I2C. These work in a master/slave arrangement and the Arduino is typically the master and the sensor is the slave (you can have multiple slave devices. Luckily, the Arduino can support both of these. You just need to get the right library when you set up your sketch.

Hope this helps.
--MARK
 
Ken, One final thought on this. On your question about the BME280 and GPS trying to write at the same time.....this really should not be an issue. The sensor and GPS unit will not really write to the Arduino. The Arduino will read data from those devices at the interval you set up in your sketch. While the GPS unit may transmit data asynchronously, the Arduino will only read the data when you tell it to with your sketch (it doesn't look like this particular GPS unit can generate any type of interrupt or other signal to indicate that data has changed). You could use the timestamp from the GPS module and then read your pressure sensor immediately. You could then use that timestamp with the LAT, LON, and pressure reading. Make sense?

In doing a little research on your GPS module, I found this tutorial online for interfacing it with Arduino and using the serial library:
https://randomnerdtutorials.com/guide-to-neo-6m-gps-module-with-arduino/

--MARK
 
My experience with a BME280: the value will fluctuate slightly while sitting on the pad due to air currents, etc.
The measured pressure values can sometimes also fluctuate if exposed to light. It depends on which sensor you are using, as some are less sensitive to this than others. Keep that in mind when building and flying the electronics.

Also, as per what Mark said above, the processor needs to read both sensors and assemble the relevant data stream to write to the SD card somehow. That is how arbitration is normally handled in this situation.
 
Ken, One final thought on this. On your question about the BME280 and GPS trying to write at the same time.....this really should not be an issue. The sensor and GPS unit will not really write to the Arduino. The Arduino will read data from those devices at the interval you set up in your sketch. While the GPS unit may transmit data asynchronously, the Arduino will only read the data when you tell it to with your sketch (it doesn't look like this particular GPS unit can generate any type of interrupt or other signal to indicate that data has changed). You could use the timestamp from the GPS module and then read your pressure sensor immediately. You could then use that timestamp with the LAT, LON, and pressure reading. Make sense?

In doing a little research on your GPS module, I found this tutorial online for interfacing it with Arduino and using the serial library:
https://randomnerdtutorials.com/guide-to-neo-6m-gps-module-with-arduino/

--MARK

I've been testing with the examples in the Arduino IDE. Trying to merge three (GPS,SD,Baro) is the bugger. Still working on it. Been using it SPI.
Ken, One final thought on this. On your question about the BME280 and GPS trying to write at the same time.....this really should not be an issue. The sensor and GPS unit will not really write to the Arduino. The Arduino will read data from those devices at the interval you set up in your sketch. While the GPS unit may transmit data asynchronously, the Arduino will only read the data when you tell it to with your sketch (it doesn't look like this particular GPS unit can generate any type of interrupt or other signal to indicate that data has changed). You could use the timestamp from the GPS module and then read your pressure sensor immediately. You could then use that timestamp with the LAT, LON, and pressure reading. Make sense?

In doing a little research on your GPS module, I found this tutorial online for interfacing it with Arduino and using the serial library:
https://randomnerdtutorials.com/guide-to-neo-6m-gps-module-with-arduino/

--MARK

Using the timestamp from the GPS was a thought, since it would be more accurate and the antenna for the GPS is exposed outside of the electronics bay so it can see the sky. I just need to translate all this advice into actual sketches. Not that experienced with the commands for each device.

Thank you.
 
GPS is touchy and a pain to get to work well in high dynamic environments like a rocket flight. Here's a link to learn more about programming your UBLOX NEO over serial: https://playground.arduino.cc/UBlox/GPS

It took me quite a bit of testing to get it working correctly, but I now get high-quality GPS data throughout the entire flight. With only the default settings, you will lose lock immediately and will probably get it back sometime after apogee, about a minute or so. If you want my code, look for it here: https://github.com/SparkyVT/HPR-Rocket-Flight-Computer

As for timestamps, you absolutely do not need GPS to calculate the descent rate, if that's all you need. Using the clocks onboard the chip is the easiest way. The clock starts immediately when power is applied, and you can access the time using the micros() command. Just get the clock timestamp at each barometric sample and compute the math between. No need to go through the pain of programming a GPS.
 
GPS is touchy and a pain to get to work well in high dynamic environments like a rocket flight. Here's a link to learn more about programming your UBLOX NEO over serial: https://playground.arduino.cc/UBlox/GPS

It took me quite a bit of testing to get it working correctly, but I now get high-quality GPS data throughout the entire flight. With only the default settings, you will lose lock immediately and will probably get it back sometime after apogee, about a minute or so. If you want my code, look for it here: https://github.com/SparkyVT/HPR-Rocket-Flight-Computer

As for timestamps, you absolutely do not need GPS to calculate the descent rate, if that's all you need. Using the clocks onboard the chip is the easiest way. The clock starts immediately when power is applied, and you can access the time using the micros() command. Just get the clock timestamp at each barometric sample and compute the math between. No need to go through the pain of programming a GPS.


Thank you for the info. I d/l your info and will look at it. I really only need rate of descent for my testing, so the more accurate it can be the better.
 
I'm using an i2C interfaced GPS unit with an Arduino pro-micro to good effect. See this great breakout from SparkFun: https://www.sparkfun.com/products/14414. Using the i2C interface is much easier than using a serial interface with the GPS. Combined with a LoRa radio transciever unit, it provides me with GPS location data for rockets lost in the weeds.
 
I'm using an i2C interfaced GPS unit with an Arduino pro-micro to good effect. See this great breakout from SparkFun: https://www.sparkfun.com/products/14414. Using the i2C interface is much easier than using a serial interface with the GPS. Combined with a LoRa radio transciever unit, it provides me with GPS location data for rockets lost in the weeds.


Thanks for the info. I was thinking about incorporating a LoRa radio for realtime viewing. Would you mind sharing your sketch for that?
 
Thanks for the info. I was thinking about incorporating a LoRa radio for realtime viewing. Would you mind sharing your sketch for that?
I'll post it to github next week (sad to say, the sketch is on another computer and I won't have access until next week). The whole unit, with baro for altitude, combined LoRa/Pro-Micro Arduino (https://www.sparkfun.com/products/14785), GPS breakout and small LiPo battery, fits on a plywood board that is only 33.88 mm wide. Weighs 24 grams.
 
I'll post it to github next week (sad to say, the sketch is on another computer and I won't have access until next week). The whole unit, with baro for altitude, combined LoRa/Pro-Micro Arduino (https://www.sparkfun.com/products/14785), GPS breakout and small LiPo battery, fits on a plywood board that is only 33.88 mm wide. Weighs 24 grams.


Thanks again. That looks pretty sweet. I'm still working on my latest parachute to test. Kinda hard getting a good seamstress around here.
 
My code also uses LoRa, GPS, and some other sensors. You can steal some snippets from there too. The link is in my prior post.

Nice code!

I see you use EEPROM, which is missing on the pro-micro. For non-volatile memory in my flight computers, I use FRAM (https://www.adafruit.com/product/1895) which is nifty because it also uses i2C. I much prefer recording flight data on non-volatile memory to recording it on SD. Non-volatile (whether EEPROM or external like FRAM) gives you easy random access.
 
I really only use EEPROM to store the sensor calibration settings and max speed/altitude from the previous flight.

Yes, there are definitely advantages to non-volatile memory. However, I record megabytes of data each flight; EEPROM & FRAM aren't good for that much storage. eMMC would do the trick, but I'm not the greatest at SMD soldering, and I can't find any breakout boards for eMMC. I like breakout boards and through-the-hole components because they are easier to place & mount, plus I don't have to design and print my own PCBs (though I just did exactly that for my latest project).
 
Thank you for the info. I d/l your info and will look at it. I really only need rate of descent for my testing, so the more accurate it can be the better.

While several people have pointed out that GPS is not necessary for timestamping, in fact you do not need any timestamps at all. Calculating descent rate uses the difference in timestamps to provide the time interval between altitude samples - but you already know that interval because you set up how fast the the BME280 is being sampled. i.e. if you set it up to be sampled every 100mS, then that is what you would use for the interval.
 
Back
Top