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.