Optional delay after rig is switched to TX (by hamlib/rigctld) before audio (i.e. RF) is output and reverse at end of TX.

[barjac]

Contact Details

G4MKT (me). Not sure who else this affects at present probably many others will hit this issue in the current noise environment in which we are living.

Feature for this project

It is a feature to solve a potential technical issue. Please read on:

It is my intention to test a receive noise cancelling device in the antenna feed line of a transceiver. Others are doing this but with separate TX and RX.

At present I assume that FreeDV audio out and the PTT are activated simultaneously or within a few ms at most and I don't see any config settings to change this.

If the radio PTT is controlled directly by hamlib then I have no means of delaying it until the RX noise cancelling device can be switched out of line before it being destroyed by RF.

If FreeDV could optionally delay the audio transmission until after the rig PTT command then the noise cancelling device could be switched out of line in time and the issue could be solved.
For absolute safety the audio should also stop prior to the PTT being released by a similar delay.
In practice I think 50ms delay would be adequate but a user setting would be ideal.

I have used this timing in a similar way on a linear (for SSB) connected to the same radio, so the mic PTT switches the linear into TX 50ms before the PTT signal is passed to the rig and also on PTT release the rig loses PTT 50ms before the linear. This has eliminated contact burn on the linear TX/RX relay.

The same hardware approach is not possible when hamlib is controlling the rig internal PTT directly, so the only solution I can see is in software.

VHF/UHF

None

Deprecated features

None

Non-standard compiler

None

Non-standard compiler

None

Implementation assistance

Testing PRs as I always do.

Support assistance

I am 76 now so 5 years may be asking too much! :)
I maintain many radio related packages for Mageia Linux including FreeDV so will continue while I can.

[tmiw]

Thanks for the request. Out of curiosity:

1. Which device is this?
2. Do any other applications implement this feature?

[barjac]

Thanks for the request. Out of curiosity:

1. Which device is this?

There are several but there was an article written in Practical Wireless in March 2014. Several FreeDV stations in the UK are using these or similar to good effect and decoding signals that they cannot otherwise.
Commercial units from China are available (Google 'ebay HF noise cancel'.) as kits or built PCB and others by companies like MFJ. How/if they resolve this problem I don't know.

2. Do any other applications implement this feature?

No idea, as I have only thought about doing some testing of this with regard to FreeDV.

I could block the audio until 50ms after the PTT is output from the rig as my audio is a physical cable, however there is no way that I could detect the PTT end in advance of it happening, so that would be of no use.

For rigs with USB audio cards and hamlib PTT control there is no way to delay either the audio or the PTT, unless this feature is in the rig firmware. I don't have one to test.

I think it can only be done by the FreeDV software as it's the only place that the start and end of transmission can be known in advance.

Required psudo logic:
Click on PTT in FreeDV to start TX, send StartPTT command, wait DelayTime and start audio out.
Click PTT again to stop, stop audio out, wait DelayTime and send StopPTT command.

The auxiliary PTT out from the rig (usually used to switch a linear) could then control the TX/RX switching of the noise canceller (or a preamp etc.) while no RF is present.

[tmiw]

1. Which device is this?

There are several but there was an article written in Practical Wireless in March 2014. Several FreeDV stations in the UK are using these or similar to good effect and decoding signals that they cannot otherwise. Commercial units from China are available (Google 'ebay HF noise cancel'.) as kits or built PCB and others by companies like MFJ. How/if they resolve this problem I don't know.

The main reason why I ask is that I've used an ANC-4 before (which doesn't have a PTT line) and there didn't seem to be any negative effects from it when transmitting other 100% duty cycle modes through it. Granted, I only have 100W max power capability here and typically run less than that, so the ANC-4 could very well not work as well with more power.

2. Do any other applications implement this feature?

No idea, as I have only thought about doing some testing of this with regard to FreeDV.

FWIW I took a look at WSJT-X (my typical benchmark for feature requests) and it seems there is a delay feature:

As I hadn't ever touched the default here (and I'm not sure if anyone else has, either), I suspect it might be okay to just hardcode some sane value (50-200ms or so). Regardless, we'll need to discuss to see if we want to include this in the first place.

[barjac]

Thanks for looking!
Yes I think that does exactly what is needed.

It does not mention whether this applies in reverse on release of PTT, maybe that would not be needed as by the time any relay has changed over the TX (audio) should have stopped anyway.

"

Set Tx delay to a number larger than the default 0.2 s to create
a larger delay between execution of a command to enable PTT and onset
of Tx audio.

	For the health of your T/R relays and external preamplifier, we strongly recommend using a hardware sequencer and testing to make sure that sequencing is correct."

I don't understand how a hardware sequencer can be of any use in this case! Where would it get the PTT signal to start the sequence?

[barjac]

Oops!

[tmiw]

This was approved by the PLT during our meeting yesterday. Changed tags accordingly and will work on this when time permits.

[barjac]

Thanks :)

[tmiw]

Thanks :)

No worries! See #618 for the implementation of this.