Severe lag using hamlib/flrig

[csibbitt]

First of all thanks for this excellent software; it is a joy to use.

I recently migrated from 0.39 on windows to 0.43/44 on linux and ran into this severe lag problem controlling my ft991a via flrig (same setup works fine in windows).

Another user has also reported this bug here: #625

My setup:

• Ubuntu 24.04
• Qlog 0.44.1-1~noble from your ppa
  • Also tested 0.39.0 since it works in windows, but it's also laggy
• libhamlib4t64 4.5.5-3.2build2 (ubuntu repo)
• flrig 2.0.04-1build2 (ubuntu repo)

Here's how I can reproduce the problem:

• Confirm Flrig can PTT reliably on and off many times with no perceptible lag
• Connect Qlog to Flrig via Hamlib, FLRig (20221109.0), Network (localhost). Enable the top 6 Rig Features checkboxes up to "PTT State". Poll interval 500ms.
• VFO and mode changes on the rig show up quickly and reliably in Qlog at first
• I set up Wireshark to watch the connection
• See Qlog sends the get_vfoA command ~once/1s
• Use Qlog PTT/band change commands several times
  • At first they respond quickly
  • Soon degrade to multiple seconds of lag
  • Sometimes commands are just lost
• See Qlog sends the get_vfoA command ~once/7s
• VFO and mode changes show up with considerable lag in Qlog
• Using PTT is a dangerous gamble - the timing of the key-down is very late and unpredictable, sometimes the PTT-off is missed entirely
• Controls still work perfectly via flrig, hamlib's rigctl

Adjusting the poll interval seemed to help (for awhile?). The default is 500ms, but going to 1000ms made the lag basically go away. If I hammered on the commands really fast it would still screw it up, though. This workaround hasn't proved reliable over time, but does occasionally seem to help.

When using hamlib/serial config, the problem does not occur, so I've only reproduced it in hamlib/flrig so far.

I tried taking QLog out of the equation and testing just hamlib->flrig using the CLI tool rigctl, like this ('-m 4' means "flrig", 'T' is PTT): for i in {1..25}; do rigctl -m 4 -r 127.0.0.1:12345 T 1; sleep 0.25; rigctl -m 4 -r 127.0.0.1:12345 T 0; sleep 0.25; done

Running this rigctl loop several times in a row didn't produce the lag problem, so this suggests it might be a qlog bug.

QLog Version

0.44.1

Which OS are you using?

Linux

QLog Installation Method

DEB/RPM

Installation Details

Can also reproduce on my own builds or older versions

[aa5sh]

Ok weird note for this one. I typically use QLog on MacOS with SmartSDR for MacOS. For some reason was having problems getting FLRig to talk with it. I did once and I noticed right off what you are saying with FLRig alone the PTT was as expected and we I point QLog to it there was inconsistent and slow.

I was going to try and grab a Debug to look at the messages (https://github.com/foldynl/QLog/wiki/Debug-Log-Level) and I couldn't get FLRig to connect. So I launched FLRig on a windows PC to a Windows SmartSDR instance and I didn't notice the PTT issues in QLog.

You may want to get a debug log. You can filter to just the rig messages like this:
QT_LOGGING_RULES=qlog.rig.*.debug=true ./qlog

Michael, AA5SH

[foldynl]

Hi, the debug output is not necessary in this case. I can replicate it.

[foldynl]

First of all, thank you very much for your perfect description of the issue. It helps me. Unfortunately, I don't have a solution for you now. The issue lies somewhere between Hamlib and Flrig. Here's why I think so. I did several tests:

1. I used curl to send requests to Flrig. In version 2.0.04, the response times were highly variable, and even though I was connected via localhost, sometimes the response time was as high as 0.4 seconds! I tested the lates Flrig 2.0.05, where the response times were more stable, but occasionally still long. This seems to indicate some issue within Flrig.

2. Hamlib. I dived into the analysis and discovered several interesting things. One is that there appears to be some kind of caching mechanism that seems to be based on the response time. So when the response times are long, the cache duration becomes longer as well. Another issue seems to be with asynchronous reading in Hamlib which caused that some response from Flrig takes 2-4 seconds !!!.

Keep in mind that QLog uses the Hamlib API. What is retrieved through the API is exactly what gets displayed. If getFreq sometimes takes a few milliseconds and other times several seconds, QLog can't do anything about it.

Even though I tried setting the poll time in QLog to 1–2 seconds, which somewhat improved the situation, the problem wasn't resolved. I’ll try experimenting with Hamlib’s cache next time. If that doesn’t help, it will be necessary to implement the Flrig interface directly in QLog, which will take some time.

What I would recommend is to use rigctld instead if you need to share a rig connection.