Help Plz. Arduino to calc rate of descent.

the rocketry show
Advertise with us
Shop deals on ebay
The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
SparkyVTFlyer said:
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).
Click to expand...
Wow, megabytes! You must be recording video too. I just record altitude, acceleration and GPS Lat and Long. At a 20 hz frequency, that's very little data. I do, however, use the non-voaltile to hold certain parameters for my code as well.
 
Ha! No video. I record three sensors in three axes at 1000 samples per second. I also capture integrated 3D rotation, speed, and altitude at the same rate. I record pressure altitude, magnetometer readings, and GPS at lower rates.

Over LoRa on standard settings I'm able to send events, time, integrated alt, integrated speed, baro alt, 3D rotation, acceleration, GPS alt & GPS location at 20 samples per second (GPS is really at 8 SPS). Capturing that data over the air really comes in handy when your rocket shreds into a ba-zillion pieces after going sideways at Mach 2.0+
 
hartlch said:
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.
Click to expand...


Good Point.

Ken
 
SparkyVTFlyer said:
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.
Click to expand...


Very good. I'll try that. Rate of descent is all I need, but GPS would be nice. Will throw it into GE for kicks.
Ken
 
Ken Wilkins said:
Very good. I'll try that. Rate of descent is all I need, but GPS would be nice. Will throw it into GE for kicks.
Ken
Click to expand...
In my code, I have:

descent_rate = apogee / ((flight_duration - apogee_time) / 1000.0)

apogee in feet
flight_duration, apogee_time in milliseconds
 
Don't forget that there will be a period of time after apogee where it will not be falling at the rate you are interested in because the parachute takes some time to fully open and stabilize. One advantage of just collecting the altitude data and importing it into a spreadsheet is that you can play around and select the data of interest visually to pick out the linear portion.
 
hartlch said:
Don't forget that there will be a period of time after apogee where it will not be falling at the rate you are interested in because the parachute takes some time to fully open and stabilize. One advantage of just collecting the altitude data and importing it into a spreadsheet is that you can play around and select the data of interest visually to pick out the linear portion.
Click to expand...

Well, that may be challenge. I'd want to ask the pilot (or if I cert & fly my own) to let it freefall to about 400' before popping the chute. I need it to go as fast as possible because I'm interested in how fast it decelerates. Testing parachute designs. As in which one slows the descent quicker.
 
Ken Wilkins said:
Well, that may be challenge. I'd want to ask the pilot (or if I cert & fly my own) to let it freefall to about 400' before popping the chute. I need it to go as fast as possible because I'm interested in how fast it decelerates. Testing parachute designs. As in which one slows the descent quicker.
Click to expand...

If your real reason for doing this is to test parachute designs, why not just adopt one of the many really good rocketry altimeters which already log altitude, velocity, and barometric pressure?
 
So, in my sketch, I'm getting the pressure in the serial monitor. How do I convert that to feet altitude? I'd put in a line for the sea level pressure and subtract my pressure? What's the calc for the sketch?
 
Last edited:
Ken Wilkins said:
So, in my sketch, I'm getting the pressure in the serial monitor. How do I convert that to feet altitude? I'd put in a line for the sea level pressure and subtract my pressure? What's the calc for the sketch?
Click to expand...
Use the international barometric formula to get meters in altitude:

upload_2018-11-26_8-51-54.png
 

Latest posts

Back
Top