KM6LOB is On the Air

After studying the documentation and the source code for WSJT-X, I determined that the UDP API did everything I needed for now. I wrote a little python script and have been testing it on my computer between two instances of WSJT-X. After a bit of tinkering, I got it running reasonably well, and I decided to put it on the air in a limited way this afternoon. I fired up on 20 meters and let the bot do its thing.

Well, as the old saying goes, no plan survives first contact with the enemy. Despite my simulations, the very first contact went wrong and I had to intervene. But after a few tweaks, I got it running reasonably smoothly. Right now, it’s running in a very simple mode that just answers CQs, in order to try to get some rate. Any compound callsigns, directed CQs, or direct calls are ignored. Each station will only be worked once per band. And, CQs are answered on the same frequency they were heard on to minimize chances of interference to other stations.

However, there is a problem I didn’t really anticipate. Namely, while the bot is calling stations and working them when it gets a reply, it very often gets no reply at all. Even stations that are at -5 or louder are CQing in the bot’s face, even after I increased the power to 75 watts. It seems likely that FT8 has now become just another QRO mode, and my original thoughts of running 25 watts on the regular frequencies were naive. If this is typical of how the watering holes are now, then even answering CQs may not be feasible when the DX pod is actually deployed and has a strict power budget. Moving to a different slice of spectrum looks virtually a requirement.

So right now, the bot is working fine, but it’s still not making too many contacts. A better strategy may be required, since QRO is not an option. FT8 has simplified the process of building a bot, but it’s no silver bullet.

What is “Success”?

Before starting the project, I wanted to sketch out some thoughts on what success would look like. Here are some facets I think are important, in no particular order.

  • Easily replicated. No proprietary or paid software. No expensive or exotic hardware.
  • FT8. This one is a no-brainer: the mode is taking the ham world by storm, and it basically begs to be automated more than any other mode I know of.
  • Low power. I think I will limit power to 25 watts at first so as to minimize any chance of disturbing others, and to simulate something closer to a sane power budget that might be typical of an off-the-grid installation.
  • Baby steps: walk before running. One thing at a time, making incremental progress. I think getting the QSO automation correct and solid needs to come first. Other aspects, like the autonomous power supply, satellite connection, and so on can come later.

The Raspberry Pi is an obvious choice for automation control. The current model is a bit under powered, as I have discussed before, but its ubiquity is an unbeatable asset going forward. Also, the newer revisions look like they might have a bit more “oomph” and those are due out soon I think, so it should be an easy upgrade. There are other boards with more attractive specs, but none of them have anywhere close to the support or fan base that the Pi does.

I am aware there are some automation-enhanced forks to WSJT-X out there, but they seem to be Windows oriented, and I am looking to run Raspbian. Additionally, I want as few changes to the WSJT-X code base as possible. Just enough, actually, to permit a Python script to control the app. Why? I think Python will be easier for people to follow and adapt, it’s cross-platform, and it’s good to separate the automation logic from the modem software anyway.

First steps, then, will be to simply get a working build of WSJT-X, from source, on a Raspberry Pi running the latest Raspbian. After that, I need to look into how it might be controlled from a Python script. If anyone is aware of prior work, please let me know. I already use the UDP service to receive data from WSJT-X and parse it in Python, but I’m not aware of any method to send control data back.

Hello World

I’ve been thinking about setting up a “DXpedition in a box” for a while now. In fact, it’s been on my mind at least since early 2016, when I was working on the “back office” team at VK0EK. During that operation, I advocated for (and got) the opportunity to set up a remote controlled station on Heard Island. That story has already been partially told elsewhere (starting at the 53 minute mark), so I won’t go into it again now. But we discussed the possibility of building a leave-behind QSO-bot at that time, and decided it would be very unlikely impossible that the Australian authorities would approve it, so the idea was scrapped.

Fast forward a year, and the subject was obviously still on my mind, as I wrote a semi-detailed proposal on KY6R’s blog. That post is a bit dated now, since FT8 had not even been released yet at the time. I had hoped someone else might pick up the torch, but so far there has been no public sign that an effort is underway. So, when the subject surfaced again on an eham thread today, I decided to try to see if I could actually make it happen.

What, then, is my goal? First off, I am not taking any position on whether robotic contacts should count for DXCC, WAS, WAZ, or any other award. I’m not particularly interested in any of them. For the purposes of this experiment, I just want to see if it would be technically feasible to build an unattended QSO-bot (I call it a “DX pod”) capable of handing out contacts in a well-defined and controlled fashion for an extended period of time. I want to be as transparent as possible in the process, and I welcome feedback and collaboration, and even competition — if you want to beat me to the punch, I am happy for you to do so! I plan to publish my work here as I go, so that others can follow along and replicate if they so desire.