Clubs that are so inclined, should use the opportunity to show that their club is welcoming to everyone, by flying the colors at their field day site! To encourage promotion of Pride at Field Day sites, I’m going to do a little last minute contest!
The Biggest, Boldest, Pride Display at a Field Day Site Wins!
To ‘enter’ send your pictures of your Field Day Pride Display to:
n3vem.radio@gmail.com
or post them to mastodon and tag me, @n3vem@mastodon.radio, in the post.
The winner will be chosen by a distinguished panel of judges (my family!), and will be able to choose any 3 clothing items from my Subversive Radio Shop to give to the members of their club or group that they think would most appreciate them!
fine print - winners will only be chosen from places I can ship too - see the shop for details on shipping locations for clothing items. All Items must be shipped to a single address, with the winner taking care of distributing the items to their club/group members on their own. Pictures should include enough in-frame to make it clear that the display is at an ARRL Field Day site.
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!
Last night was my first time ever being net control! I volunteered to host a monthly net for the Narwhal Amateur Radio Society (NR7WL), of which I am a proud member. The Pride Radio Network graciously has allowed us to connect our hub to their network, so that our members (and non-members!) can connect via the plethora of bridges they have set up (DMR, YSF, D-Star, P-25, NXDN, Allstar, Echolink, etc.)
Because I figured we’d probably only have a handful of check-ins for this first time around, I decided to do the net “E-Cars” style, where as net control, I’m on for the hour, and just put out periodic calls for check-ins. I felt like that went very well, and it made me wonder why more repeater-based and network-based nets don’t run in that style, instead of the “be here at the exact right moment” variants.
I felt like it makes it easier for participants, because they can show up whenever they want during the hour, and it takes the pressure to feel like the airtime has to be filled up, off the net control and other participates. Instead, it makes it a time where you just kind of hang out, call for check-ins periodically, and either chit chat with folx who checked in, or wait quietly while multi-tasking between check-ins, based on whatever the net control, participants, and vibe for the net seem to dictate.
Anyway - I had a blast! If you’re potentially interested in checking in in the future, here are the net details:
Time: 1st Tuesday of Every Month at 7pm Pacific, 10pm Eastern
Location: Hosted on the NR7WL Allstar Node (61672), the N3VEM Repeater (Allstar 56001 & Echolink 994842), and the Pride Radio Network.
We’d like to specifically thank the Pride Group for allowing us to connect our hub to their system - The Pride Radio Network enables club members and non-members wishing to check in to connect via DMR, System Fusion, D-Star, IRLP, Echolink, M-17, NXDN, P-25, Hams over IP, Hamshack Hotline, plus some others. Be sure to check out the Pride Radio Network site as they regularly make updates and improvements to their network.
If you want to join the net via Allstar, you can simply point any Allstar enabled repeater, hotspot, or VOIP application at node 61672 during the net. If you’d like to connect via any of the other modes mentioned, please visit the Pride Radio Network Information Page for details on node numbers etc.
The NARS Club Net is a directed net, and also serves as a 1 hour time slot where net control will be monitoring the hub even if there are no check-ins. This means that folx can feel free to check in at any point during the hour that works for them; just tune in and listen for the preamble and call for check-ins which will be repeated periodically, or throw out your callsign if a few minutes goes by and you don’t hear anything.
When checking in, feel free to share your name and location as you are comfortable (or not), answer the net question, and/or share anything else that is on your mind. We strive to be welcoming and accommodating, so don’t worry about whether or not you are ‘doing it right’ - with us, you’re always doing it right as long as you’re following the guidelines of your license and having fun!
It’s been a busy few months, and the folx who I interact with on Mastodon already know that I’ve got lots of irons in lots of fires. I figured it’s probably time for me to do a quick ‘state of the shack’ post to give a quick highlight on where all my various projects and activities stand, in case anyone has been wondering about the status of any particular item.
The quick summary here, is that my Motorola GR1225 died, so I currently have a machine on the air using a pair of Kenwood TK840 radios, the duplexer from the Motorola, and a new USB interface from Repeater-Builder to connect it to the computer that runs the Allstar software. After some very positive feedback on the post I wrote as I was trying to get the machine running again, I decided to start a fund-raiser to support some upgrades to the repeater, and to also help repair and get some additional repeaters on the air, which brings us to the next project…
r4e is an acronym for Repeaters 4 Everybody.
As a way to support upgrades on my repeater and some additional repeaters that are operated with a purposeful mission of openness and acceptance, and to help bulk up the RF side of the Pride Radio Network, I’ve started the r4e project which some of you may have stumbled across already in the header of my site. If you’re willing to help support some repeaters financially, or with donations of equipment, or to just connect an existing repeater to the pride network, those gifts and actions can go a long way towards our roadmap!
This project is an offshoot of the r4e project, and is a way to raise additional funds for those projects by selling radio merch that (I hope) is unlike most of the stuff already out there. Buy some cool stuff to support the project!
Version 3 of the rocket (Ponzu) had some body tube damage during its first flight, which is now repaired, and it’s ready to fly again. I also built a new ground station that is an all-in one unit with the single board computer, LoRa receiver, an RTL-SDR dongle for receiving APRS packets, touchscreen for launch control and data display, etc. Motors are ordered for the next launch, which will be on June 13th or 14th, as weather permits.
A while back I joined the Narwhal Amateur Radio Society (NR7WL) - they’re a relatively new club, but have values that I dig. We had kicked around the idea of a club ‘network’ to be able to connect via digital modes, and potentially a club net. That idea sat for a little bit, but bubbled back up recently, so I took the initiative to set up an Allstar node for the club (61672) which will serve as our hub, and the location for our first club net, for which I’ll be serving as net control!
Net details as follows:
Narwhal Amateur Radio Society Club Net
Time: 1st Tuesday of Every Month at 7pm Pacific, 10pm Eastern
Location: Hosted on the NR7WL Allstar Node (61672) and the Pride Radio Network. The Pride Radio network has bridges that will allow you to connect via DMR, IRLP, System Fusion, M-17, NXDN, P-25, D-Star, Echolink, Hamps Over IP, Hamshack Hotline, plus others!
I haven’t made any major updates to the shack recently, but I have moved a few things around. In the utility space behind the operating position I added a DIY rack made from lumber to move the various computer and network bits and bobs into. My next project in the shack is related to re-doing some of the audio routing - I have designs drawn up in KiCad for an interface device that will sit beside my mixer and convert all the audio to the OHIS standard. The basic reasoning behind this for me, is that by converting the audio to OHIS, I can leverage an existing standard to run a single shielded cat6 cable to each radio and device, instead of the 3 or 4 audio and PTT cables that run to each radio now. I currently have some bursting-at the seams cable management, and doing this should reduce the mess in there quite a bit. The plan is also to eventually replace my aging mixer, and build a new rack mount arrangement to the left of my operating position to house the mixer, interface, and some other related shack equipment.
Diversity is something important to our hobby. If you disagree, or think this statement is somehow political, you’re part of the problem in the hobby, and I won’t engage with you on the subject. If you do feel the same way I do however, the ARIP is one of my projects that is essentially a tool that clubs, individuals, or other organizations can use as a way to show their commitment to inclusion in the hobby. The most recent update on this effort is some changes to the website and methodology to make it more of a self-serve tool. There is more information about that available on the ARIP Website
Currently, the Radio League of America (RLA) is little more than an idea. That idea being that the amateur radio community is too large and diverse for everyone to have their voices heard by a single national organization. There are many amateurs who have voiced a desire for something different to be available, and the RLA is just one of many potential avenues as that movement takes life. I have committed to at some point in the near future getting together an initial presentation of what that might look like, and setting up a recurring (probably quarterly) series of meetings for people who are interested to see if it is something worth fleshing out in more detail and organizing around.
The repeater recently had a yet to be determined malfunction, and it was only putting out a few milliwats of power, instead of its normal 25 watts, meaning RF coverage dropped from its respectable footprint detailed on the page linked above, to only covering a mile or so.
I have started working on repairs, and hope to get it up and running quickly, but I decided to sit down and write this blog post because I’ve been ruminating on a few things related to the repeater, and thought this would be a good way to collect my thoughts, while I work through the mud.
Mission
The mission of my repeater is very near and dear to my heart - it is basically my way of creating a space on the air that has the same values I do - openness, inclusion, and welcoming to every type of individual who is interested in amateur radio. With that said, having a repeater on the air, connecting to nets that align with the repeater’s mission, and being part of the Pride Radio Network, is very important to me. The trouble is, keeping a repeater on the air takes both labor and money. So far I’ve managed to keep the machine on the air using only my own labor and money (I’ve managed to keep it frugal so far, so it’s been mostly an effort of my own labor.)
The repeater currently being offline however, is bumping into the limits of what I’m capable of accomplishing with my labor, and I’m starting to worry that getting it back on the air may end up involving more financial resources than I can muster quickly.
Options for the Most Immediate Need
So Priority 1 right now is getting something back on the air. Right now I’ve got a short list of choices:
Repair the current machine myself
This is what I’m currently working on. I’ve only got a few dollars worth of parts in it. I’m waiting for one more to arrive, and crossing my fingers that it will be the magic bullet that gets me back on the air.
Replace the current machine with a new one made of essentially 2 commercial radios and the duplexer from the current machine.
I have 2 radios that can be used, but this option will require a little more money for a new controller, bits to make some new harnesses, and misc. hardware- no biggie, it would just have to wait a few weeks because I do keep a pretty small/tight hobby budget so that we can sock away for education and stuff for our kids.
Pay someone else to repair the current machine?
I have zero idea what this would cost, or who I would take it to (there is a commercial shop locally that used to service this model when it was in production, so they might still be willing). I suspect it would cost more than my plan B, but I imagine it couldn’t be too bad. It would also be a way to be more confident in getting the current machine back on the air, instead of having it become more e-waste, so I’m inclined to shop around a bit if I can’t get it working myself.
Figure out how to scrounge up a little more money and buy a mostly direct replacement
This specific model can sometimes still be had for a fairly reasonable amount, and there are other comparable out of production repeaters from other companies that are similar in features and cost, if you can sort out the programming.
Figure out how to scrounge up a larger amount of money and buy a ‘proper’ replacement -
i.e. something either still in production, or in production recently enough that parts, service, programming software, etc., are actually available without having to go through dubious methods to make it happen:-) This could be big $$$, but Yeasu does have that program on their repeaters that makes the price of a new repeater not much more than buying a used one.
The Wheels Have Started Turning
So, while I’m most likely to keep slogging away at some combination of the first 3 items above, (maybe, just maybe, jumping to the 4th) this is where my thoughts start to take a meandering path. If you’re still with me, thanks! If you bow out here, I won’t be offended, because I’m not 100% sure where this thought train is going.
Like many things, all of this would be easier if there were more $$$ available to throw at the problem.
I don’t like asking people for money, but I have considered setting up something to be able to take donations for the support of the repeater. I suspect doing so I’d maybe be able to look harder at option 3, or maybe even 4 eventually, but I’m not sure if I’m comfortable asking for donations, and I don’t know what kind of tax nightmare that might become.
The other things I’ve considered would be reaching out to one of the clubs that I’m a member of that is a proper non-profit, to see if they’d be willing to act as my ‘sponsor’ to apply for an ARDC grant, to enable me to skip right to the 4th option.
With the 2 money ideas, I then spiral into the next rathole of thoughts - if I could scrounge up some resources via a combination of donations/grants, it would be very satisfying to me to acquire and set up machines, and then ship them around to places where I can find people willing to put them up at their homes or club sites, to help add more machines with full time connections to things like the Pride Radio Network.
The thought above, surprise surprise, took me spiraling down yet another side-tunnel in this rat-nest of ideas…
If money were not the hurdle, and I was helping to do this on a slightly larger scale, maybe the thing to do would be to stop operating my current repeater and any future repeaters under my own callsign, but instead maybe do it as a volunteer trustee for one of the clubs I participate in, so that the repeater network is ‘theirs’ instead of my own. Only catch there is getting into the volunteer thing can turn into a giant time commitment, which I’m not sure I could actually make (I had to drop some of my volunteer activities already, since I have a large family.)
So anyway, thats my crazy-train of thoughts for the moment. Real world, I’m most likely to focus on getting this machine fixed myself or by hiring it out, and then saving up over the long run for an eventual replacement, but it felt good to get all these thoughts out of the brain and into text.
If you have any input or suggestions I’d love to hear them - hit me up at my email (I’m good on QRZ) or via Mastodon.
I’ve been dabbling with AREDN the last several weeks. I’m not really an emcom guy, but I did want to dabble with the mesh stuff, and in my particular use case, it seemed like it might be a fun way to send my Radio Rocket’s data ‘back home’ instead of using a cellular hot spot and paying for data. I figure AREDN is a way I can do my dabbling, but maybe be of some use to the emcom folx by at least filling in a bit of a coverage hole if they need it, since there are no nodes around me, and I do have some limited emergency power at my disposal if needed.
Even though the mesh stuff is mostly line of site, I think I should still be in good shape, because of our 4 primary launch sites, one definitely has a line of site shot back home, one of them probably should, and one of them might. The 4th is probably a no-go for direct line of site, but I do have access to a TV tower on a family member’s property to add a relay node if needed…
Anyway, I haven’t done anything terribly exciting yet to really share, other then just getting my first 2 nodes set up. My only advice is to maybe avoid the TP-Link CPE210 devices. It may have been user error, but I fought with one until I gave up :-). For the 2 nodes that I got running, the GL.iNet AR300M16-ext device I got to be the mobile node was wild easy to set up, and the Mikrotik Basebox that I set up for my home node went pretty much according to directions, after being extremely careful about making sure I had the most recent nightly build of the firmware, and followed the directions exactly. (Imagine that!)
I may share more stuff on the project in the future, but for now I threw up a new static page with info on my nodes that folx can check out if they’re curious.
Exciting day! Radio Rocket version 2 is officially ‘done’ (or at least, at the point where it’s minimally viable for launch!)
that means it is time to give it a name!
When it became apparent that there were going to be multiple versions of the radio rocket, I decided I needed a ‘clever’ naming scheme. After tossing the idea around with friends and family that have been helping build it or following along, I decided to go with Sushi-related terms for the names of the various versions.
Version 1, which we crashed, was posthumously name “Nigemono” which is the generic term for cheap cuts of fish and toppings - i.e. not the good stuff, kind of like a crashed rocket is not the good stuff :-)
I think it was Smitty Halibut, N6MTS, who mentioned that cute names should at least go in alphabetical order so that it’s easy to tell which order they go in. That means that this version of the radio rocket needed an ‘O’ name. I think it’s rather convenient that the sushi term for Pacific Halibut starts with an O, so in honor of our friend Smitty, version 2 of the radio rocket is now officially dubbed ‘Ohyō’
Radio Rocket Ohyō Stats and Info
Height: 198cm ; 78”
Diameter: 38mm ; 1.5”
Launch Weight, w/o Motor: 1,261g ; 44.5oz
Recovery: dual 30” parachutes
Paint: Yellow and Green, inspired by vintage RF spectrum analyzer traces
Telemetry: GPS data via APRS packets (no digipeating) on 144.39MHz, and magnetometer, gyro, acceleration, barometric pressure, altitude, and messaging via LoRa on 433MHz. Flight data will also be posted live to Mastodon via the ground station’s ‘auto-tooter.’
Flight Predictions:
First 3 flights will be on Aerotek G76G motors, with an ejection delay of ~7 seconds. The first flight will not house any electronics, and will be strictly to test the integrity/durability of the rocket itself. Assuming a successful first test flight, the next 2 flights will carry the APRS and LoRa payloads.
For these first 3 flights, modeling predicts:
Apogee (max altitude): 266m ; 872’
Max Velocity: 65.5 m/s (235kph) ; 215 ft/s (147mph)
Max Acceleration: 99 m/s^2 ; 325 ft/s^2 (about 10g)
Time to Apogee: 7.77 s
Total Flight Time: 56.4 s
Depending on how these flights go, we’ll either do additional flights with larger motors at another time, dabble more on the software, or maybe even start building version 3 :-)
If I end up going the larger engines route, and pursue high power certification, an H170 would carry this rocket to:
Apogee (max altitude): 1106m ; 3,628’
Max Velocity: 178.6 m/s (643kph) ; 586 ft/s (400mph)
Max Acceleration: 122 m/x^2 ; 399 ft/s^2 (about 12g)
Time to Apogee: 14.5 s
Total Flight Time: 208 s
While I’d likely never do so, the largest motor that would fit is a J350, which would carry the rocket to about 6500’, assuming it held together since that motor would get the rocket to nearly Mach 1.
Motors and flight supplies are on order, and as soon as they arrive we’ll evaluate the status of our launch fields and pick a time-frame for launches.
Here it is folx - Radio Rocket Version 3, painted up, and officially named! We’ve been using sushi terms, in alphabetical order for our Radio Rocket versions. The letter P was up next, so we went with Ponzu, which is a sauce that is sweeter than traditional soy sauces. I think this is a pretty fitting name, because this rocket is absolutely sweeter than it’s predecessors. We started with an Apogee Kestral Kit, but replaced the stock 9” payload bay, with an 18” payload bay.
Radio Rocket Ponzu (v3)
Height: 109.86cm ; 43.25”
Diameter: 41.6mm ; 1.64” (BT-60 sized tube)
Weight, w/o Motor: 498g ; 17.3oz
Recovery: 30” parachute
Paint: Gold, fading to blue with a spattered fade
Telemetry: GPS data via APRS packets (no digipeating) on 144.39MHz, and magnetometer, gyro, acceleration, barometric pressure, altitude, and messaging via LoRa on 434MHz. Flight data will also be posted live to Mastodon via the ground station’s ‘auto-tooter.’ Receipt of flight updates via XMPP is available upon request.
The primary goal with version 3 of the rocket was to make everything smaller and lighter, so that we would be able fly faster and higher on the same motors. This worked out pretty well, because at 498 grams, it only weighs 39% of what it’s predecessor weighed. It is also 89cm shorter, which makes it much easier to transport, and handle while getting set up.
Based on current simluations with Open Rocket, we should be able to hit some more impressive figures with Ponzu than we did with Ohyo.
On a G64 motor we should be able to hit
864 meters vs Ohyo’s 270 meters
154 meters/second vs Ohyo’s 64 meters/second
16G vs Ohyo’s 7G
For our first couple launches however, we’ll likely fly on either F20 or F42 motors, to keep altitudes in the 300 meter range, velocity in the 70-80m/s range, and max G force in the 8G-10G range.
Lastly, here are a couple detail shots of the rocket. I’m not an expert builder/finisher, but I am getting better at it, and some of these rockets are starting to look pretty decent :-)
Also, don’t forget to check out the final picture, which is derivative of the logo of one of the clubs I belong too - the Narwhal Amateur Radio Society.
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:
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!
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.
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.
We’ve done our dry runs, and made some final tweaks, so we’re ready to burn some rocket fuel!
If you’ve been following along, after our last couple dry runs we made some tweaks, but had a couple somewhat significant things we wanted to change before scheduling our launch - both related not to the electronics or radio side of things, but to the physical rocket stuff, and some support items. You can refer to the post just before this one for details, but the tldr; is:
We needed a new launch pad
We needed a new rail guide
We needed to get my hotspot working so that we could post live updates from the field
All 3 of those things are now in place, so we’re ready to go!
Our plan is to launch over 3 consecutive Sundays, with make-up dates essentially being the following Sunday if we have to scrub.
Launch 1: Planned for May 28th 2023 (Completed!)
Liftoff @ 10:00AM EDT, 14:00 UTC
This launch is a ‘test launch’ which is a live fire of the rocket, but without the electronics payload. If you follow along on mastodon, you should see live toots right up until the final countdown, and then we’ll manually give an update for how the launch went after we recover the rocket, pack up, and get back home to evaluate how things went.
If you’re within range, and have equipment that can receive frequencies in the 380 - 700 nanometers band, feel free to try to catch us live.
[ed. This launch went very well - we’re making a couple minor tweaks to a couple things, but are now ready for our live ‘On the Air’ launch!]
Launch 2: Planned for June 4th (Completed!)
Liftoff @ 08:00AM EDT, 12:00 UTC
If all goes as planned, this will be the first ‘fully live’ launch. If you’re in the Lancaster PA area, you can try to receive our telemetry directly. We have 2 on-board transmitters that you can listen for us on:
APRS on 144.39 (N3VEM-11) which will be sending location and altitude data
LoRa on 433MHz (each packet will include my callsign, so that you know if what you’re receiving is us). If you manage to receive our packets, feel free to send a LoRa message that starts with ‘@relay’ and the rocket will repeat your message for us, and anyone else listening, to hear.
There are also 2 non-radio ways to follow along:
look for N3VEM-11 on APRS.fi - we should get enough altitude to be picked up by the W3PC digipeater in town. You probably won’t see all of our packets, but there should be a small handful that make it while the rocket is near apogee.
follow the rocket’s mastodon account. Via our ground station, there will be live status updates getting tooted out beginning at roughly T-36 minutes (9:24AM EDT, 13:24 UTC).
[ed. Launch went very well! Stay tuned for a separate post with specific details!]
Launch 3: Planned for ?
Liftoff @ 10:00AM EDT, 14:00 UTC
Launch 3 should essentially be a repeat of launch 2, unless we learn something during the first 2 launches that causes us to change our plans.
Radio Rocket Ohyō Stats and Info
Height: 198cm ; 78”
Diameter: 38mm ; 1.5”
Launch Weight, w/o Motor: 1,261g ; 44.5oz
Recovery: dual 30” parachutes
Paint: Yellow and Green, inspired by vintage RF spectrum analyzer traces
Telemetry: GPS data via APRS packets (no digipeating) on 144.39MHz, and magnetometer, gyro, acceleration, barometric pressure, altitude, and messaging via LoRa on 433MHz. Flight data will also be posted live to Mastodon via the ground station’s ‘auto-tooter.’
Flight Predictions:
First 3 flights will be on Aerotek G76G motors, with an ejection delay of ~7 seconds. The first flight will not house any electronics, and will be strictly to test the integrity/durability of the rocket itself. Assuming a successful first test flight, the next 2 flights will carry the APRS and LoRa payloads.
For these first 3 flights, modeling predicts:
Apogee (max altitude): 266m ; 872’
Max Velocity: 65.5 m/s (235kph) ; 215 ft/s (147mph)
Max Acceleration: 99 m/s^2 ; 325 ft/s^2 (about 10g)
We’re starting to prepare for Ohyō’s first launch! Most model rockets don’t require a ton of prep work - people build them, shove in an engine, pack the parachute, and fire them off. since Ohyō is carrying a couple hundred dollars worth of custom programmed electronics however, we want to be extra sure that everything is is ‘just-so’ before we send it all skyward.
Essentially, our plan of attack is as follows:
Do as many dry runs (basically do all the steps except for the actual launch) as needed until the prep, and all the steps right up to launching are pretty seamless.
We’ve done 2 of these so far - the rest of this post will be discussing what we learned.
Do a launch where we follow all the steps, but don’t actually put the electronics in the rocket, and launch it without any payload.
Finally, do the full-blown launch with payload.
Dry Runs 1 and 2
So far we have done the first 2 dry runs. The first dry run was basically a walkthrough with minimal documentation, so that we could record the steps we needed to take, and approximately how long each step will take.
The second dry run was our first attempt at essentially following our own directions :-) We learned a couple important things from dry run #2, and we made a couple adjustments already:
We needed to add some buffer time into our steps, to allow for little hiccups here and there.
We did our second dry run while running a stop watch, and then essentially gave ourselves a 10 - 25% buffer on the new timings.
We still have a lingering ‘communication bug’ where the ground station doesn’t seem to want to receive the LoRa data while out in the field.
Like it was for Nigemono (version 1), I believe this is related to power for the ground station’s radio, so I made a pigtail that would allow the ground station to be powered off the same, large, 12v battery that runs everything else when we’re out in the field, vs. relying on the little LiPo batteries in the ground station. It’s still nice having them in there as a back-up power source, but I won’t be relying on them any longer.
Our launch pad is ‘aging out’ (It is nearly 25 years old after all :-O)
It doesn’t look like the disaster that Elmo made of his launch pad, but some of the plastic parts on ours are starting to get brittle and break - the whole thing nearly toppled over with the rocket just sitting on it, when one of the plastic snap-connectors broke. I have a material list and hand-sketches that I drew up to just make a new one out of 1010 Series aluminum extrusions and fittings, so I’ll be doing some price checking at places like McMaster Carr, Fastenal, etc. over the next couple weeks.
We’re not likely to have wifi at our launch site, so I needed an internet connection so that the ground-station’s status-tooter could post updates to Mastodon on launch day.
I ordered up a data sim for the little Nitehawk Mobile router that I’ve had collecting dust for a couple years, so that should keep us ‘online’ for launch day.
Our rail-guide is inadequate.
Most model rockets use launch lugs (essentially a little tube glued on the side that slides over a rod), or as they get larger, buttons/rail guides. Launch buttons are essentially like little ‘wheels’ on the side of rocket that side into the channel in a piece of aluminum extrusion, and then ‘glide’ the rocket along the rail during launch. Rails are much stiffer than rods, and work better for larger rockets.
For Ohyō I decided to use a fly away rail guide, which is essentially a two piece shell that wraps around the rocket - when the sliders are in the rail, that holds them together, but when the rocket leaves the rail, tension from springs or rubber bands opens the two halves, and they fall away from the rocket. I initially grabbed the inexpensive ones available from Apogee that Tim talks about in this video. It seems like they would normally work great, but Ohyō is so long, and has so much of it’s weight near the nose, that it leans pretty hard away from the rail, causing a lot of friction. I ended up ordering a more expensive, but heavier duty and much longer version from Additive Aerospace. You can see them in action in this quick clip.
And that mostly covers what we learned from our first 2 dry-runs. We’ll be doing a 3rd, and probably 4th, in the very near future, and one or both of those will likely include status updates to Mastodon, so make sure to follow the rocket’s account there if you’re interested!
Radio Rocket Ohyō Stats and Info
Height: 198cm ; 78”
Diameter: 38mm ; 1.5”
Launch Weight, w/o Motor: 1,261g ; 44.5oz
Recovery: dual 30” parachutes
Paint: Yellow and Green, inspired by vintage RF spectrum analyzer traces
Telemetry: GPS data via APRS packets (no digipeating) on 144.39MHz, and magnetometer, gyro, acceleration, barometric pressure, altitude, and messaging via LoRa on 433MHz. Flight data will also be posted live to Mastodon via the ground station’s ‘auto-tooter.’
Flight Predictions:
First 3 flights will be on Aerotek G76G motors, with an ejection delay of ~7 seconds. The first flight will not house any electronics, and will be strictly to test the integrity/durability of the rocket itself. Assuming a successful first test flight, the next 2 flights will carry the APRS and LoRa payloads.
For these first 3 flights, modeling predicts:
Apogee (max altitude): 266m ; 872’
Max Velocity: 65.5 m/s (235kph) ; 215 ft/s (147mph)
Max Acceleration: 99 m/s^2 ; 325 ft/s^2 (about 10g)
Exciting day! Radio Rocket version 2 is officially ‘done’ (or at least, at the point where it’s minimally viable for launch!)
that means it is time to give it a name!
When it became apparent that there were going to be multiple versions of the radio rocket, I decided I needed a ‘clever’ naming scheme. After tossing the idea around with friends and family that have been helping build it or following along, I decided to go with Sushi-related terms for the names of the various versions.
Version 1, which we crashed, was posthumously name “Nigemono” which is the generic term for cheap cuts of fish and toppings - i.e. not the good stuff, kind of like a crashed rocket is not the good stuff :-)
I think it was Smitty Halibut, N6MTS, who mentioned that cute names should at least go in alphabetical order so that it’s easy to tell which order they go in. That means that this version of the radio rocket needed an ‘O’ name. I think it’s rather convenient that the sushi term for Pacific Halibut starts with an O, so in honor of our friend Smitty, version 2 of the radio rocket is now officially dubbed ‘Ohyō’
Radio Rocket Ohyō Stats and Info
Height: 198cm ; 78”
Diameter: 38mm ; 1.5”
Launch Weight, w/o Motor: 1,261g ; 44.5oz
Recovery: dual 30” parachutes
Paint: Yellow and Green, inspired by vintage RF spectrum analyzer traces
Telemetry: GPS data via APRS packets (no digipeating) on 144.39MHz, and magnetometer, gyro, acceleration, barometric pressure, altitude, and messaging via LoRa on 433MHz. Flight data will also be posted live to Mastodon via the ground station’s ‘auto-tooter.’
Flight Predictions:
First 3 flights will be on Aerotek G76G motors, with an ejection delay of ~7 seconds. The first flight will not house any electronics, and will be strictly to test the integrity/durability of the rocket itself. Assuming a successful first test flight, the next 2 flights will carry the APRS and LoRa payloads.
For these first 3 flights, modeling predicts:
Apogee (max altitude): 266m ; 872’
Max Velocity: 65.5 m/s (235kph) ; 215 ft/s (147mph)
Max Acceleration: 99 m/s^2 ; 325 ft/s^2 (about 10g)
Time to Apogee: 7.77 s
Total Flight Time: 56.4 s
Depending on how these flights go, we’ll either do additional flights with larger motors at another time, dabble more on the software, or maybe even start building version 3 :-)
If I end up going the larger engines route, and pursue high power certification, an H170 would carry this rocket to:
Apogee (max altitude): 1106m ; 3,628’
Max Velocity: 178.6 m/s (643kph) ; 586 ft/s (400mph)
Max Acceleration: 122 m/x^2 ; 399 ft/s^2 (about 12g)
Time to Apogee: 14.5 s
Total Flight Time: 208 s
While I’d likely never do so, the largest motor that would fit is a J350, which would carry the rocket to about 6500’, assuming it held together since that motor would get the rocket to nearly Mach 1.
Motors and flight supplies are on order, and as soon as they arrive we’ll evaluate the status of our launch fields and pick a time-frame for launches.
In a relatively short time from writing this post, I’ll be doing a presentation about this rocket project at the QSO Today Virtual Expo. My specific presentation, How to Build the Radio Rocket will be Sunday March 26th, at 6pm UTC (2pm EDT, 11am EDT), in the event you’d like to mark your calendar.
The real reason for this post however, is for folx who end up stumbling here as a result of the presentation, after it happens:-) During the presentation I threw out a lot of stuff very fast, so I wanted to put some summary information here, with links to the things that I referred to during that presentation, for easy reference.
General Rocketry Info
National Association of Rocketry (NAR) Tripoli Rocketry Association
These are the 2 big organization in Model/Mid-Power/High-Power Rocketry. If you’re interested in rocketry info in general, these organization are a great place to start. The biggest difference between the two associations is that the NAR is primarily a United States based organization, and tends to be more active in the model and mid-power areas of the hobby. Tripoli is a global organization with clubs around the world, and tends to be high-power centric. Both organizations however do cover the full range of the hobby, and they recognize each other’s certifications if you get involved in high power.
My Radio-Rocketry Project
The quickest way to read up on my specific project is to check out the dedicated summary page for the rocket project, and to check out my blog posts that are tagged Radio-Rocket.
Resources
For the code bits of this project, I’m doing my best to keep the most current copies of the code updated on github. The code for the current in-progress version is in my RadioRocketV2 Repository. I also have the code from the original version in my RadioRocket Repository, however I’m no longer updating the original repository since I’ve started working on V2 of the rocket.
Quite a bit of the electronic bits, including the 70cm LoRa modules, come from Adafruit.
The single board computer in the ground station is a Libre Computer which in my opinion is just as easy to work with as the Raspberry PI, but is actually obtainable, and doesn’t come from a company who’s social media account behaves like an entitled ass-hat.
The Project box for the ground station is one of these. They’re actually pretty slick little enclosures.
I get a lot of my rocketry supplies from Apogee Components. I like them for the same reason I like Adafruit - they don’t just sell stuff - they have a pretty extensive library of how-to information, videos, etc.
I wanted to do a quick update on the status of the Radio Rocket since it’s been a bit since I shared any info on it.
edit 2023-01-10: I just learned that a presentation on the radio rocket was accepted for the March QSO Today Virtual Expo so if this rocket project has been interesting to you, make sure to check that out! It will be a great opportunity to see a more wholistic overview of the project, and to ask questions also!
Physical Construction Status
The booster portion of the rocket, i.e. the part that holds the fire, is significantly complete - it just needs an engine retainer and paint.
The bay the holds the main electronics sled is built, and prepped, just needs paint.
The APRS electronics bay, which will essentially be inside the shoulder of the nosecone and extending down into the top body tube, needs to be built. All the parts are on hand, but I want to have the replacement APRS tracker on-hand first, so that I can verify final dimensions before I start cutting things.
Electronics Status
The ground station is complete and ready to go. I’ll certainly be making updates to the code, and some other design things down the road, but I have it at it’s ‘ready for test launch’ state.
Micro-controller, LoRa, & sensors on the main electronics sled have all been installed, bench tested and are ready to go for the test flights.
APRS tracker needs to be ordered, and then programmed. The one I had was damaged beyond repair when V1 crashed. Luckily that part worked fine, so I can reload the existing code into into the new one when it comes.
Next Steps
So with that quick summary, this is my current checklist of next steps for the radio rocket, roughly in order of what will come next:
Order replacement APRS tracker & battery
Load up the already-written code for the APRS tracker
Build the sled for the APRS tracker, fit it to the forward section of the rocket, and cut the airframe to length
Do the prep work for the forward section of the airframe (filling groves in the body tubes etc.)
Order and install a motor retainer
Order and install recovery (parachute’s) - the size of chute’s needed is weight dependant, so it will be easier to wait till the rocket is mostly finished and just weigh it.
Conduct several dry-runs
set everything up to run through all the steps up to, but excluding, actually launching the rocket
Order engines and launch supplies
Conduct electronics-free test launch
launch the rocket like a ‘normal’ model, with weights in place of the electronics, to test basic launching and flight expectations.
Paint Job!
This is when the rocket will get its final paint job and be officially ‘named’ so that I can stop calling it “Version 2”
It’s dawning on me that I’ve never really written about the fact that for a few months, I’ve officially been a member of the ‘repeater owner’ club. The saga actually began a number of years ago, when one of the offices at my work was getting rid of a repeater. It’s a long story about how that came about, but at the end of the day, they were getting rid of it, so I saved it so it could see a second life on the amateur bands.
The actual repeater in question is a Motorola GR1225 (UHF version), which were fairly common ‘desktop repeaters’ that were in use in quite a few businesses. As cell phones took over the niche they filled, they seemed to become readily available on the used market. Even if you don’t luck out like I did and save one that was bound for the trash, you can usually find them on Ebay for just a few hundred dollars.
Anyway, the repeater sat on the floor of my home office, unused, for a several years, because I wasn’t quite sure how I wanted to press it into service. In our area, 70cm isn’t super popular, and most of the 70cm repeaters sit quiet, so I wasn’t in a hurry to just stick it on the air to add yet another unused 70cm machine.
Within the last year or so however, the Ham Radio Workbench crew started talking about setting up an Allstar hub, which they did (node 55915). It was at that point that I said - heck, I have an unused repeater sitting on my floor - why not put it on the air, add Allstar capabilities to it, and have it hang around connected to their hub?
And so the project began…
Repeater Coordination
Repeater coordination councils are all volunteer, so this takes some time! In my case it took about ~5 months from application, until I was assigned my frequency pair by the council that coordinates my area. While I waited, I did start ‘construction’ but just put the repeater on the air uncoordinated, with a low-to-the ground antenna, on a frequency pair that was unused in the area.
Construction
Since the machine is a desktop repeater, construction wasn’t too involved - just a few steps:
Tuning the duplexer, which I did twice - once while I was uncoordinated, and then once again when I was assigned my final pair. W2AEW has a bunch of great videos on his youtube channel. I don’t have a ton of fancy equipment, but I think I got pretty decently tuned with my nano VNA, following this video specifically, to guide me along the way. As a note, since this is a desktop repeater, it only has the notch-type ‘portable’ duplexer, which works fine running here at my house, since I’m the only source of RF :-)
Audio interface for Allstar - since this is a Motorolla repeater, I was able to use one of the RIM-lite interfaces from repeaterbuilder, which plugs directly into the back of the transciver, and in turn accepts the USB cable. I had to fiddle with some of the settings in the radio software, but it really wasn’t too difficult to get up and running.
Allstar Node - pretty straightforward stuff here too - Raspberry Pi3, running Allstarlink. There seems to be some contention in the Allstar world, between Allstarlink and Hamvoip. At the time I went with Allstarlink because it seemed like the one that was more “open” and it sounds like there is some stuff in Hamvoip that might be slightly borderline as far as software license legality goes (Although I was more concerned about openness that software licenses - In some cases I firmly believe that piracy is the moral thing to do). I didn’t dig deep into it though, so do your own homework:-)
In hindsight, I’m glad I went with Allstarlink. This is because it runs on Debian, and I was able to fairly easily install node-red along side it. Hamvoip runs on Arch, which seemed way more fiddly when I played around with it recently.
Node-RED - as mentioned, I installed Node-RED alongside Allstarlink, and I’m using that to schedule and fire off announcements etc, instead of the macros and scheduler that are built into both Allstarlink and Hamvoip.
Antenna - Nothing too fancy here - jut a Diamond X50NA, on a mast at the eve of my house, with a fairly direct run of LMR400.
Future thoughts
I’ll dabble with this for a while on a small scale, and if I find I enjoy the whole repeater-ownership thing, I’ll probably start working on upgrading at some point down the road. Some of this would require re-applying for updated coordination, but the things I’d probably want to explore would be:
Getting the Antenna higher, once I put up a proper antenna, or find a cheap/free place to move the machine too, instead of my house.
Switching to hard line (les loss, etc. etc.)
Getting my hands on some proper notch/pass cans for better filtering/isolation
An external PA maybe - I have the machine on low power - it’s capable of more, but this model is known for blowing finals when run at any fairly high duty cycle on their high power setting.
Anyway, that’s the story for now, and I’m having fun dabbling around with it!
All of the core folx at POTA have known about this for a bit, but it’s time to start sharing with the broader POTA family…
POTA Family,
I’m writing today with some sad news – on November 30th I will be officially hanging up my POTA hat, and moving on to the next phase of my amateur radio journey.
Having been involved with POTA since its beginning, this was not an easy decision to come to, but with a young growing family, it’s the decision that I had to make. I’m still very passionate about ham radio and POTA, so you’ll still hear me on the air hunting parks, and will likely see me posting about what I’m up to in ham radio if you check in the right places (Mastodon is probably your best bet). In order to free up the time required for my family commitments however, I have to step away from any official duties.
As I depart, I want to thank the POTA team for all of their support over the years, and for putting so much faith in a middle-aged guy with a freshly minted IT degree as we got all this up and running – volunteering for POTA as I was finishing up my degree as an adult was an awesome learning experience, that I would not trade for the world.
I’d also like to thank all of the participants of POTA for making the effort worth it – without all of you, the program wouldn’t have been a success, and hearing the compliments and notes of appreciation from everyone is what makes all the hard work worth it.
Login
