Nothing like an extra week of competition and some great competitors to provide motivation... Father's day was launch day for flight 2 and with one exception it was a success! A 36" nylon parachute from Apogee Rockets was just the ticket for a safe return to earth.
I started with a slight redesign of the 3D printed base (updated files included with this blog post) to strengthen it and to move the parachute mount to its centerline. Threaded rods replaced screws so that I could secure the entire stack-up of base and Featherwing PCBs. Grommets were added as a shock absorber to the screws holding the parachute mount in place.
Printing
Drilled
New Features
New Parachute and Mount
With the rocket back together I spent some time with my code. I'm not entirely sure about the mbed OS pre-emption model, specifically if threads of the same priority can be suspended at points other than an explicit release of control with a wait or yield, so I made a slight change to the StringFifo to protect against pre-emption while checking how many bytes are available. The big find, however, was had by monitoring profiling outputs (P4_0 and P5_6) on a scope and finding that writing to the Micro-SD card is slow and expensive (time-wise) which explained why I lost data during the first flight. [This kind of debugging sound familiar avitron?!?
]. In the scope trace below the red trace is an output that is high while in the fprintf to write data (Micro-SD writer thread). Usually the call takes ~20 uSec but occasionally it requires ~52 mSec as the buffered data is written. The yellow trace is the active time inside the accelerometer thread executing every 10 mSec. Each measurement and associated push of data requires about 450 uSec. The Micro-SD writer thread is executing about every 5 mSec in this capture because it is trying to keep up with the accelerometer and light sensor threads, each executing every 10 mSec. It was immediately clear that my write process can't keep up and eventually the FIFO between it and the sensors overflows. Fortunately it yields the thread during the long write or I would have been back to the drawing board. My quick fix is to a) take advantage of the large amount of RAM in the MAX32630 and allocate 256 kBytes to the FIFO and b) cut the default recording time to 60 seconds as a back-of-the-napkin calculation showed I won't overflow the larger FIFO during that time. A better solution will need to eventually be found but this one worked and I recorded all data. The mbed project from the earlier blog post has been updated.
Threads in action
Finally I took the rocket outside and added a make-shift light box of electrical tape around the light sensor with just a sliver opening to reduce the amount of light hitting it on these sunny launch days. As you can see from the data graph below my hack was successful, the rocket doesn't rotate much - which we verified with video in slo-mo. But the light sensor still needs to be improved. Probably by scaling the output voltage more with an external resistor divider.
Launch is nothing compared with ejection!
I pulled the temperature sensor further outside the nose cone and got slightly more interesting data this flight. It measured a decrease of about 5 degrees F from ground temperature to the apogee of flight.
Unfortunately the GPS failed again so I still don't know how high the rocket flew. This time I was able to correlate loss of fix with the starting of recording. There will have to be further investigation to see if there is some strange code problem or perhaps some additional electrical noise that causes the receiver to lose fix.
The rocket was completely undamaged and will fly again. Just have to figure out what's going on with the GPS. And to find a bigger engine so it will really soar!
I started with a slight redesign of the 3D printed base (updated files included with this blog post) to strengthen it and to move the parachute mount to its centerline. Threaded rods replaced screws so that I could secure the entire stack-up of base and Featherwing PCBs. Grommets were added as a shock absorber to the screws holding the parachute mount in place.
Printing
Drilled
New Features
New Parachute and Mount
With the rocket back together I spent some time with my code. I'm not entirely sure about the mbed OS pre-emption model, specifically if threads of the same priority can be suspended at points other than an explicit release of control with a wait or yield, so I made a slight change to the StringFifo to protect against pre-emption while checking how many bytes are available. The big find, however, was had by monitoring profiling outputs (P4_0 and P5_6) on a scope and finding that writing to the Micro-SD card is slow and expensive (time-wise) which explained why I lost data during the first flight. [This kind of debugging sound familiar avitron?!?
]. In the scope trace below the red trace is an output that is high while in the fprintf to write data (Micro-SD writer thread). Usually the call takes ~20 uSec but occasionally it requires ~52 mSec as the buffered data is written. The yellow trace is the active time inside the accelerometer thread executing every 10 mSec. Each measurement and associated push of data requires about 450 uSec. The Micro-SD writer thread is executing about every 5 mSec in this capture because it is trying to keep up with the accelerometer and light sensor threads, each executing every 10 mSec. It was immediately clear that my write process can't keep up and eventually the FIFO between it and the sensors overflows. Fortunately it yields the thread during the long write or I would have been back to the drawing board. My quick fix is to a) take advantage of the large amount of RAM in the MAX32630 and allocate 256 kBytes to the FIFO and b) cut the default recording time to 60 seconds as a back-of-the-napkin calculation showed I won't overflow the larger FIFO during that time. A better solution will need to eventually be found but this one worked and I recorded all data. The mbed project from the earlier blog post has been updated.Threads in action
Finally I took the rocket outside and added a make-shift light box of electrical tape around the light sensor with just a sliver opening to reduce the amount of light hitting it on these sunny launch days. As you can see from the data graph below my hack was successful, the rocket doesn't rotate much - which we verified with video in slo-mo. But the light sensor still needs to be improved. Probably by scaling the output voltage more with an external resistor divider.
Launch is nothing compared with ejection!
I pulled the temperature sensor further outside the nose cone and got slightly more interesting data this flight. It measured a decrease of about 5 degrees F from ground temperature to the apogee of flight.
Unfortunately the GPS failed again so I still don't know how high the rocket flew. This time I was able to correlate loss of fix with the starting of recording. There will have to be further investigation to see if there is some strange code problem or perhaps some additional electrical noise that causes the receiver to lose fix.
The rocket was completely undamaged and will fly again. Just have to figure out what's going on with the GPS. And to find a bigger engine so it will really soar!
