This looks ok to me and it passes the CI checks. I have not built it and tested it. I never use Turbo mode as that mode is not really suitable for weak signal/QRP operation and I've never seen any other JS8 operators using it either. There is some built-in latency once PTT is pushed just to close contacts in transmit relays, and no two rigs are probably the same. So without extensive testing on various rigs and equipment I don't know if this is valid or not.

@wmiler what do you think?

Or I'll put this a different way; I can approve the code because it LOOKS sound and will build. But it is based on the experience with one operating system, one rig, and I haven't seen any logging output that proves that it actually fixes the issue. I think it needs extensive testing across all three platforms, with various equipment.

So we're moving a hardwired unsigned int to a public const to be able to use it in mainwindow to modify the tx delay. Does this work for VOX? JS8 does not emit a keying tone for the VOX users to account for delay in transmit relays. Software defined radios are not real-time with their built-in delay in audio processing, etc..

So at present I can't approve it for merge until that extensive testing is done.

I haven't built this yet, so I haven't tried it on win10 or Ubuntu. I'll add it to my list for tonight.

I'll also try it on MacOS with a VOX setup and see what it does. I don't use VOX but a lot of users with small, economical QRP radios do. I think it needs to be tested in actual on-air conditions

What would be the optimal setting for tx delay in the Advanced section of the Radio tab? I built this and configured VOX on my FlexRadio and tested it with a fellow who's only about 10 miles away. I cannot get a single decode on his end with VOX keying the transmitter. With VOX it doesn't hold PTT between frames. He can see my signal on the waterfall but every frame is dropped no matter what speed mode I use.

Edit: I did a little troubleshooting with this. With VOX there's audio being sent before the relays in the radio settle. So every frame is corrupted.

I never use Turbo mode ... and I've never seen any other JS8 operators using it either.

For what its worth: Turbo is a blessing when conditions allow it, for ragchew QSOs like I like to engage in. I use it whenever I can.

I never use Turbo mode as that mode is not really suitable for weak signal/QRP operation ...

I only do QRP operation. Our BNetzA requires some paperwork if your antenna puts out more than 10 W EIRP. Completing that paperwork isn't really feasible when you're in a rented flat and put out a couple wires when operating and pull them back in when not, like I am. So I stick to QRP all the time, which results in less than 10 W EIRP out of common antennas. So I dare to contradict your assessment that "Turbo mode ... is not really suitable for ... QRP operation". That is simply not my experience, as a QRP operator. Of course, I can't use it all the time, but I can use it some of the time, and when that's the case, my ragchew QSOs become really slick.

What would be the optimal setting for tx delay in the Advanced section of the Radio tab? I built this and configured VOX on my FlexRadio and tested it with a fellow who's only about 10 miles away. I cannot get a single decode on his end with VOX keying the transmitter. With VOX it doesn't hold PTT between frames. He can see my signal on the waterfall but every frame is dropped no matter what speed mode I use.

Edit: I did a little troubleshooting with this. With VOX there's audio being sent before the relays in the radio settle. So every frame is corrupted.

I remember looking at the code of the modulator: It only starts emitting non-zero audio samples to the sound card when the symbols start. This means that JS8 does not presently support VOX. We might want to change that.

Would you kindly open a ticket for that?

So at present I can't approve it for merge until that extensive testing is done.

It seems to me you are afraid of things that would equally go wrong if a user would chose to increase whatever tx-delay they had configured by 100 ms. But maybe I'm missing something.

and I haven't seen any logging output that proves that it actually fixes the issue

You could obtain such output yourself, but I can also help you with that.

mainwindow.js8: 25-11-20T07:28:53.901Z: Setting PTT to on
configuration.js8: 25-11-20T07:28:53.901Z: Configuration::transceiver_ptt: true Transceiver::TransceiverState(online: yes Frequency {3578000Hz, 0Hz} Transceiver::DIG_U; SPLIT: off; PTT: off)
transceiverbase.js8: 25-11-20T07:28:53.901Z: "TransceiverBase::set:" #: 15 Transceiver::TransceiverState(online: yes Frequency {3578000Hz, 0Hz} Transceiver::DIG_U; SPLIT: off; PTT: off)
transceiverbase.js8: 25-11-20T07:28:53.901Z: "TransceiverBase::set:" #: 16 Transceiver::TransceiverState(online: yes Frequency {3578000Hz, 0Hz} Transceiver::DIG_U; SPLIT: off; PTT: on)
mainwindow.js8: 25-11-20T07:28:53.901Z: -> msg: dPg2Mbxnu2++                
transceiverbase.js8: 25-11-20T07:28:53.901Z: "HamlibTransceiver::do_ptt:" true Transceiver::TransceiverState(online: yes Frequency {3578000Hz, 0Hz} Transceiver::DIG_U; SPLIT: unknown; PTT: off) reversed = false
mainwindow.js8: 25-11-20T07:28:53.901Z: -> bit: 4
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 0 = 0
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 1 = 6
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 2 = 2
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 3 = 3
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 4 = 5
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 5 = 4
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 6 = 1
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 72 = 2
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 73 = 5
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 74 = 0
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 75 = 6
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 76 = 4
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 77 = 1
mainwindow.js8: 25-11-20T07:28:53.901Z: -> tone 78 = 3
configuration.js8: 25-11-20T07:28:53.902Z: Configuration::handle_transceiver_update: Transceiver State #: 15 Transceiver::TransceiverState(online: yes Frequency {3578000Hz, 0Hz} Transceiver::DIG_U; SPLIT: unknown; PTT: off)
configuration.js8: 25-11-20T07:28:54.006Z: Configuration::handle_transceiver_update: Transceiver State #: 16 Transceiver::TransceiverState(online: yes Frequency {3578000Hz, 0Hz} Transceiver::DIG_U; SPLIT: unknown; PTT: on)
mainwindow.js8: 25-11-20T07:28:54.006Z: MainWindow::handle_transceiver_update: Transceiver::TransceiverState(online: yes Frequency {3578000Hz, 0Hz} Transceiver::DIG_U; SPLIT: unknown; PTT: on)
mainwindow.js8: 25-11-20T07:28:54.006Z: Asking the modulator to emit audio.
modulator.js8: 25-11-20T07:28:54.006Z: Starting 6 ms late into transmission, skipping some of the 100 ms start delay
modulator.js8: 25-11-20T07:28:54.006Z: Symbol transmission to start after 94 ms of silence.

Well, there is some people using VOX but I must not have the right setup for it. Using normal PTT with CAT control this seems to work fine but I'm wondering what it does that the user can't already do with the settings in the UI.

@aknrdureegaesr what are your settings for Tx delay in the UI? I'm trying to duplicate the original issue with 2.4.0 and I'm not getting the same results - Turbo mode works fine in 2.4.0 with no leading tones clipped.

I have no tx_delay configured via the UI, that is, 0 ms.

Turbo mode works fine in 2.4.0 with no leading tones clipped.

I've been using

QT_LOGGING_RULES='configuration.js8=true;mainwindow.js8=true;transceiverbase.js8=true;modulator.js8=true;soundout.js8=true' ./JS8Call-improved

but the really important one is modulator.js8=true . What does it report? In my experiments with 2.4.0, the key lines that produces with 2.4.0 was (see #44):

modulator.js8: 25-11-17T17:23:18.101Z: Starting 101 ms late into transmission, cutting away initial symbol(s).
modulator.js8: 25-11-17T17:23:18.101Z: Symbol transmission to start immediately.

Most of the clipping leaves out the 100 ms dead air time that is intended to precede turbo symbols. So there was only 1 ms missing of symbol time. We were lucky here that the fudge time in transceiver base happened to be the exact same as the initial dead air time of Turbo and shorter than the initial dead air time of the other modes. I didn't bother to investigate the consequences of the late start, as the fix is trivial (or I consider it to be trivial, which may not be the same thing). Possibly, we may be producing key clicks. Not sure.

Anyway. Repeating this with my fix, I get:

modulator.js8: 25-11-20T07:28:54.006Z: Starting 6 ms late into transmission, skipping some of the 100 ms start delay
modulator.js8: 25-11-20T07:28:54.006Z: Symbol transmission to start after 94 ms of silence.

Ok, thanks. Will try to duplicate that here on MacOS later this evening when I get some time.

@aknrdureegaesr @wmiler OK, so I think I arrived at the crux of the issue.

When a fresh install of JS8Call-improved is done, the default setting for the Tx delay is 200 milliseconds. This is generally the minimum accepted time to allow for relay settling in the transmitter. If audio is transmitted before the tx relays settle, it will clip the leading tones. Some people, if they are using an amplifier, set this to 0.3s to allow extra time for the relay in the amp to settle on key down. Even if the amp is on standby it still uses the rx/tx relay in the amp.

So it would appear to me that you misconfigured your settings to create an issue. Then coded a "fix" for something that doesn't need to be "fixed". If everybody does this it adds code bloat.

While the code is ok, and doesn't really hurt anything, is it necessary? I don't think so.

However, during testing of this I did discover that VOX does not work properly with my setup. I know it works with some because some people are using it. But on my setup it has the same issue as setting the Tx delay in the UI to 0ms. A more appropriate "fix" would be to have JS8Call-improved send a keying tone when VOX is selected that obeys the same Tx delay that is set in the UI before sending JS8 tones. Otherwise, while I can approve the code here because it doesn't break anything, I can't approve it for merge because I don't see what it "fixes".

Ok, we can do another fix. Right now, JS8Call-improved misbehaves if the tx delay is set below 100 ms. So we could alternatively change the UI part so it no longer allows a tx delay below 100 ms to be configured. That would be fine with me, too. I'll change my PR towards that end.

The whole VOX thing is a completely different issue, orthogonal to what I'm trying to do here.

I know it works with some because some people are using it.

Just because some people use it does not guarantee it works. I think everybody who's currently using VOX is missing initial symbol data in their HF output for as long as the VOX takes to engage. The error correction then kicks in and the missing symbols do no harm, if the rest of the transmission is high enough above the minimal SNR required for that mode.

Do we have a ticket for "VOX does not work as intended yet"?

Right now, JS8Call-improved misbehaves if the tx delay is set below 100 ms. So we could alternatively change the UI part so it no longer allows a tx delay below 100 ms to be configured. That would be fine with me, too. I'll change my PR towards that end.

@aknrdureegaesr that would be a good change. As you proved with this PR, a person can actually partially break tx if it is set to zero. I can't actually think of a reason anybody would do that, but limiting the minimum setting to 0.1s, and noting that in the tooltip that pops up over the setting would be good.

Do we have a ticket for "VOX does not work as intended yet"?

No, I'll go create one.

@aknrdureegaesr I'll make an adjustment to the minimum Tx delay setting so it can't go below 100 milliseconds and push the change to update the PR. I think that will solve the issue that was raised, and in reality a Tx delay setting of zero should never be allowed anyway because it will definitely clip leading symbols, similar to VOX.

VOX did not work before this PR, and it won't work properly after. But I wrote a ticket for that one so we can remember to look at it.

After the build checks complete I will merge this. It is a fairly trivial change.