First - the plugs:

support some repeaters financially, or with donations of equipment, or by connecting an existing repeater to the Pride Network

Buy some cool stuff to support my passion projects!

Ponzu Launch Report

Hey folx! We had a very successful launch of Ponzu (Radio Rocket v3) on June 13th!

The first week after school lets out each year we do “Daddy Camp” which is basically a week of backyard camping and summer camp type activities - one of the mornings was set aside for Rocket launching, so we launched 7 rockets, including Ponzu, and it was a smashing success!

First, the details on Ponzu for this flight:
Height: 109.86cm ; 43.25” Diameter: 41.6mm ; 1.64” (BT-60 sized tube)
Launch Weight, w/o Motor: 487g ; 17.18oz
Recovery: 30” parachute
Paint: Gold on the bottom 2/3, fading to blue with a spattered fade
Telemetry: Magnetometer, gyro, acceleration, barometric pressure, altitude, and messaging via LoRa on 434MHz. Motor: G53FJ, 9 Second Ejection Delay
Launch Weight:634g ; 22oz
Altitude: 588.92m ; 1929ft
Max Velocity: 324kph ; 201mph
Max Acceleration: 179m/s^2 ; 18g (641.02m/s^2 ; 65g at parachute deployment)
Flight Time: 132s

This was our most impressive radio rocket flight to-date, in pretty much all regards - fastest speeds and highest altitude due to the new rocket and electronics design, AND the rocket was successfully recovered! There were only a couple things that went ‘wrong’ during this launch, which I’ll detail in a bit, but first, let’s do the exciting bit - launch videos!

Ponzu (Radio Rocket v3) Launch Video

All Launches From the Session

Retrospective & Lessons Learned

As I tend to do for these launch reports, I’m just going to throw down the bullets of what we learned/things we might change for the future etc.

• I had my laptop along to let the very youngest watch some Daniel Tiger during the setup etc. between launches. That went a long way towards keeping the tiniest members of the flight crew from going feral on us during the session:-)

• We forgot our magnet to turn on Ponzu’s payload from outside the rocket, so we had to do a weird half-disassembly maneuver while the rocket was on the rail, to push the internal power button. It worked, but for the future we’re going to buy a bunch of big magnets on sticks to keep in the box, in my office, in the car, etc. so that we don’t have just 1, and leave it behind somewhere. The kid have some of these (associate link) at their school that they use for some lessons. They are nice and chunky and hard to loose, so we’ll probably order a package of these to have around in some strategic places.

• We need to fiddle with the colors on the ground station’s touch screen to try to get maximum visibility outdoors. The current colors were a scheme that are considered high contrast, but outside it was still a little hard to see. I may need to just take it out in the back yard on a sunny day and play with colors till I find a combo that works well.

• We need to tweak the code that generates the ‘velocity’ portion of the data. You may have noticed the dashboard didn’t show any velocity data on the velocity gauges - that is partially because I used units (cm/millisecond) in the code that turned out to not be quite granular enough. I’m updating that code to measure in mm/millisecond which gives more granularity/precision. I use weird units like that in the code, so that I can use integers in all the calculations (which the microcontroller can do faster), and the multiply up/divide down to more standard units in the dashboards for final display.

• We had a much longer walk than planned - the rocket actually landed one farm over from our launch site, but luckily it was a farm where I know the farmer because we have kids the same age, and talk regularly enough that I was comfortable flagging him down in his field so that we could hike out through the hay he was raking to retrieve the rocket. Since we’re flying higher now, I probably need to invest in a Chute Release device (associate link). These slick little things basically use a rubber band wrapped around the parachute, to keep the parachute reefed when it deploys, so that the rocket will fall faster down to a set altitude before releasing the band and allowing the parachute to unfurl. This keeps the rocket from drifting too far during it’s descent.

• For part of the ascent we didn’t get any telemetry (you can see several seconds in the video where no telemetry is received.) For now I’m going to blame that on our temporary antenna situation with the new ground station. Since the new ground station isn’t quite complete, the antenna was just sort of thrown on the table dangling from it’s little coax jumper, instead of being mounted. We may even switch to an egg-beater or even a directional antenna mounted via the mast-holder that we put on the side of the ground station box.

• I think we’ll add 2 meter APRS back into our next flight. Luckily visibility was good, but we were high enough that we could have easily lost sight of the rocket, making it hard to find without some location tracking.

• OR we may look into LoRa APRS - that’s a thing now, and since we already have LoRa on-board, if it isn’t too difficult burping out periodic LoRa APRS packets might help us keep the weight down instead of adding an additional device. That will be pretty contingent though on the infrastructure around here - I’m not sure how many, if any, LoRa igates or digipeaters are around my area.

• I want to get our AREDN setup finalized, so that we can ‘send our data home’ via AREDN, and then do the live tooting and site updates from our home internet connection, based on the data received through the AREDN devices.

• We’ll be ready to finish/tidy up the back panels etc. of the new ground station now that we know everything works pretty well.

• We’ve got some options for adding on-board cameras laying around here, so we’ll try to work on that for some of the upcoming launches. We have a couple little ‘dongle’ cameras that we could attach, and I’ve also dabbled with ESP32 cams, so this could end up being either a recording that we retrieve later, or a live stream of video during the launch itself (or both?!)

• Video, screen-grabs, helpers, etc. rocket flights are so short, that having lots of video, screen grabs, etc. helps when reviewing stuff post launch. I might try to rope in some more helpers, and more devices, in the future, to try and capture more video, dashboard stuff etc.

• Dashboard playback - after this flight I whipped up a python script that will basically “play back” the telemetry data, so I can tweak up the dashboard and stuff and test with real-time data now, for future updates.

• Max Acceleration data - The max acceleration recorded was actually at parachute deployment - I may tweak the code so that it shows “Max acceleration during ascent” since that’s what we’re after more than what the sensors read when the rocket blows its sections apart for recovery deployment.

• Radio Rocket v4? I may start ‘building’ another series of radio rockets in parallel to the continued work on v3 and future iterations of the Radio Rocket. I’m thinking something along the lines of a “Radio-Rocket-Lite.” A lot of people have been interested in this project, and I’d like to do a much more simplistic version where I can put together a step-by-step of; go buy X rocket kit, X tracker, connect it to a battery, load X firmware, and go launch it!

Wrap up

This will wrap up this post for now, but I may come back and edit it, or write a follow up, as I continue analyzing the data. I’ll have some charts and such to share, which are always fun too!

Radio Rocket V3 Electronics Payload

I suppose it’s time to do an update on the status of the electronics payload for version 3 of the rocket, to bring all 7 of my loyal blog readers up to speed :-) I share a bunch of ad hoc stuff on Mastodon so if you follow the rocket there, you’ve seen some of this info already.

I shared in my last post that one of the major changes for version 3 was the decision to move away from ‘breakout boards glued and screwed to a piece of wood’ construction, and to instead do custom designed PCB carriers, so that the sled would also be the electronics bus, to replace all the wires.

For me, the first step of doing this was learning how to use KiCad, but after a week or so I was zipping around in there, and eventually ordered up my first batch of boards:

As expected, I did find some bugs, problems, and things to redesign from the first batch of boards, that I fixed up for bench testing by cutting traces and adding jumpers, and things like that:

I also ended up switching to a shorter battery type (switched from using 18650 to 18350), so that I could shorten up the battery carrier sled, in order to standardize the length of the rectangular carrier boards:

After doing the redesign, I ordered up another batch of boards, which are now the versions currently in use. This new selection of boards is:

• Circular boards, starting at the top left and going clockwise:
  • BT-60 (41.5mm) Tube Size Spacer / blank adapter
  • Carrier for ‘6 pin’ Adafruit breakout boards (like the LSM6DSOX 6 DoF Accel/Gyro and ADXL375 High G Accelerometer)
  • Carrier for ‘7 pin’ Adafruit breakout boards (like the BME 680 Temp/Humid/Pressure/Gas board)
  • Antenna mount and Diplexer board (to allow VHF aprs & UHF LoRa to share an antenna)
  • ‘Trigger’ board (mosfet based trigger to fire ignitors, or turn other accessories on and off)
  • ‘Perf Board’ which allows me to do some experimentation of small circuits
  • 38mm Tube Size Spacer / blank Adapter
• Rectangular boards, left to right:
  • Micro Controller Carrier (for the Teensy 4.1)
  • Battery Carrier and power switching
  • LoRa Radio breakout carrier (for the Adafruit RFM96w)
  • LightAPRS tracker carrier (for the LightAPRS 2 or LightAPRS-W 2)

And after flowing some solder to start assembling things, it’s coming together nicely! I still have a couple items to do yet on the sled (adding a couple modules and sub-boards that are still on the way) but it’s technically ‘working’ now, and fits nicely inside the payload bay of the under-construction rocket!

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.

1st 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 1

The first launch happened on May 28th, at roughly 10am local time (14:00utc). The first launch didn’t actually carry the radio payload, but was instead a ‘test’ launch to make sure the rocket itself would behave like, well, a rocket :-)

We followed our checklist however, as though we were going to include the payload, and then just left it out, so that we would have 1 last shot at ironing out any kinks in our prep and setup. The good news is, that all of that went very well!

Since this was our first ‘live launch’ of the rocket, we were hoping to learn anything we needed about the launching of the rocket itself, our new launch pad, and the fly away rail-guide, which we had never used before. Again, all of that went pretty much exactly as planned, with just one notable exception:

• The retaining ring that holds the engine in, actually popped off when the ejection charge fired, and while the parachutes still deployed, the motor casing also ejected out of the back of the rocket. Luckily the ring and motor casing were both found during a post-launch sweep of the area.

I can’t say for sure, but I believe this happened due to the motor adapter that we were using. The rocket is built to accept up to a 38mm motor, but we were launching with a 29mm motor, so there is a spacer tube that the engine slides into, and then another spacer that fits between the back of the motor and the ring. This rear spacer was a pre-fabbed plywood ring, and due to it’s thickness, the retaining ring that screws on probably only had 1 or 2 ‘threads’ worth of bite.

• Our fix for this will be to replace the wooden retainer with a washer that has the correct inside and outside diameter, but is much thinner, to allow the retaining ring to thread on further. Additionally, we may also order a different pre-made adapter from a different company, that uses a slightly different design, which is more purpose built and looks to have flanged pieces that can nest together without taking up ‘thread’ room.