No better way to be “done” with something than to post it online, right?
Astute readers will have noticed the Vulpes Radio Orienteering Controller project page pop up here this fall. It’s an incomplete start, but I wanted to write a little bit here about the why, how, and what’s next, and some of that will get moved over to the page eventually. I’ve posted a bit about this before on Mastodon.
I’m not a huge fan of big posts with lots of history, but here I am again. One thing I don’t know if I can bring myself to do (today) is list out all the resources I dug up while working on this project. But if there are questions, I can update.
So, the why: around the beginning of August, I took what was meant to be a short break from social media that became a three month break, during which I got really into reading about Amateur Radio Direction Finding (ARDF), or Radio Orienteering (RO) as it is being rebranded (rightly, IMHO). Formal RO is related to foxhunting but has some differences, mostly that it happens on foot with multiple transmitters. Both terms are pretty general, and ARDF itself could include anything from this sporty stuff to figuring out which neighbor’s holiday lights are interfering with your ragchew. I’ve never done any of this stuff! My background is in racing and directing adventure races.
In any case, I was sort of looking for a project so I could both use KiCad and learn more about electronics. Working on this gave me something to do instead of getting even more frazzled seeing cool radio things other people were posting on mastodon.radio at the time.
Because of course a ham is always looking to save small amounts of money by spending larger amounts of money, I got irritated by the lack of 1) commercially available, 2) relatively inexpensive, 3) easy to use RO transmitters/controllers. I soon gave up on finding something that fit all my criteria and decided to hack together something as easily as I could. This mean a) using off-the-shelf as much as I could and b) hacking things together cheaply. I may or may not have succeeded, but in my defense, I did learn a lot.
The how: I’ll be focusing on 80 m RO for a silly reason–I don’t like the aesthetic of running around with a tape-measure Yagi. If you do it, great! I’ll probably do it someday! But the small size of an 80 m receiver seemed cool, and using existing low-power 80 m CW kits as transmitters seemed like a good idea, so now I have a RX80M receiver, an NS-80+ transmitter, and a Cricket 80A transceiver.
Lots of existing projects use microcontrollers and switches to set up the RO transmitters. Some of them have complex cable arrangements to sync the clocks so each of five transmitters accurately starts and stops transmitting a unique CW signal on a certain cycle. One that I actually found after starting my ESP32 programming was designed by N1OIQ and uses an Arduino. I chose to use an ESP32 because 1) I wanted to learn how they work, 2) I knew they had WiFi (which is used) and Blutooth (which isn’t used yet), and 3) they should be able to do the job. Rather than building up a specific design around the raw chip, I used a development board that seems to be readily available, and if it becomes hard to find, the design can be modified to use a dev board with a different pinout.
A few years ago, I got into the idea of using LoRa to support a wilderness endurance race; specifically APRS over LoRa, which is how I was introduced to this type of programming. I specifically hacked around on SQ9MDD’s codebase and learned about serving interactive web pages from small devices. It’s magic! So the idea here is, why have physical I/O (switches and buttons) when you can run all the settings from the web browser in your phone? And why should you have to push a button simultaneously on multiple devices in order to sync them up to start at the same time, exactly n hours into the future, when we have computers to keep track of all that?
The timing thing was a bit of an extra problem because an ESP32 board needs to be powered to keep time. I learned about RTC development boards (also readily available) and integrated one into the circuit. This allows you to track time between power cycles using a CR2032 battery and, as long as the ESP32 is powered up before it’s supposed to turn on, the RTC will kick the transmit cycle into gear.
One of the best things about this design is that the hardware is pretty simple (few parts, easy to put on a PCB), so lots of things can be tweaked in software.
All this happened over three months, was not entirely smooth sailing, I learned a lot, and I have to admit that I’ve bounced back and forth between “this is so great everyone will want it” and “all I wanted was to try this out at local races, why didn’t I just buy something.” If you want a bunch of play-by-play, you can check out the Gitea issues.
Major outstanding stuff right now:
- code issues (bugs and new features)
- board size should match an existing case, or I need to design one
- publish parts list (although a loose BOM exists)
- key jack holes are a little tight, or not lined up right
- RTC header holes are a little tight
- screenprint on the back of the board which pins actually need solder
Where was I going with this? Who knows. As the project page says, get in touch if you want to test or otherwise collaborate. I don’t think I’ll be able to drag local folks out to test until the Spring. I’m thinking about possible ways to package this up as a kit or full build. As mentioned above, though, there may be a software loading component if there are iterations that people want to use.
@W1CDN Well done!!