VOX tail for packet mode

[VK3KYY]

Sure. In summary:

- Disable the VOX pre-triggering timer
- Remove the check for AUDIO_AMP_MODE_RF when doing getAudioAmpStatus() to allow VOX to transmit with an open squelch
- Change the VOX tail time to a 10ms stepping (though in practice, the SNR threshold has some hold which means values below 100ms only work sometimes, not consistently)

Do you have to 'tune' the vox tail for your specific TNC ? I was hoping perhaps we could just add a menu called VOX or "VOX Mode" and have that as "Voice" or "Packet", and then set some default settings

I suppose setting VOX Mode to Packet could change the VOX tail setting to something like 100mS and change the step size etc

i.e it would be a pain in the ass for Voice VOX to have to adjust the Tail in 10mS steps

[M7PKY]

Hi VK3KYY,

I have been looking at this with M0GZP too,

I think the only tuning that really would need to be done is to ensure the volume coming into the radio is good enough to trigger and maintain VOX throughout the transmission.

Realistically, the shorter the VOX tail the better, because TNCs have a TX tail too after the actual data which is often adjustable. As long as all audio produced at the end of the transmission is captured and sent, it'll work fine.

It might be possible to further reduce the VOX tail itself, however this is not something I have played with. It would appear that values below 100ms aren't very reliable because it takes time for the sampled value to fall back below the threshold. This is of course improved by setting the threshold higher but still not ideal.

I think having a separate VOX tail stepping (and probably an entirely separate VOX unit value set in nvram) for Packet would be ideal, with the resulting menu options maybe becoming VOX Tail P and VOX Tail V? Packet mode would of course also need to remove the pre-trigger timer and allow VOX TX either during any RX or during RX when the squelch is set to open (should voice mode also allow VOX TX to occur whilst RXing with squelch set to open?)

The VOX pre-triggering timer was removed because you want to get the TX Delay (the preamble tone/byte before packet data) as short as possible. 100ms seems a popular choice but it can go lower. I'd say that the changes outlined by M0GZP triggers VOX pretty quickly but could be faster as it is a bit inconsistent.

[VK3KYY]

Hi VK3KYY,

I have been looking at this with M0GZP too,

I think the only tuning that really would need to be done is to ensure the volume coming into the radio is good enough to trigger and maintain VOX throughout the transmission.

Realistically, the shorter the VOX tail the better, because TNCs have a TX tail too after the actual data which is often adjustable. As long as all audio produced at the end of the transmission is captured and sent, it'll work fine.

It might be possible to further reduce the VOX tail itself, however this is not something I have played with. It would appear that values below 100ms aren't very reliable because it takes time for the sampled value to fall back below the threshold. This is of course improved by setting the threshold higher but still not ideal.

I think having a separate VOX tail stepping (and probably an entirely separate VOX unit value set in nvram) for Packet would be ideal, with the resulting menu options maybe becoming VOX Tail P and VOX Tail V? Packet mode would of course also need to remove the pre-trigger timer and allow VOX TX either during any RX or during RX when the squelch is set to open (should voice mode also allow VOX TX to occur whilst RXing with squelch set to open?)

The VOX pre-triggering timer was removed because you want to get the TX Delay (the preamble tone/byte before packet data) as short as possible. 100ms seems a popular choice but it can go lower. I'd say that the changes outlined by M0GZP triggers VOX pretty quickly but could be faster as it is a bit inconsistent.

Adding separate settings like Vox Tail P and Vox Tail V will cause problems because 99.99% of people will be using VOX for Voice, and it will overcomplicate things, also this may not even translate easily.

So if this does ever get implemented it would need to be much simpler

[M7PKY]

Hi VK3KYY,

I have been looking at this with M0GZP too,

I think the only tuning that really would need to be done is to ensure the volume coming into the radio is good enough to trigger and maintain VOX throughout the transmission.

Realistically, the shorter the VOX tail the better, because TNCs have a TX tail too after the actual data which is often adjustable. As long as all audio produced at the end of the transmission is captured and sent, it'll work fine.

It might be possible to further reduce the VOX tail itself, however this is not something I have played with. It would appear that values below 100ms aren't very reliable because it takes time for the sampled value to fall back below the threshold. This is of course improved by setting the threshold higher but still not ideal.

I think having a separate VOX tail stepping (and probably an entirely separate VOX unit value set in nvram) for Packet would be ideal, with the resulting menu options maybe becoming VOX Tail P and VOX Tail V? Packet mode would of course also need to remove the pre-trigger timer and allow VOX TX either during any RX or during RX when the squelch is set to open (should voice mode also allow VOX TX to occur whilst RXing with squelch set to open?)

The VOX pre-triggering timer was removed because you want to get the TX Delay (the preamble tone/byte before packet data) as short as possible. 100ms seems a popular choice but it can go lower. I'd say that the changes outlined by M0GZP triggers VOX pretty quickly but could be faster as it is a bit inconsistent.

Adding separate settings like Vox Tail P and Vox Tail V will cause problems because 99.99% of people will be using VOX for Voice, and it will overcomplicate things, also this may not even translate easily.

So if this does ever get implemented it would need to be much simpler

I would guess just having VOX Tail change purpose (and target NVRAM value) depending on VOX mode selection would be sufficient? Essentially combining the P and V options into one menu option based on which mode is selected.

[VK3KYY]

Yes.. basically I think we would need to add 1 UI setting for VOX Mode,

Not sure if we would internally store separate values for packet and voice, as NV space is limited and people won't often be switching between voice and packet vox use

[M7PKY]

Yes.. basically I think we would need to add 1 UI setting for VOX Mode,

Not sure if we would internally store separate values for packet and voice, as NV space is limited and people won't often be switching between voice and packet vox use

If only one value in NVRAM is stored for VOX tail, would switching from Packet to Voice mode force values below 0.5s to be defaulted to 0.5s and values in between the .5s be rounded? Or would it be reasonable to just allow 100ms steps on both Voice and Packet modes, with the only effects of Packet mode becoming removal of the pre triggering timer and allowing TX during open squelch RX?

[VK3KYY]

If only one value in NVRAM is stored for VOX tail, would switching from Packet to Voice mode force values below 0.5s to be defaulted to 0.5s and values in between the .5s be rounded? Or would it be reasonable to just allow 100ms steps on both Voice and Packet modes, with the only effects of Packet mode becoming removal of the pre triggering timer and allowing TX during open squelch RX?

I would need to look at the code, but unfortunately at the moment I'm busy with other things.