FM Network with RAW audio through UDP. #782
Comments
|
It would be nice to have this option because SVXLink allows cooperation via UDP by specifying: With raw UDP audio, we can pass DTMF tones to svxlink so we can switch groups on svxreflector and control svxlink via DTMF via MMDVM FM Mode which is not allowed by the USRP protocol in svxlink |
|
Yes, that's right, RAW could add more features. Additionally, it will be possible to use various voice notifications from SVXLINK. |
|
Yes you are right. Thanks to this, there will be full integration of the MMDVM FM mode with the capabilities of svxlink |
|
Really, this would be a wonderful addition. I also use a repeater based on MMDVMHOST, operating in DMR and FM mode. SVXLINK via USRP has very limited functionality. A huge request to the developer to add the ability to broadcast audio in RAW format via UDP to work with SVXLINK. |
|
I also fully support fellow radio amateurs! I also use Svxlink via USRP protocol and have no way to run parrot and use group switching. I really ask you to modify mmdvmhost to allow dtmf to work and support raw format for using SvxLink without additional settings via USRP. |
|
Note that DTMF tones are not filtered by the MMDVM so should be passed correctly, only the CTCSS and high audio frequencies are removed. The USRP UDP option was originally designed to interact with external software that provided access to EchoLink and not as a general function, it was always expected that the inbuilt FM repeater would be used most of the time. However it appears that you want to do more. In the MMDVM.ini you will see that LinkMode is documented (did you read the file at all?) and it allows almost complete access to the FM audio in and out via USRP with almost no logic operation. I think the CTCSS detector is still operational as that will allow the repeater to remain multimode correctly. |
|
Jonathan, thank you very much for your answer. Yes, I know that USRP from MMDVMHost does not filter DTMF and passes these tones via USRP, but we have a problem that USRP in svxlink is a simple implementation in a separate branch, not the main code, and USRP svxlink did not allow DTMF decoding and sending radio messages. USRP in the svxlink branch was added mainly as a network connection option to DV via USRP. |
|
Adding a raw mode would not be an issue, my only issue is that you ask for two channels, I don't understand this. There is only one audio source and I would expect one channel in and one channel out of the host. Other than that, I think I can add an implementation later today for you to test. |
|
Hi, I am not sure what SM0SVX autor svxlink is used in this definition. I found this info on svxlink.conf The "udp" type is not really an audio device but instead will read and write |
|
Can I also do a change test on my dmr/fm repeater? |
|
I've added a RAW data type for the FM Network and it uses two channels of 16-bit signed integers only one of which is used, when sending data out, both channels have the same audio data in them. I hope that helps. |
|
Wow, many thanks, I see we need in MMDVM.ini in [FM Network] define Protocol=RAW it will send sound in RAW UDP and in svxlink.conf we need to define in Rx1 an Tx1 AUDIO_DEV=udp:127.0.0.1:port_number |
|
Something went wrong. |
|
From MMDVM |
This package is from MMDVM19:18:40.398721 IP (tos 0x0, ttl 64, id 8543, offset 0, flags [DF], proto UDP (17), length 668) And this package is from SVXLink19:21:45.562505 IP (tos 0x0, ttl 64, id 56661, offset 0, flags [DF], proto UDP (17), length 2076) |
|
Hi EU4BNC Can you show [FM Network] section from MMDVM.ini and definition AUDIO_DEV from [Tx1] and [Rx1] from svxlink.conf? |
|
[FM Network] [Rx1] [Tx1] |
|
Hm interesting it maybe js OK I am not expert but I wonder why MMDVM use 3811 port to send data on port 4811 where 3811 is used by svxlink as TX UDP in svxlink.conf. |
|
4811 Is RX For SVX (For receiving from MMDVM and translating to Internet) Using the tcpdump utility, I see that the packets from SVXLink are very different from the packets from MMDVMHost. Even in size. |
|
If I am remember when long time ago I play with python gateway from AnalogBridge to SVXLink the USRP protocol use audio with 8 khz but SVXLink via UDP accept audio with sample rate which defined in svxlink.conf CARD_SAMPLE_RATE where is 48 000 hz in most cases so for this reason maybe is different size of packet send data from svxlink and from MMVDMHost. So for this reason is incompatible sample rate audio where MMDVMHost should be send RAW with 48 kHz sample reate |
|
If am remember other my experience with svxlink via UDP. In svxlink.conf we use CARDS CHANNELS =1 so the UDP stream has 2016 bytes, so it looks that it is mono audio with one channel. |
|
I'm no expert either) |
|
Yes, so if use CARD_SAMPLE_RATE in [GLOBAL] settings like 48000 so svxlink will be used for receiving and transmitting in RAW Audio with sample rate 48000 Hz. In most cases sound cards which we use in svxlink use, 48000 Hz sample rate. So if MMDVMHost use sample rate which is used in USRP 8000 Hz we have incompatible sample rate audio data. So we need to add resample audio data via RAW UDP to 48000 hz |
|
Looking for info from your tcpdump information about length From MMDVM it is confirmed that RAW UDP from MMDVM is sample rate 8000 Hz and from SVXlink is 48000 hz |
|
Is it possible to increase the siple rate in mmdvmhost to 16000 or 48000, since the quality of speech is very low? |
|
Now I add CARD_CHANNELS=1 parameter. And.... 20:41:36.843420 IP (tos 0x0, ttl 64, id 62422, offset 0, flags [DF], proto UDP (17), ### length 1052) |
|
We need to use in MMDVMHost in RAW UDP mode, 48000 Hz sample rate. CARD_CHANNELS=1 in svxlink only reduce to mono audio with 48000 sample rate |
|
We need "resampler" in MMDVMHost) |
|
The quality of the speech at 8000 Hz sample rate is the same as at 48000 Hz sample rate as the audio is limited to 3 kHz which is below the Nyquist limit. I will have to add a resampler to get up to 48000 Hz sample rate, should I also change from stereo to mono audio only? |
|
I assume that mono is sufficient because in most cases we use CARD_CHANNEL=1 so it is in mono mode |
|
I have use udp audio in svxlink with my dashbaord svxlink to listen stream from svxlink and working very well. |
|
SVXLink with UDP RX and TX works good with GnuRadio: |
|
The message comes about because an incoming packet, from SVXLink, has arrived from an IP address and/or port that isn’t listed in the ini file as being where the gateway is. This is a security feature.
Can you check to see what the correct address and port for SVXLink is, and is it the same for transmit and receive UDP packets?
Sent from Yahoo Mail for iPhone
On Wednesday, October 18, 2023, 18:56, Waldek ***@***.***> wrote:
Hi, I have the same "problem" ? I don't know what this information in the log means.
I: 2023-10-18 17:47:40.360 MMDVMHost-20231017 is starting
I: 2023-10-18 17:47:40.360 Built 17:19:49 Oct 18 2023 (GitID #e91f640)
I: 2023-10-18 17:47:40.360 General Parameters
I: 2023-10-18 17:47:40.360 Callsign: SP2ONG
I: 2023-10-18 17:47:40.360 Id: 123456
I: 2023-10-18 17:47:40.361 Duplex: yes
I: 2023-10-18 17:47:40.361 Timeout: 180s
I: 2023-10-18 17:47:40.361 D-Star: disabled
I: 2023-10-18 17:47:40.361 DMR: disabled
I: 2023-10-18 17:47:40.361 YSF: disabled
I: 2023-10-18 17:47:40.361 P25: disabled
I: 2023-10-18 17:47:40.361 NXDN: disabled
I: 2023-10-18 17:47:40.361 M17: disabled
I: 2023-10-18 17:47:40.361 POCSAG: disabled
I: 2023-10-18 17:47:40.361 FM: enabled
I: 2023-10-18 17:47:40.361 AX.25: disabled
I: 2023-10-18 17:47:40.361 Modem Parameters
I: 2023-10-18 17:47:40.361 Protocol: uart
I: 2023-10-18 17:47:40.361 UART Port: /dev/ttyACM0
I: 2023-10-18 17:47:40.361 UART Speed: 460800
I: 2023-10-18 17:47:40.361 RX Invert: no
I: 2023-10-18 17:47:40.361 TX Invert: yes
I: 2023-10-18 17:47:40.361 PTT Invert: no
I: 2023-10-18 17:47:40.361 TX Delay: 100ms
I: 2023-10-18 17:47:40.361 RX Offset: 0Hz
I: 2023-10-18 17:47:40.361 TX Offset: 0Hz
I: 2023-10-18 17:47:40.361 RX DC Offset: 0
I: 2023-10-18 17:47:40.361 TX DC Offset: 0
I: 2023-10-18 17:47:40.361 RF Level: 100.0%
I: 2023-10-18 17:47:40.361 DMR Delay: 0 (0.0ms)
I: 2023-10-18 17:47:40.361 RX Level: 50.0%
I: 2023-10-18 17:47:40.361 CW Id TX Level: 50.0%
I: 2023-10-18 17:47:40.361 D-Star TX Level: 50.0%
I: 2023-10-18 17:47:40.361 DMR TX Level: 50.0%
I: 2023-10-18 17:47:40.361 YSF TX Level: 50.0%
I: 2023-10-18 17:47:40.361 P25 TX Level: 50.0%
I: 2023-10-18 17:47:40.361 NXDN TX Level: 50.0%
I: 2023-10-18 17:47:40.361 M17 TX Level: 50.0%
I: 2023-10-18 17:47:40.361 POCSAG TX Level: 50.0%
I: 2023-10-18 17:47:40.361 FM TX Level: 50.0%
I: 2023-10-18 17:47:40.361 AX.25 TX Level: 50.0%
I: 2023-10-18 17:47:40.361 TX Frequency: 435000000Hz (435000000Hz)
I: 2023-10-18 17:47:40.361 Use COS as Lockout: no
I: 2023-10-18 17:47:40.361 FM Parameters
I: 2023-10-18 17:47:40.361 Callsign: SP2ONG
I: 2023-10-18 17:47:40.362 Callsign Speed: 20WPM
I: 2023-10-18 17:47:40.362 Callsign Frequency: 1000Hz
I: 2023-10-18 17:47:40.362 Callsign Time: 10mins
I: 2023-10-18 17:47:40.362 Callsign Holdoff: 1/0
I: 2023-10-18 17:47:40.362 Callsign High Level: 50.0%
I: 2023-10-18 17:47:40.362 Callsign Low Level: 20.0%
I: 2023-10-18 17:47:40.362 Callsign At Start: no
I: 2023-10-18 17:47:40.362 Callsign At End: no
I: 2023-10-18 17:47:40.362 Callsign At Latch: no
I: 2023-10-18 17:47:40.362 RF Ack: K
I: 2023-10-18 17:47:40.362 Ack Speed: 20WPM
I: 2023-10-18 17:47:40.362 Ack Frequency: 1750Hz
I: 2023-10-18 17:47:40.362 Ack Min Time: 4s
I: 2023-10-18 17:47:40.362 Ack Delay: 1000ms
I: 2023-10-18 17:47:40.362 Ack Level: 50.0%
I: 2023-10-18 17:47:40.362 Timeout: 180s
I: 2023-10-18 17:47:40.362 Timeout Level: 80.0%
I: 2023-10-18 17:47:40.362 CTCSS Frequency: 88.5Hz
I: 2023-10-18 17:47:40.362 CTCSS High Threshold: 30
I: 2023-10-18 17:47:40.362 CTCSS Low Threshold: 30
I: 2023-10-18 17:47:40.362 CTCSS Level: 20.0%
I: 2023-10-18 17:47:40.362 Kerchunk Time: 30s
I: 2023-10-18 17:47:40.362 Hang Time: 30s
I: 2023-10-18 17:47:40.362 Access Mode: 1
I: 2023-10-18 17:47:40.362 Link Mode: no
I: 2023-10-18 17:47:40.362 COS Invert: no
I: 2023-10-18 17:47:40.362 Noise Squelch: no
I: 2023-10-18 17:47:40.362 RF Audio Boost: x1
I: 2023-10-18 17:47:40.362 Max. Deviation Level: 90.0%
I: 2023-10-18 17:47:40.362 Mode Hang: 10s
I: 2023-10-18 17:47:40.362 Ext. Ack: N
I: 2023-10-18 17:47:40.362 Ext. Audio Boost: x1
M: 2023-10-18 17:47:40.362 Opening the MMDVM
I: 2023-10-18 17:47:42.377 MMDVM protocol version: 2, description: MMDVM 20221121 12.0000 MHz GitID #508018c
I: 2023-10-18 17:47:42.377 CPU: ST-Micro ARM, UDID: 4B0025000351383032333330
I: 2023-10-18 17:47:42.377 Modes: DMR FM
I: 2023-10-18 17:47:42.438 Display Parameters
I: 2023-10-18 17:47:42.438 Type: None
W: 2023-10-18 17:47:42.438 No valid display found, disabling
I: 2023-10-18 17:47:42.438 Opening network connections
I: 2023-10-18 17:47:42.438 FM Network Parameters
I: 2023-10-18 17:47:42.438 Protocol: RAW
I: 2023-10-18 17:47:42.438 Sample Rate: 48000
I: 2023-10-18 17:47:42.438 Gateway Address: 127.0.0.1
I: 2023-10-18 17:47:42.438 Gateway Port: 4810
I: 2023-10-18 17:47:42.438 Local Address: 127.0.0.1
I: 2023-10-18 17:47:42.438 Local Port: 3810
I: 2023-10-18 17:47:42.438 Pre-Emphasis: yes
I: 2023-10-18 17:47:42.439 De-Emphasis: yes
I: 2023-10-18 17:47:42.439 TX Audio Gain: 1.00
I: 2023-10-18 17:47:42.439 RX Audio Gain: 0.20
I: 2023-10-18 17:47:42.439 Mode Hang: 3s
M: 2023-10-18 17:47:42.439 Opening FM network connection
I: 2023-10-18 17:47:42.439 Opening UDP port on 3810
I: 2023-10-18 17:47:42.439 RSSI
I: 2023-10-18 17:47:42.439 Mapping File: RSSI.dat
I: 2023-10-18 17:47:42.439 Loaded 0 RSSI data mapping points from RSSI.dat
I: 2023-10-18 17:47:42.439 Starting protocol handlers
I: 2023-10-18 17:47:42.439 MMDVMHost-20231017 is running
M: 2023-10-18 17:51:22.244 FM packet received from an invalid source
M: 2023-10-18 17:51:22.265 FM packet received from an invalid source
......
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
When analyzing the traffic, it is clear that data for MMDVMHost leaves from a different port (the port is different from the one specified in Gateway). Here is an example package from MMDVMHost in SVXLink. Port 3811(mmdvmhost) sends data to port 4811(SVX). Here is an example package from SVXLink at MMDVMHost. Port !!!39605(SVX) sends data to port 3811(MMDVMHost)20:41:36.843420 IP (tos 0x0, ttl 64, id 62422, offset 0, flags [DF], proto UDP (17), ### length 1052) SVXLink port is 4811, but outgoing data comes from port 39605. Outgoing port may be different for each transmission. |
|
Is it possible to make a function to disable protection? |
|
I have modified the host to allow more flexibility in RAW mode, but I won’t completely open it up as security is extremely important.
Give the latest GitHub version a go and see how it goes please.
Sent from Yahoo Mail for iPhone
On Wednesday, October 18, 2023, 19:56, EU4BNC ***@***.***> wrote:
Is it possible to make a function to disable protection?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Thank you very much, I'll try it now. |
|
Great! First success! The data went from SVXLink to MMDVMHost correctly, all that remains is to figure out why SVXLink does not respond to data from MMDVMHost. |
|
Maybe the level of audio from MmdvmHost is too low to open Vox in svxlink try gain audio in MMDVMHost
|
|
I would like to express my deep gratitude for the work done, the addition of the RAW protocol and Resampler. |
|
We can ask you to add one more modification. SVXLink incorrectly handles SQUELCH DETECTION when traffic on the incoming port is lost. This causes SQUELCH to open when traffic appears and not close when traffic disappears. SVXLink has the ability to control SQUELCH via PTY. If "O" is received on the PTY device (e.g. PTY_PATH=/tmp/sql), SQUELCH will be opened, if "Z" is sent to the device (e.g. PTY_PATH=/tmp/sql), SQUELCH will be closed. Is it possible to add external SQUELCH control via PTY to MMDVMHost? After the traffic starts broadcasting to the Gateway port, we will send O to PTY. Before the end of broadcasting packets to PTY, we will send Z. GATEWAY_SQL_PTY=/tmp/sql |
|
This is an extract from the SVXLINK instructions: |
|
I think this could be move to a SVXNetwork. |
|
We discussed this problem sm0svx/svxlink#644 But how to do/implement this in a UDP stream in MDVMHost, I don't know. We want to inerconnect MMDVMHost in FM MODE with svxlink via RAW UDP because at the current branch svxlink USRP not support decoding DTMF via USRP and does not send any audio message from modules etc. RAW UDP Audio will allow full integration MMDVMHost with the possibility svxlink. |
|
It appears that the audio from MDVMHost is being sent as much as it has and SVXLink is expecting a full buffer? and if the incoming sound does not fill the full buffer, it waits and therefore is not able to consider that "SQL" is closed. But I am just guessing that this is what happens |
|
That sounds extremely stupid of SVXLink. If you can find the buffer length that they're expecting, please let me know.
On Tuesday, 24 October 2023 at 13:04:55 BST, Waldek ***@***.***> wrote:
It appears that the audio from MDVMHost is being sent as much as it has and SVXLink is expecting a full buffer? and if the incoming sound does not fill the full buffer, it waits and therefore is not able to consider that "SQL" is closed. But I am just guessing that this is what happens
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
I don't know, but I assume that based on the behavior of receiving UDP RAW audio when the TX option ASYNC_AUDIO_UDP_ZEROFILL=1 is used and then it works. Opening and closing SQL and when I do not use the ASYNC_AUDIO_UDP_ZEROFILL option, i.e. I set it to 0, then when AUDIO comes there is information about opening SQL and after the UDP transmission is completed, there is no information about closing the SQL, which blocks further operation. Probably the author of svxlink would answer these doubts... |
|
I've added the squelch file handling. Can you give it a try and report back please? |
I'll try it ib evening and report here. Thanks to you! |
I'm sorry, could you please explain how this setting works and what should be in the sql file. |
|
You must add in MMDVM.ini SquelchFile [FM Network] and in svxlink.conf in [Rx1] SQL_DET=PTY Note that MDVMHost and svxlink should be run by the same user due to the /tmp/sql PTY device permissions Tell us whether the new solutions added by Jonathan work for you now. Thanks, Jonathan, for your support |
|
Thanks a lot! It works! |
|
Wow! Let me know if you need any more changes for it. Maybe you can make an announcement on the OpenDV group and maybe a small guide on how to configure it, and what you can use it for. Would that be possible? |
Yes, I will prepare a text to present this project a little later. Once again, thank you very much for your support and improvements. Currently, our repeater network has MMDVM equipment installed with MOTOROLLA GM and CM series radios. DMR switching is carried out via Brandmeister and XLX. Analog traffic is switched through the SVXLink server with the ability to control groups via DTMF. This is such an interesting symbiosis. |
|
Hi, thank you once again for the work done. A good alternative would be to be able to link svxreflector with the OPUS codec. Thanks again, this is a project I've been waiting for for a long time. |
I think that such a solution is not realistic because you would have to implement the entire mechanism for handling communication with svxreflector, which is in svxlink, and you would have to constantly monitor changes in the svxlnik code to have a current implementation of such a solution, and this is not the goal of MDVMHost. MDVMHost can send the analog audio stream to software such as svxlink and it takes care of the rest of the implementation of communication with svxrelfector, group management, etc. |
|
hello everyone! I have svxlibk in analog mode, after refining mmdvmhost, I want to note that I really like the sound quality coming through udp, I have the same board myself and I think that the work done is just fine, we got dtmf and alerts plus the quality standards, which are controlled through mmdvmhost and svxlibk, so those who don't like the changes I suggest not to use them. |
Hello. Now I use mmdvm in fm mode in conjunction with SVXlink through USRP. But perhaps it is possible to use RAW data via UDP? Is it possible to do this?
The text was updated successfully, but these errors were encountered: