TLF and fldigi fighting over frequency in RTTY mode

[df7cb]

Over the past year, I've been trying to do some RTTY contests with TLF. I got it working occasionally, but most often, things wouldn't initialize correctly and the fldigi waterfall (and sometimes the whole UI) would freeze. Tuning the VFO around would show that the actual rig frequency is always jumping back to the original value after a fraction of a second. At one point I had a sequence of "start X, start Y, switch mode, ..." that made it work, but it was very fragile and any problem during operation (rig communication hickup something) would trigger the problem again. Once the problem happens, even quitting TLF will leave fldigi frozen for some more time. I put in some printf to see the communication between the two programs and it looks like fldigi is flooded with requests that it doesn't have the time to digest.

What I think happens around the rig frequency being locked is that both TLF and fldigi are connected to the rig via rigctld, so when RTTY mode is initially activated and TLF tries to communicate the frequency offset to both the rig and fldigi, fldigi will also see a frequency change in the rig which TLF can then read back and communicate to the rig again... etc. If you manage to get past that initialization, it works, until things get out of equilibrium again. (I can't really disconnect fldigi from rigctld because it needs to key PTT.)

Last Friday, just before the WPX RTTY contest I spent the evening reading the TLF source to see if I can fix the problem. Originally I thought disabling the "when RTTY is activated, change the frequency by CENTER_FREQ" logic in fldigixmlrpc.c, but this had little or no effect.

What made things work was to remove the two rig.set_mode and rig.set_frequency calls at the end of the fldigi_xmlrpc_get_carrier() function. With this, starting TLF and fldigi and entering RTTY mode worked and I could to the contest.

In summary, I think there's more than one bug or missing feature here.

• if both TLF and fldigi are connected to the rig, they shouldn't fight over the frequency
• CENTER_FREQ is hard-coded to 2210, it should be configurable (fldigi and myself prefer 1500)
• rig.set_mode and rig.set_frequency every few ms might be too much for fldigi to ingest. (The problem might be elsewhere, but removing these helped a lot)
• the code flow in fldigixmlrpc.c is a mess. The confusingly-simillarly-named variables fldigi_var_carrier and fldigi_var_shift_freq are set in non-trivial ways without any comments and are used at the very other end of the file to communicate with other parts of the program.
• the CENTER_FREQ offset is only added to the frequency shown in TLF when the rig is in USB mode, not when it's in USB-DATA mode. I tried adding RIG_MODE_USBD1 to the switch statement in fldigi_xmlrpc_get_carrier(), but that didn't help.
• the signum and modeshift handling is a small mess in that function, and some of the values are likely just wrong (CWR should be the opposite of CW, but it isn't)
• AUTO_CQ doesn't know about RTTY being sent and the counter starts immediately (probably ok, just a bit weird)
• clicking on a call in fldigi doesn't stop the AUTO_CQ timer
• clicking on an exchange in fldigi brings the exchange to TLF, but the user can't edit it, backspace doesn't do anything
• is there a way to define macros that have leading and trailing spaces? I put more | everywhere instead, but this might be a nice addition.
• the RTTY documentation is full of "it used to work otherwise" bits that are irrelevant today and should be removed
• there should be some discussion about FSK vs AFSK in the docs and what that means for rig mode and fldigi
• I should finally take the time to read the whole TLF manpage, some of the things I learned last week I got from reading the source even when the manpage already had them 😸 (| in macros, :list command)
• overall, I shouldn't complain that much, I made 420 RTTY QSO over the weekend with TLF 🚀. The bandmap was working as it should

I can try to come up with a few pull requests to fix some of the points, but I wanted to drop this here before I start forgetting about the details.

[zcsahok]

I also experienced TLF-Fldigi interoperation issues. Will try to reproduce it.
One thing that doesn't help really is that we poll Fldigi each 10ms ...
fyi: I just started reviewing fldigixmlrpc code https://github.com/zcsahok/tlf/commits/review_fldigixmlrpc