SQL_DET for UDP Audio device

[EU4BNC]

Hello. MMDVMHost has recently been modified to broadcast RAW traffic over UDP. Previously, USRP was used to transmit FM to SVXLink, but this was not convenient since DTMF control did not work and voice services did not work. At the moment, SVXLink communicates with MMDVMHost, audio is transmitted, but none of SVXLink's existing SQL_DET analysis methods work correctly. SQL does not close. I would like to ask the SVXLink developer to add a method for processing SQL_DET for "UDP AUDIO DEVICE", which will open SQUELCH when traffic appears on the RX udb:address:port port and close SQUELCH when traffic disappears on the RX udp:address:port.

[XATTA6]

I also have an MMDVM modem that works in FM mode. Currently, DTMF over UDP has started working, and I think it's a good idea to make SQL_DET support based on the availability of data on the UDP port, since VOX does not work quite correctly.

[sp2ong]

I agree that VOX is not the best mechanism used to detect the opening of a "squelch" for UDP stream audio.

We have svxlink in the manual:
The VOX squelch detector determines if there is a signal present by calculating the mean value of the sound samples. The VOX squelch detector behaviour is adjusted with VOX_FILTER_DEPTH and VOX_THRESH.

So the activation of VOX depends on the mean signal amplitude. If the amplitude sent via UDP is low, VOX will not work or will work intermittently. We can try to select the VOX_THRESH value, e.g. 100 to 300 and
SQL_HANGTIME=2500
VOX_FILTER_DEPTH=20

Another method that may work with UDP is to use SQL_DET=SIGLEV

SQL_HANGTIME=150

SIGLEV_DET=NOISE
SIGLEV_SLOPE=1
SIGLEV_OFFSET=0

See chapter CALIBRATING THE SIGNAL LEVEL DETECTOR below for more information. http://www.svxlink.org/doc/man/man5/svxlink.conf.5.html

You can adjust OPEN level
SQL_SIGLEV_OPEN_THRESH=30
SQL_SIGLEV_CLOSE_THRESH=2

But a simple method for UDP audio would probably be useful. If there is no audio, the lock opening status is closed. If the audio stream comes via UDP, the lock opening status is open.

It would be nice if the author of svxlink could advise us how to approach the issue of AUDIO via UDP support in [Rx1]

[EU4BNC]

The problem is that Squelch opens when there is a data stream on the udp port, but does not close because the data stream stops.

[sp2ong]

If it is as you write, then it is a problem because audio is delivered via UDP over the network, we do not have much choice in controlling the opening of the "squelch"

[EU4BNC]

Yes, as far as I understand the principle of operation of SVXLink, in order to interact with MMDVMHost with SVXLink via RAWoverUDP, it is necessary to create another SQL_DET control algorithm.

[sp2ong]

I think maybe this is a general problem when we use AUDIO__DE=udp:127.0.0.1:port_number
in [Rx1], perhaps it was not used much before and it was checked that there is a problem with the VOX method for UDP audio. I guess you can always simulate it by sending audio via UDP, using the netcat tool, etc. to confirm the problem

[EU4BNC]

I guess you are right. Perhaps the developer can add a method for opening and closing SQL_DET based on the presence and absence of traffic on the udp audiodev port.

[sp2ong]

If this problem can be solved, it will be a great added value because we will use svxlink in the native FM mode using MMDVm equipment, giving the possibility of using FM on DV repeaters and the great possibilities offered by svxlink.
Please remember that the FM mode in MMDVM is pure FM mode and there is no FM to DV transcoding.

We will need the help of the author of svxlink to solve this problem.

[sp2ong]

I did a test and cross-connected two svxlinks on two different computers with UDP audio and if VOX is set in SQL_DET, testing different settings, whenever one svxlink sends audio via UDP to the other, the SQL opens

Rx1: The squelch is OPEN (1118)

and does not close after sending the audio via UDP, so it is not a problem of audio sent via UDP with MDVMHost only actually svxlink has a problem with VOX when I use UDP audio in AUDIO_DEV

A request to the author of svxlink if it is possible to submit a solution to the problem of using AUDIO_DEV=udp:127.0.0.1:1234 in [Rx1] method for the correct operation of the SQUELCH opening mechanism. Maybe add SQL_DET=UDP or NET and key the status when audio comes in, opens the SQUELCH and when it doesn't, closes it

[EU4BNC]

Yes, exactly squelch does not close. Therefore, Svxlink continues to keep the remaining repeaters in the active group in transmit mode, and DTMF commands do not work.

[sp2ong]

I did a test with saved DTMF tones in a file that is played and sent from one svxlink to a test svxlink that listens via UDP with the SQL_DET=OPEN option set, which causes the SQUELCH to be permanently open.Thet svxlink that received DTMF via UDP commands were decoded correctly

Rx1: The squelch is OPEN
SimplexLogic: digit=*
SimplexLogic: digit=#
SimplexLogic: digit=9
SimplexLogic: digit=1
SimplexLogic: digit=2
SimplexLogic: digit=6
SimplexLogic: digit=0
SimplexLogic: digit=#

[EU4BNC]

Yes, you are right, everything is recognized, but svxlink does not perform any actions until squelch closes. Therefore, until the problem with squelch is resolved, dtmf commands will not work. As a temporary solution I use squelch by ctss, sometimes it works correctly.

[EU4BNC]

As you can see, I tried to enable the parrot module, but there is no record of its inclusion. And in fact, the module will not work until Squelch closes.

[sp2ong]

All we can do is wait for the problem to be solved. Currently, it is impossible to use svxlink with MMDVM hardware with pure FM, which is a pity.

73

[EU4BNC]

Yes, I would like to ask the developer to participate in solving the problem.

[sp2ong]

I forgot one parameter that might help?
You need to enter it in /etc/default/svxlink (Enable UDP zerofill if set to 1)

ASYNC_AUDIO_UDP_ZEROFILL=1

if you use systemd to start svxlink via /lib/systemd/system/svxlink.service in this file you have:
[Service]
EnvironmentFile=/etc/default/svxlink
.....

then this file is read and this environment variable is set

Then the law in [Rx1]
SQL_DET=VOX

VOX_FILTER_DEPTH=20
VOX_THRESH=800

and settings
SQL_HANGTIME=350

see if this helps

[sp2ong]

Maybe when using UDP audio the SQL_DET=NONE option would be useful, we do not need to have such a mechanism - if the audio comes, it is processed. A useful option here is probably SQL_HANGTIME

[sp2ong]

Ok spent more time try to use SQL_DET=SIGLEV it works most time for me you can try

I use ASYNC_AUDIO_UDP_ZEROFILL=1 in mys /etc/default/svxlink

AUDIO_DEV=udp:127.0.0.1:4910
AUDIO_DEV_KEEP_OPEN=0
SQL_DET=SIGLEV
SQL_SIGLEV_RX_NAME=Rx1
SIGLEV_DET=NOISE
SQL_SIGLEV_OPEN_THRESH=15
SQL_SIGLEV_CLOSE_THRESH=5
SIGLEV_SLOPE=24
SIGLEV_OFFSET=0
SQl_START_DELAY=0
SQl_START=0
SQL_HANGTIME=50

My mean UDP amplitude was about 5 measured by the siglevdetcal tool so SIGLEV_SLOPE is 24 and SIGLEV_OFFSET 0

and result

SimplexLogic: Event handler script successfully loaded.
Rx1: The squelch is OPEN (152)
Rx1: The squelch is CLOSED (0)
Rx1: The squelch is OPEN (64)
Rx1: The squelch is CLOSED (0)
Rx1: The squelch is OPEN (127)
Rx1: The squelch is CLOSED (0)
Rx1: The squelch is OPEN (59)
Rx1: The squelch is CLOSED (0)
Rx1: The squelch is OPEN (150)
Rx1: The squelch is CLOSED (0)

You can try it, maybe will be work with your svxlink

[sp2ong]

More tests indicate that the SQL_DET method based on SIGLEV and probably on VOX does not work if the UDP audio stream sent does not have the ASYNC_AUDIO_UDP_ZEROFILL=1 option, i.e. enable the UDP audio code to write zeros to the UDP connection when there is no audio to write available.
But I did this test by connecting 2 svxlinks cross-connected via UDP, so if UDP audio from MDVMHost does not have something like that implemented in svxlink via ASYNC_AUDIO_UDP_ZEROFILL=1, then no SQl_DET method will work on svxlink for UDP audio.
Unfortunately, I'm not a programmer and I don't know the intricacies of the svxlink code, so my observations are only based on these experiences and I can't check it myself. The opinion and advice of the author of svxlink would be very valuable here.....

73

[dl1hrc]

Hi,look for the AudioStreamStateDetector sections in my UsrpLogic branch.I'm away for some days and have less time at the moment.Mni 73s Adi/DL1HRCAm 21.10.2023 17:50 schrieb Waldek ***@***.***>: More tests indicate that the SQL_DET method based on SIGLEV and probably on VOX does not work if the UDP audio stream sent does not have the ASYNC_AUDIO_UDP_ZEROFILL=1 option, i.e. enable the UDP audio code to write zeros to the UDP connection when there is no audio to write available. But I did this test by connecting 2 svxlinks cross-connected via UDP, so if UDP audio from MDVMHost does not have something like that implemented in svxlink via ASYNC_AUDIO_UDP_ZEROFILL=1, then no SQl_DET method will work on svxlink for UDP audio. Unfortunately, I'm not a programmer and I don't know the intricacies of the svxlink code, so my observations are only based on these experiences and I can't check it myself. The opinion and advice of the author of svxlink would be very valuable here..... 73 —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sp2ong]

Adi, thank you for your answer, yes, in your USRP implementation, UDP reception and transmission works very nicely without the need to use the SQL_DET mechanism, so the solution used in the svxlink USRP branch would be a solution to the problem of audio exchange via UDP between svxlink and MDVMHost

[EU4BNC]

Good afternoon. I tried all the suggested options. Unfortunately nothing helped. Developer help needed.