Intermittent "Rig Error: Get Frequency Error - Communication timed out" (FT-710 using FTDX-10 profile)

[TecnoTalarn]

Description

When using QLog with Hamlib rig control, CAT communication works as expected most of the time. However, intermittent popup errors appear during operation stating:
Rig Error: Get Frequency Error

Error Detail: Communication timed out

Hardware & Software Setup

• Transceiver: Yaesu FT-710
• QLog Version: 0.51.1 (Qt 6.11.1, Hamlib 4.7.2)
• OS: macOS 27.0 arm64

CAT / Rig Configuration

• Interface: Hamlib — Yaesu FTDX-10 (20241118.9)
  (Note: I am intentionally using the FTDX-10 profile instead of the FT-710 profile because the FT-710 profile currently causes an issue where the VFO bounces/toggles back and forth when changing bands).
• Port Type: Serial (/dev/cu.usbserial-011BC95D0)
• Poll Interval: 100 ms
• Baudrate: 38400
• Data Bits: 8 | Stop Bits: 1
• Flow Control: None | Parity: None
• DTR: None | RTS: None
• PTT Type: CAT
• Share Rig via port: Enabled (4532)

Steps to Reproduce

1. Configure a CAT profile for FT-710 using the FTDX-10 Hamlib driver as described above.
2. Connect to the transceiver and operate normally.
3. Frequency updates work, but periodically (intermittently), the timeout popup dialog interrupts the workflow.

Additional Context / Questions

1. Is the 100 ms polling interval at 38400 baud causing serial buffer starvation on macOS, leading to intermittent CAT timeouts?
2. Is there any known fix for the native FT-710 Hamlib profile regarding the VFO bounce issue on band changes?

---

QLog Version

0.51.1

Which OS are you using?

macOS

QLog Installation Method

DMG

Installation Details

[foldynl]

Is the 100 ms polling interval at 38400 baud causing serial buffer starvation on macOS, leading to intermittent CAT timeouts?

I can answer just following question. 100ms is really very fast and unnecessary. I think hamlib itself has an internal update somewhere around 500ms (I'm not sure about that). So, if I were you, I would start trying some reasonable setting somewhere around 1000ms first.

Otherwise, there have already been several reports about this rig. I’m not sure whether they were from you or someone else, but Hamlib doesn’t seem to get along very well with this radio. Try searching through the closed issues and discussions.

[leonardinux]

Same problem on 0.52.0 using FT991A with hamlib.
It seems to be problematic using rigctld.exe but if I use external rigctld.exe and set QLog to use rigctl.exe with "hamlib net" model 02 it works.
Take a look at rigctld.exe version included on latest QLog deploy and relative settings... on previous version it works fine!

73 de Leo IZ5FSA

[foldynl]

@leonardinux , please, could you send me a screenshot of your Rig setting for the case when timeout occurs ? Qlog from 0.52 started using the settings that it previously omitted for the internal rigctld. Please also send me the settings of your external rigctld (command) that you think works. So that I can compare the two settings.

[leonardinux]

@foldynl , sorry for delay but I'm on holydays at the tuscany seaside... now listening on VarAC 80M

This is the FT991A setup that doesn't work.

Then I run hamlib from cmd.exe (I am now ona Win11 machine) as:

rigctld.exe -m 1035 -r COM6 -s 38400

and then use this working setup

How can I help debugging???

73 de Leo IZ5FSA

[aa5sh]

Try setting the Flow Control to Hardware. in looking at the capabilities output for the 991 it looks like that is the default setting that rigctld would use.

…

On Aug 24, 2026, at 2:22 PM, IZ5FSA ***@***.***> wrote: leonardinux left a comment (foldynl/QLog#1132) <#1132 (comment)> @foldynl <https://github.com/foldynl> , sorry for delay but I'm on holydays at the tuscany seaside... now listening on VarAC 80M This is the FT991A setup that doesn't work. Image: Image (view on web) <https://github.com/user-attachments/assets/552f7b56-fbef-420a-991e-48ce713f540d> Then I run hamlib from cmd.exe (I am now ona Win11 machine) as: rigctld.exe -m 1035 -r COM6 -s 38400 and then use this working setup Image: Image (view on web) <https://github.com/user-attachments/assets/57711675-c424-416c-8cda-26d904595536> How can I help debugging??? 73 de Leo IZ5FSA — Reply to this email directly, view it on GitHub <#1132?email_source=notifications&email_token=AUEEMXXJD4ZONKUZCZZ4XI35LSIXTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBQGAYTONJTHE2KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-5400175394>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUEEMXTDL5ALR5WQRB6TWWD5LSIXTAVCNFSNUABFKJSXA33TNF2G64TZHMZTQNZUG4ZDCMJXHNEXG43VMU5TKMJTHA2DCNJZGQY2C5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AUEEMXWH7IPLKIPWRXXLGBT5LSIXTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBQGAYTONJTHE2KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AUEEMXW4I3QFIRGK35QP56D5LSIXTA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBQGAYTONJTHE2KM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.

[foldynl]

As Michael correctly pointed out, you need to use the Hardware setting.

There was a bug in QLog because I overlooked the fact that None is a valid value in Hamlib. Before version 0.52, when the value was set to None, QLog did not set anything. For Hamlib, this meant using the default value, which in your case is Hardware.

Now QLog explicitly sets these None values. For Hamlib, this means “do not use the default value; use the value provided by QLog.” I think this behavior is more correct than before.

However, one thing is wrong and I need to fix it: these default values are not preselected when a rig is configured in QLog. This should be fixed.

[leonardinux]

Yes, the flow control set to HW solve the issue.
Thank you @aa5sh and @foldynl

73 de Leo IZ5FSA