Date   

Re: Replicated DMR Voice Packets

Pierre Martel
 

I think it is a good idea to have a problem when there is packet duplication, cause the only reason I can think of for the cause of packet duplication is a loop into the network. Now if there is a loop, and the packets keep on being replicated and no one notices, and other loops come and now we would have 3,4,5 time the packet replicated the end result would be network congestion. Bandwidth is not of infinite supply. And looping does degrade network performance. So the best thing is to make sure there is no looping and the 'bug' won't happen. It is not because you can link multiple systems together that it is a good thing to actually link them.





Le ven. 11 déc. 2020 à 08:42, <g8ptn@...> a écrit :

For general information, on a recent switch to a new DMR server, an observation was made that DVSwitch does not seem to cope with replicated voice packets.

The effect of the replicated packets is that the outgoing audio stream to DVSM sounds slow.


Whilst it is not desirable to have this situation in the network, my understanding is that the G4KLX software does deal with this by looking at a sequence number in the packets and drops replicated packets and replaces them with silence.


The cause of the replication has been fixed on the network in question, but it highlighted that it is also desirable to drop the replicated packets at the client side if possible.


I am not sure if the feature to drop can only be provided for the homebrew DMR protocol.


Dave (G8PTN)


Replicated DMR Voice Packets

g8ptn@...
 

For general information, on a recent switch to a new DMR server, an observation was made that DVSwitch does not seem to cope with replicated voice packets.

The effect of the replicated packets is that the outgoing audio stream to DVSM sounds slow.


Whilst it is not desirable to have this situation in the network, my understanding is that the G4KLX software does deal with this by looking at a sequence number in the packets and drops replicated packets and replaces them with silence.


The cause of the replication has been fixed on the network in question, but it highlighted that it is also desirable to drop the replicated packets at the client side if possible.


I am not sure if the feature to drop can only be provided for the homebrew DMR protocol.


Dave (G8PTN)


Re: DVSwitch Dashboard - DMR Master Information

g8ptn@...
 

Hi Waldek,

Next time I see the missing information I will check the log files with the grep command you have provided and add the workaround.

Thank you very much for the prompt and detailed response.


Dave


Re: DVSwitch Dashboard - DMR Master Information

SP2ONG Waldek
 

My dvswitch server is working 24H and I use a simple method to recovery info about status connected servers / links

I put in /etc/cron.d/ file with contain:

MAILTO=""
#
0 2 * * * root systemctl restart mmdvm_bridge
0 2 * * * root systemctl restart ysfgateway
0 2 * * * root systemctl restart nxdngateway
0 2 * * * root systemctl restart p25gateway
#

after creating the file you must restart crontab

/etc/init.d/cron restart

which restart services during the night for example 2:00
In MMDV_Bridge.ini in [DMR Network] I put my base DMR server (IP address, port , password) and
in NXDNGateway.ini and P25gateway.ini YSFgateway.ini  I have defined in Startup=  
reflectors which I want always connected after a restart of services


Re: DVSwitch Dashboard - DMR Master Information

SP2ONG Waldek
 

Dave,

The dashboard is searching in MMDVM_Bridge log file with current data

grep -a 'DMR, Logged\|DMR, Closing DMR\|DMR, Opening DMR\|DMR, Connection' /var/log/mmdvm/MMDVM_Bridge-2020-12-11.log

and if the result is empty the dashboard looking to MMDVM_Bridge log file with yesterday

grep -a 'DMR, Logged\|DMR, Closing DMR\|DMR, Opening DMR\|DMR, Connection' /var/log/mmdvm/MMDVM_Bridge-2020-12-10.log

As so result this command is used to create the status of DMR Server.

If your system works 24H and you have connected to DMR Serve for more than 2 days without changing DMR server at current the dashboard can not has the possibility get info about the connected DMR server

if see that info about the status DMR Server is empty try to check log file with the above command where file name MMDVM_Bridge log file must be with yesterday

Waldek



Re: DVSwitch Dashboard - DMR Master Information

g8ptn@...
 

Hi Steve,

Unfortunately, when I opened the browser today 11th Dec, the “DMR Master” information had disappeared again. I wonder if it is happening on a 24-hour basis.


Changing the Default DMR Server in the “dvs” control panel restores the information as before.


Dave 


Re: DVSwitch Dashboard - DMR Master Information

Steve N4IRS
 

Did you edit /etc/lighttpd/lighttpd.conf?
show me the result of: systemctl status webproxy
show me the result of: ls /lib/systemd/system/web*

Steve N4IRS


On 12/10/2020 3:53 PM, Chris K6CV wrote:
Hi Steve, I'm a newbie here, and seem to have a issue with lighttpd, below is what I see, and of course no dashboard web page found.
Not sure what all this means, but it looks like my webproxy service is in a damaged and not running state.
:
root@raspberrypi:/var# ps ax | grep lighttpd
17717 pts/0    S+     0:00 grep lighttpd
root@raspberrypi:/var#

root@raspberrypi:/var/log/mmdvm# systemctl restart webproxy
Failed to restart webproxy.service: Unit webproxy.service not found.
root@raspberrypi:/var/log/mmdvm# ps ax | grep lighttpd
11431 pts/0    S+     0:00 grep lighttpd

root@raspberrypi:/var/log/mmdvm# systemctl status lighttpd
● lighttpd.service - Lighttpd Daemon
   Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2020-12-10 11:06:31 PST; 1h 8min ago
  Process: 773 ExecStartPre=/usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
  Process: 778 ExecStart=/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf (code=exited, status=255/EXCEPTION)
 Main PID: 778 (code=exited, status=255/EXCEPTION)
 
Dec 10 11:06:31 raspberrypi systemd[1]: lighttpd.service: Service RestartSec=100ms expired, scheduling restart.
Dec 10 11:06:31 raspberrypi systemd[1]: lighttpd.service: Scheduled restart job, restart counter is at 5.
Dec 10 11:06:31 raspberrypi systemd[1]: Stopped Lighttpd Daemon.
Dec 10 11:06:31 raspberrypi systemd[1]: lighttpd.service: Start request repeated too quickly.
Dec 10 11:06:31 raspberrypi systemd[1]: lighttpd.service: Failed with result 'exit-code'.
Dec 10 11:06:31 raspberrypi systemd[1]: Failed to start Lighttpd Daemon.
root@raspberrypi:/var/log/mmdvm#

73's
DE K6CV Chris.


Re: DVSwitch Dashboard - DMR Master Information

Chris K6CV
 

Hi Steve, I'm a newbie here, and seem to have a issue with lighttpd, below is what I see, and of course no dashboard web page found.
Not sure what all this means, but it looks like my webproxy service is in a damaged and not running state.
:
root@raspberrypi:/var# ps ax | grep lighttpd
17717 pts/0    S+     0:00 grep lighttpd
root@raspberrypi:/var#

root@raspberrypi:/var/log/mmdvm# systemctl restart webproxy
Failed to restart webproxy.service: Unit webproxy.service not found.
root@raspberrypi:/var/log/mmdvm# ps ax | grep lighttpd
11431 pts/0    S+     0:00 grep lighttpd

root@raspberrypi:/var/log/mmdvm# systemctl status lighttpd
● lighttpd.service - Lighttpd Daemon
   Loaded: loaded (/lib/systemd/system/lighttpd.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Thu 2020-12-10 11:06:31 PST; 1h 8min ago
  Process: 773 ExecStartPre=/usr/sbin/lighttpd -tt -f /etc/lighttpd/lighttpd.conf (code=exited, status=0/SUCCESS)
  Process: 778 ExecStart=/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf (code=exited, status=255/EXCEPTION)
 Main PID: 778 (code=exited, status=255/EXCEPTION)
 
Dec 10 11:06:31 raspberrypi systemd[1]: lighttpd.service: Service RestartSec=100ms expired, scheduling restart.
Dec 10 11:06:31 raspberrypi systemd[1]: lighttpd.service: Scheduled restart job, restart counter is at 5.
Dec 10 11:06:31 raspberrypi systemd[1]: Stopped Lighttpd Daemon.
Dec 10 11:06:31 raspberrypi systemd[1]: lighttpd.service: Start request repeated too quickly.
Dec 10 11:06:31 raspberrypi systemd[1]: lighttpd.service: Failed with result 'exit-code'.
Dec 10 11:06:31 raspberrypi systemd[1]: Failed to start Lighttpd Daemon.
root@raspberrypi:/var/log/mmdvm#

73's
DE K6CV Chris.


Re: DVSwitch Dashboard - DMR Master Information

g8ptn@...
 

Hi Steve,

I have done the update/upgrade and it seems fine now.

Many thanks.

Dave


Re: Using DVSwitch to access DMR+/Phoenix

G4WXN@...
 

Thanks, I'll give it a whirl.

--
Derek

G4WXN


Re: MMDVM to MMDVM connections ?

Gerry Filby
 

Figures ... was curious if the underlying protocol could support peer to peer connections ...

Cheers !
Gerry.


Re: Using DVSwitch to access DMR+/Phoenix

Steve N4IRS
 

sudo /opt/Analog_Bridge/dvswitch.sh tune PASSWORD@...:55555:StartRef=4440;RelinkTime=180;UserLink=1!9

On 12/10/2020 11:16 AM, G4WXN@... wrote:
sudo /opt/Analog_Bridge/dvswitch.sh tune PASSWORD@...:55555:StartRef=4440;RelinkTime=180;UserLink=1
--
Derek

G4WXN


Re: Using DVSwitch to access DMR+/Phoenix

G4WXN@...
 

sudo /opt/Analog_Bridge/dvswitch.sh tune PASSWORD@...:55555:StartRef=4440;RelinkTime=180;UserLink=1
--
Derek

G4WXN


Re: connection Ycs server

luiz_sergio lemos
 

I listen to audio from other stations, but when I transmit nothing appears on the YCS panel.


Re: MMDVM to MMDVM connections ?

Daryl
 

I use my gateway ID as a TG on BM as a place to go so as not to tie up one of the chat TG's.
Works for me and a couple of my locals
Daryl
G0 ANV


Re: connection Ycs server

luiz_sergio lemos
 

191.252.101.21:42000


Re: connection Ycs server

Steve N4IRS
 

What YCS reflector? What is your tune string?

On 12/10/20 6:16 AM, luiz_sergio lemos wrote:
Hi,

Dvswitch ysf mode connects to the YCS server but does not transmit audio. 
Any tips?

PU1LOY Luiz Sérgio


connection Ycs server

luiz_sergio lemos
 

Hi,

Dvswitch ysf mode connects to the YCS server but does not transmit audio. 
Any tips?

PU1LOY Luiz Sérgio


Re: digital transmit overtime

Patrick Perdue
 

I’m adjusting it on the USRP node.
For now, I wrote a cheap shell script that is called only when the USRP node is keying towards ASL, which sleeps for a while, mutes both TLV and USRP. Then another script runs when the node stops transmitting which kills the running time or if it exists, then unmute A_B 10 seconds later. It isn’t perfect, but it does give people a chance to disconnect if things go on for a long time.

Sent from my zippo

On Dec 9, 2020, at 18:57, Steve N4IRS <szingman@msgstor.com> wrote:

Patrick,
Which TOT are you adjusting? Are you adjusting the TOT on the USRP node or the ASL TX? The TOT controls the TX not the RX. Just a thought.

Steve

On 12/9/20 5:55 AM, Patrick Perdue wrote:
Hi Steve:

Thanks. Yeah, I thought it should work the same as any other channel driver, so I changed it to a ridiculously low number (10000), and transmissions over 10 seconds across the bridge still passed after rpt reload, at least from digital to analog. I didn't test in the other direction.











Re: DVSwitch Dashboard Web Port

Joe, WB3IHY
 

Steve,
Webproxy WASN'T running.  That was the netstat output from the WORKING nodes.  Netstat had shown nothing for port 8080 on the non-working one.  That should have been my first clue.  Bu the lack of a generated log file clinched it.

Incidentally, I did look (and had tried) your suggested way of upgrading nodejs.  For some reason, that method completely hosed the existing install on that server.  As a result, I ended up having to remove and completely purge it.

Doing so also removed the DVSwitch installation (but, thankfully, left all the config files intact).  After reinstalling DVSwitch, I ended up back at version 4 of node...which I was then able to successfully update the way I described.

I'm betting that it had something to do with the fact that the server is Ubuntu based (Mint) rather than "pure" Debian (Stretch).  But hey, no big deal.  Just happy it now works.

Thanks again for pointing me in the right direction(s).

73,
Joe

1381 - 1400 of 9087