FreeDATA icon indicating copy to clipboard operation
FreeDATA copied to clipboard

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

Open k8wu opened this issue 9 months ago • 5 comments

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): Image

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.

Image

Log Files

No response

Additional context

No response

k8wu avatar Jun 06 '25 00:06 k8wu

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.

DJ2LS avatar Jun 06 '25 08:06 DJ2LS

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.

k8wu avatar Jun 06 '25 12:06 k8wu

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 😊

DJ2LS avatar Jun 06 '25 17:06 DJ2LS

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 avatar Jun 08 '25 19:06 k8wu

FYI - this behavior is still prevalent in 0.17.6.

k8wu avatar Aug 18 '25 23:08 k8wu