[Bug]: PTT fails to key on audio sometimes, or fails to unkey after audio is finished sometimes

[k8wu]

FreeDATA Version

v0.17.3-beta

What operating system are you using?

Windows

Operating System Version

Windows 11 Home 24H2

Architecture

x64

Area of problem

Rig Control

Describe the bug

Sometimes, the rig (in this case, an Icom IC-7300) will not key up when it's supposed to, or it will not unkey when the audio is finished, resulting in data never being sent or responses from the remote side being missed. Here's what it looks like when the latter happens (no screenshots of the former yet, but I can probably get some if I'm in front of my computer when it happens vs. being remoted in):

This happens with Hamlib and Flrig. I use Flrig in my shack, but I've tested using Hamlib directly and it still happens, though only every few overs.

No other digital mode program behaves like this on my shack PC.

To Reproduce

The best way to reproduce this is to have a QSO in conditions where there may be a lot of retries due to poor SNRs.

Expected behavior

I would expect the PTT to key when there is audio to send, and to unkey as soon as there isn't.

Screenshots

Putting the screenshot here as well for completeness's sake.

Log Files

No response

Additional context

No response

[DJ2LS]

Thanks for the feedback, @k8wu
To me this looks a bit like EMV problems, as the problem exists with Flrig as well. The blue bars on your waterfall are showing, there is no audio available, which is an indicator for problems with the audio stream, recovering after a short time.
You could test this as well with "VOX", maybe keying your radio manually for testing purposes, to see if it happens as well.

[k8wu]

I'm not sure what you mean by "EMV problems", but watching what Flrig does, it seems that either the program doesn't send a PTT key-up event properly and then sends audio while the rig is not keyed up, or after the audio stops, the program doesn't send a PTT key-off event properly and then it is transmitting nothing while the rig is in transmit mode.

Perhaps implementing some sort of check to see if the PTT is really keyed up after sending a key-up event and sending additional key-up events if it is found that the rig is not reporting the PTT being keyed up, and vice-versa, would be the solution here. I don't think it's a problem with the audio chain.

[DJ2LS]

EMV might be better translated as EMC, describing issues because of RF which intereferes with USB port.

The problem with flrig is familiar to me. I have this as well, after the USB connection is interrupted and restored again without restating flrig. So question is then why it occurs for you as well. That's why I was thinking about issues with usb port when transmitting because the waterfall screen looks like this could happen in your case 🤔

But I'm sure we will fix this somehow 😊

[k8wu]

When this issue happens and the PTT does not actually key down, this is what shows up in the console:

2025-06-08 15:17:25 [debug    ] Event:                         ev={'ptt': True}
Set PTT failed: Request-sent
Polling error: Request-sent
Set PTT failed: Idle
2025-06-08 15:17:31 [debug    ] Event:                         ev={'ptt': False}

Normally, you only see this when the PTT keys up and down successfully:

2025-06-08 15:19:14 [debug    ] Event:                         ev={'ptt': True}
2025-06-08 15:19:20 [debug    ] Event:                         ev={'ptt': False}

A similar thing happens when the PTT is supposed to key up but does not do it - but of course, in that case, the ptt event's True and False states are reversed.

[k8wu]

FYI - this behavior is still prevalent in 0.17.6.