I quite like using data modes, and for this I use fldigi. I think one of the key things is to have a good setup, and so I have spent quite a lot of time creating macros, getting the CAT cable working, and building a homebrew data interface. For contests I use fldigi’s log, but for normal contacts I use DXKeeper. I found an application called fldigiDXLabsGateway.exe that will forward fldigi’s logged QSO to DXKeeper.
One of the problems that I have had though was controlling the transceiver. I have tried using Commander (in the DXLab suite) and flrig but both seemed to cause fldigi to use the PTT line via the CAT cable. The transceiver then didn’t want to get the audio via the data port. I did *sort of* get this working (you have to make sure the transceiver uses either USB DATA or LSB DATA mode), but it is unreliable at best, and fldigi and the rig control program seem to fight over the mode setting. If you want to try that though, click on the the link below:
Using Rig control program with fldigi
In this configuration fldigi needs to control the rig using XML-RPC rather than Hamlib
The other problem is that fldigi doesn’t fill in the power field, so I had to manually update the record in DXKeeper. I try to use as little power as possible, so I am changing the RF power setting all the time. So, after trying various configurations, this was the one I settled with:
In order to solve the problem of how to control the rig, I decided to go homebrew and create a transceiver controller. I looked at various architectures (and ran into various problems), but in the end I went for one that intercepted the messages going to the COM port. I did this by using a COM port loopback program called COM0COM.
COM0COM gives you pairs of COM ports (we only need one pair), and makes it appear as if the two COM ports are loopbacked to each other. This gives us lots of advantages over other ways of intercepting serial data – we don’t have to mess with drivers, and we don’t have to worry about serial ports disappearing when programs are closed (so we don’t have to worry too much about what order we run programs). I have tried COM0COM on Vista and Windows 7. On Vista you can use version 3.0 (after jumping through a few hoops), but Windows 7 needs a signed driver, so you have to use version 2.2 (and you still have to jump through a few hoops – mainly putting the OS into test mode, rebooting, installing, coming out of test mode and rebooting).
So the new architecture is:
In order to put the power field in the log I intercept the TCP message sent by the fldigiDXLabGateway. Usually the gateway and DXKeeper both use port 52001, but I configured the gateway to use port 51001 so that I could intercept the message, add the power field, and then sent it to port 52001. The finished controller’s UI looked like this:
Serial data from fldigi is intercepted by the master controller, and then forwarded to the radio. Same goes for data coming from the radio. The master controller also sends messages to the radio, so I created a queue. That way I can match replies up with requests, and ensure they go to the right place.
Now I’ve done this, I have a framework which I can use for any controls that I want. The only controls I have so far are RF power, AF gain, and controlling what the CS/Voice button does -in this case play a pre-recorded voice message (SSB / phone) or output a 10W carrier (for tuning / swr display).