tlf
tlf copied to clipboard
Tlf
Review of fldigixmlrpc code
A review/rework of Fldigi interworking. It started as I couldn't get the idea behind connerr and connerrcnt leading to reconnection, at least this is stated in the comment (maybe @airween knows it). Then a number of issues popped up, I'm working through them slowly. Hopefully will get some of the issues from #463 fixed.
Documentation references: xmlrpc-c: https://xmlrpc-c.sourceforge.io/doc/libxmlrpc.html and https://xmlrpc-c.sourceforge.io/doc/libxmlrpc_client.html xmlrpc-c sources (not the latest, but usable): https://github.com/ensc/xmlrpc-c FLdigi xmlrpc: https://xmlrpc-c.sourceforge.io/doc/libxmlrpc_client.html
Now curing my main issue: Fldigi gets blocked when used with TLF.
The reason is that in fldigi_xmlrpc_get_carrier() among other things we set the rig mode and freq. We literally bombard Fldigi with requests, as this function is called each 20 ms. Fldigi duly propagates the requests to the rig, but this high I/O load due to some internal working essentially blocks the decoder/encoder/GUI part of Fldigi making the program irresponsive and also TLF unusable in this combination.
Here is short script to trigger the situation: it sends 300 set_mode requests in about 9 seconds. My setup (Fldigi 4.2.06 + rigctld + rig at 9600 Bd) takes roughly 30 seconds to recover from this flooding. And TLF sends such requests continuously...
import xmlrpc.client
from time import sleep
with xmlrpc.client.ServerProxy("http://localhost:7362/") as fldigi:
for i in range(300):
fldigi.rig.set_mode('USB')
sleep(0.03)
As I'm not sure if this mode/freq setting is actually required (@airween, any idea?), so the workaround is to request the current values and call the setter function only if really needed. Thus at the expense of 2 getter calls we can avoid the unnecessary and trouble making setters.
Will limit the rate of calling Fldigi from the current 50 times per sec (20 ms) to 10 times per sec, as this should be also roughly enough. RTTY at 45 Bd can send less than 10 char/s and for faster modes the practical limit is anyway on the human side.
Uhm, I'm really sorry, I completely missed this issue (and from mentioned one).
Let me review both soon and reflect all.
it sends 300 set_mode requests in about 9 seconds
That's very weird. I don't think I had any reason to make this. My RIG uses 4800 baud and the response time for a RIG command is about 200-300 ms. When Tlf uses that it asks the current VFO and the current FREQ, that's two requests. As I remember in background process we use a 500ms sleep, and as I remember I tried to use the same mechanism. But it was years ago...
As I'm not sure if this mode/freq setting is actually required (@airween, any idea?), so the workaround is to request the current values and call the setter function only if really needed. Thus at the expense of 2 getter calls we can avoid the unnecessary and trouble making setters.
Honestly, I don't remember why did I think that mode and freq set was necessary - but may be I found some extra scenario which justified it. Probably we should try your suggestion.
Background process sleeps for 10 ms between iterations and now only each 10th runs checks fldigi status. Let's see if this is enough. A quick test with both TLF and fldigi connected to rigctld showed no issues regarding frequency setting. (ok, it was not hardware RTTY but AFSK)
CQ-WW-RTTY is happening right now, there are many RTTY stations in the air.
I tried to set up my RIG with Fldigi, and I have to tell you that's completely unusable.
As @df7cb explained here, Fldigi's (or the XML-RPC lib) response format depends on used locale. I had to set up the locales for Fldigi, then Tlf could work with that - for a while. After a very few minutes Fldigi completely frozen: I was not able to communicate with it, even the waterfall stopped. I assume the problem was the flood of requests from Tlf (I used Zoli's repository: zcsahok:review_fldigi_xmlrpc, but I tried with the master branch too with same result).
So we definitely need to review - I try to help you guys with this.
I would think that polling at a rate faster than once per second is excessive. Maybe I'm missing something.
I was not able to transmit signal, just tried to receive. But after a few minutes, Fldigi just frozen. I mean how long had you been using Fldigi?
Fldigi was running for an hour when I took the screenshot. Maybe check the AFC setting, if it's on then that can also trigger the freq setting ping-pong.
Optimized getting call/exchange data from Fldigi. Also tried to move UI code out of these functions as they are called from the background process.
I would think that polling at a rate faster than once per second is excessive. Maybe I'm missing something.
It has to be much more often so there is no delay after clicking on a call in fldigi before it appears in tlf.
Just tested it and the delay between clicking on Fldigi and the callsign appearing in TLF is minimal.
That's it for the moment. Will address the freq control strory in a follow-up PR: the whole fldigi_xmlrpc_get_carrier() function can be probably dropped.