SQL_DET for UDP Audio device about svxlink HOT 22 OPEN

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.

from svxlink.

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]

from svxlink.

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.

from svxlink.

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

from svxlink.

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

from svxlink.

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.

from svxlink.

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"

from svxlink.

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.

from svxlink.

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

from svxlink.

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.

from svxlink.

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.

from svxlink.

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=#

from svxlink.

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.

from svxlink.

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.

from svxlink.

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

from svxlink.

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

from svxlink.

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

from svxlink.

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

from svxlink.

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

from svxlink.

from svxlink.

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

from svxlink.

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

from svxlink.