PTT takes several attempts to stop from the FreeDV GUI.

[barjac]

I am reporting this on behalf of another station (G6WPJ) who has been trying to resolve this for some months.

His transmissions continue after hitting the PTT in FreeDV as he struggles to stop the transmission.
After several attempts it does finally work but is very hit and miss.

Until it does work he is still reporting as being in TX in the reporter.

Normally he is using omnirig in Windows but today tried switching to flrig which apparently also has a GUI PTT button.

Using the PTT in flrig works instantly, but he is then not reporting when in TX.

From the above it would seem to me to be a FreeDV issue but I could be wrong. :)

I am sending a link to this issue to him, so he may be able to add any further system information requested.

[tmiw]

What radio is he using? Based on the code it shouldn't matter whether OmniRig or Hamlib/FLrig is used for the purposes of reporting.

[barjac]

I'm hoping Matt will appear here to answer any more questions, however I only mentioned the reporter to maybe help indicate where the issue might be. The main issue is that the PTT button is being mainly ignored at the end of each transmission. TX start is fine.

Matt reads the RSGB news every Sunday morning and hosts the general net afterwards so I know that this has been happening for a long time now.

He tested with flrig just to see if it was only related to omnirig but the result is the same.

However apparently flrig has a GUI with a PTT. This works instantly where the FeeDV one has the problem.

Matt is very busy, so there may be delays in replies.

[tmiw]

If it weren't for being able to stop PTT from within flrig, this would sound a lot like RFI. Might still be worth testing reducing power as much as possible just in case.

Anyway, I'll wait until I hear more about the setup (such as rig type).

[Tyrbiter]

https://www.qrz.com/db/G6WPJ gives a lot of detail on the station, including a comprehensive HF station diagram and also a software interaction diagram.

It probably explains why this issue is long-standing and difficult to debug...

[tmiw]

It looks like Hamlib 4.6 (not sure about 4.5.5) has support for the FDM-DUO:

Mooneers-16-MacBook-Pro-16158:hamlib mooneer$ bin/rigctl -l | grep FDM
 33001  ELAD                   FDM-DUO                 20220608.0      Stable      RIG_MODEL_ELAD_FDM_DUO

Has he tried a direct Hamlib connection yet (vs. going through FLrig)? It probably means no other apps can be used at the same time but it might help rule out some possible causes.

[barjac]

@Tyrbiter
I had forgotten about his qrz page - thanks!

@tmiw
I am a little puzzled by what he says about not being able to access his radio from more than one application at once in his 'rant'.

I am sure that we did talk about using rigctld as I do which does allow FreeDV and klog to both interact with my radio from both applications and multiple instances of FreeDV on different machines simultaneously.

But no I don't think he has tried this and there may be a good reason that I have forgotten, possibly to do with Windows.

I did tell him about this github issue so he may be too busy or AFK just now. We will certainly have a chat at weekend if not before.

...and

[baz@leno ~]$ rigctl -V
rigctl Hamlib 4.5.5 Apr 05 11:43:08Z 2023 SHA=6eecd3
[baz@leno ~]$ rigctl -l | grep FDM
 33001  ELAD                   FDM-DUO                 20220608.0      Stable      RIG_MODEL_ELAD_FDM_DUO

[g6wpj]

Sorry it has taken me so long to comment here.

I have tried rigctl, flrig and omnirig over the last couple of three months.

This has included running rigctl and flrig with diagnostic messages switched on and monitoring when the ppt sticks and what is reported by both of the control applications in their debug texts.

Essentially I see the same behaviour with both applications. The delay timing vs the diagnostic message reporting shows the delay being in the communication from FreeDV to the serial port control app. In other words there are no messages printed by either rigctl or flrig suggesting a fault they simply do not receive the 'ppt-off' signal from FreeDV. When they do receive it they 'de-key' promptly as expected.

I have concluded the delay may be CPU resource related and FreeDV in my installation is not getting round to servicing the 'ptt button mouse click' from the GUI in a timely manner.

I offer the following thoughts...

There is never a delay to making the ppt active, as soon as i hit the 'ppt on' button in the GUI the serial control app reacts and the radio goes to Tx.

If I run less 'other stuff' on the PC the ptt delay is less pronounced and happens much much less often

I do not see the delay with other applications such as WSJT-X. or FreeData or VarAC

I cannot be certain but I do not think it is RFI related as it does not happen with other apps and I do not see a delay between 'ptt-off' diagnostic messages being printed on the screen by rigctl or flrig and the radio returning to Rx.

So my own feeling is there is 'something' happening in FreeDV which my overloaded PC is revealing or making worse. However given if I just run less, I can pretty much avoid the issue I am happy if this is made a low priority to be looked at.

FreeDV is a great piece of software and I must say thank you to the team for all their great work!

73 Matt

[tmiw]

Thanks for the update! I realize this is mainly about TX but one thing you can try is going to Tools->Options->Modem and unchecking "Simultaneously Decode All HF Modes". That does mean you'll have to push Stop to change modes (i.e. from 700D to 700E) but FreeDV should also use less CPU as it's only decoding one mode at a time.

You can also uncheck the "Use single thread" option there too if you do decide to keep "Simultaneously Decode All HF Modes" turned on. This will allow better usage of whatever cores you have in your system during decode.

Hopefully one of those things helps. There are a lot of changes being made to FreeDV as of late, so it may be a while before we try to optimize things.