2nd Successful Launch!
First - I’ll start by defining successful:
We launched the rocket, and it came back to us, in a condition where it could be safely flown again.
Launch 2 - First Radio Launch
This Launch took place on June 4th, and was our first launch carrying the radio payload. For those not up to speed, this included both an APRS tracker, transmitting APRS data, and a LoRa radio, transmitting telemetry data. To receive the transmissions, we built a ground station that has been detailed in previous posts, that used a LibreComputer LePotato, with an SDR dongle receiving the APRS data and running Direwolf as a network TNC, and an Adafruit feather with a LoRa radio receiving the LoRa data. The LePotato was then running node red to give us a dashboard of the telemetry data.
Overall, it was success!
As with any success, we had quite a few learnings as well, since this was our first launch where we were collecting and sending live data, so following is a list of things we noted, along with some data / charts / images / etc. that demonstrate what we’re referring to.
Warning this post is rather long…
Engine retainer popped off
just like last time, our engine retainer popped off, but this time I think it was due to a somewhat hard impact upon landing, because the engine casing itself was still in the rocket, and the retainer ring was on the ground right next to it. This one I believe was a 2-part issue.
- The first is the thickness of the spacer in the retaining ring, so we’re just going to lay out the $30 and buy the purpose-built part (we had been using a $7 knock-off).
- The second cause of this, is that based on our data, our descent was about twice as fast as expected. Based on our modeling we were expecting a landing at about 18 feet per second, but based on our flight sensor data, the rocket was coming down at about 36 feet per second. The most probable cause of this, is the fact that one of the two parachutes hadn’t opened fully, as can bee seen in this screen grab from our video (we’re just lucky it landed within the frame of the camera!):
Node-Red dashboard struggles to keep up with packet rate
This could be caused by several things, and we’ll have to do some experiments to figure it out. If you watched the video, you may have noticed that the gauges only update once every 4 packets, which is about once per second. This was a purposeful delay that was added because of the dashboard’s struggle to keep up when updating every 250ms.
Node red handles the actual packets fine, because it does log them all, and there are no missed packet in the logs - it seems to be specifically something in displaying them, which could be node red itself, or the browser that we view them on, the capabilities of the single board computer, or the machine the browser is running on, etc. It will be nice to figure something out here, so that we can see the ‘live data’ a little clearer. Luckily we can get everything we need for the fun data analysis from the logs on both the ground station, and the rocket itself. This will give us plenty of time to poke at options for making the dashboard ‘more live’.
Node-Red dashboard design items
After using the dashboard for a live launch, there are some tweaks that I’d like to make, to the general UI.
- Update the ‘scale’ on some of the gauges and charts to make changes easier to spot
- Move the gauges to a secondary section, and bring the line charts to the primary view - seeing the history in the line charts seems to give a better understanding of what is going on.
- Adjust the history displayed. The flight is short, so we should probably just update the number of historical data points to reflect 2 or 3 minutes worth of time, since at the end of the flight, we’re most interested in the very short duration of the flight, and maybe just a few points before launch.
- I’m also tempted to change the dashboard so that it doesn’t start displaying the received data until about 2 minutes prior to launch, but I’m on the fence with this.
Local audibles & social (mastodon) posts need tweaked
If you listen closely to the lead video, you can hear that after launch there are some audible status announcements. These are essentially the same things that get posted to Mastodon for live updates. Right now they are rate limited by time, but they still got a little ‘behind’ as they were read out. I think instead of doing them timed, we may adjust them so that they are only at specific events - i.e. Launch detection, Apogee Detection, Separation, and then at specific points during descent (maybe every 100 feet or something like that.)
Local audibles hard to hear
There are spoken status announcements throughout the process. Just via the laptop speaker however, they are hard to hear. It might be nice to add an external speaker or something, so that they are much louder, and able to be heard by bystanders, instead of only at the launch control point.
APRS data - height above terrain < 0 feet
The APRS data packet includes a Height Above Terrain number. This is deduced using barometric pressure, but due to fluctuations during start up, sometimes it reports -1 or -2 feet. I should just code in to hold it at 0 in these cases.
APRS packet data rate
Because a rocket moves fast, we wanted a much higher than usual APRS packet data rate. We set up our packets to transmit with no path, so that we wouldn’t flood an area with packets. I’m still not 100% comfortable though with the number of packets we generated while the rocket was sitting on the pad, and after landing. I think we might tweak up the code so that we only send 1 packet every several minutes, and then at detection of launch, we increase the rate to the max the device can do, and then after touchdown decrease the rate again. The lightAPRS tracker has an on-board pressure sensor, so the pressure readings can be used to detect altitude change, and therefor detect launch… or …
Get Sensor Data to the APRS tracker
In theory I could, via SPI or serial, send data from the lora sled to the APRS sled in the rocket, so that the APRS packets could include some of the other telemetry data, or so that we could do various APRS ‘things’ based on events detected by the LoRa and sensor sled. Doing this would be easier if I…
Combine APRS and LoRa onto a single sled?
I made them two different sleds in case I wanted to use just one or the other, in other rockets. Putting them together however, on one sled, or at least back to back so the can be connected easily, would make the item above much simpler.
Turn ground station antennas sideways
Once the rocket launches, it is essentially directly overhead. I was able to observe the drop in signal strength once the rocket was ‘off the tip of the antenna’ vs. broadside to it. I don’t recall who it was, but someone in the audience at my QSO Today presentation gave me the idea to monitor this, because they speculated that this could be the case. The drop in signal strength wasn’t enough to cause any issues, but it was interesting to observe:
Pre-Launch Signal Strength
Post-Launch Signal Strength
Sensing Separation needs tweaked
If you have sharp eyes, you may have noticed that the indicator for ‘separation detected’ was on the whole time. This is done with a light sensor - usually as I powered up the LoRa sled I would keep my finger over the hole in the coupler, until I slid everything together, but I forgot to do that, so it ‘sensed’ light, i.e. separation, right away. A quick fix would be to issue reset commands to everything once the rocket is on the pad. A better fix might be to tweak the code to check for the launch condition before checking for this condition (I thought I had done that, but apparently not.)
Max Acceleration / G-force reading on dashboard
The dashboard recorded our Max G as 2.2 or so, but in reality Max G was actually 9.8. This is because, in the node-red code, I forgot to account for the fact that G-Force needs to be based on an absolute value, because the G-Force can happen in a ‘negative’ direction. See Sensor orientation & data section, coming next:-)
Sensor orientation & data
This is something that I’m currently ‘on the fence’ about. Right now all of the code just uses the ‘orientation’ of the sensor on the board, because while doing the initial programming, I wasn’t fully sure in which ‘direction’ the sensor would be mounted. Now that we have them in, and are using the data, I’m debating where, if at all, in the software I’d like to ‘adjust’ so that the sensor readings align with ‘real world’ (i.e. Y being up, X & Z being planes ‘on the horizon’). A good example of this is in the accelerometer data. You can clearly see the big ‘spike’ at launch when the motor fired, fairly stable readings while the rocket coasted, and then another small spike when the ejection charge fired. The big spike however, reads a negative number because of the orientation of the board in the rocket. I’m still deciding if I care enough about this to change it :-)
Having logs of the data on both the rocket and the ground station was awesome - maybe log even more of the data.
logging the data in both places was nice because it helped us confirm the timing of some stuff, and gave us multiple places to look. Below are some charts of the raw data, which are fun to look at because you can ‘see’ some of the key events in the sensor data, as highlighted below. One of the interesting things (to me anyway) is how you can almost visualize the ‘arching over’ at apogee in the gyro and magnetometer data.
And some other misc. stuff
While not mission critical, there are some things that have come up, that I’ve thought would be handy
- Stick a bullseye level on launch pad’s rail support, to make it easier to be sure the launch pad is level and straight
- I may want to at some point build a more deliberate ‘Rocketry Go-Kit’ with two primary components:
- A single integrated ‘ground station’, like a road case that would house the ground station, batteries, launch controller, etc.
- Something to ‘hold the stuff’ - i.e. some kind of organized kit to hold and carry all of our supplies, like maybe one of those sets of tool cases that stack together where the bottom one has wheels, so they can be moved around like a hand-truck.