main@DVSwitch.groups.io | Followup on Network Watchdog timeout message FCS to DMR bridge

Home Messages Hashtags Subgroups Wiki

Topics

Date Date 1 - 14 of 14

Followup on Network Watchdog timeout message FCS to DMR bridge

David Young #7935 I posted an issue several months ago concerning getting the error message 'Network Watchdog Timeout' after any FCS transmission using an MMDVM_Bridge between FCS and DMR. Specifically this caused another bridge which I am running 'NXDN to DMR', same DMR TG, to stop working. What happens is that the NXDN MMDVM_Bridge log file sees the Network Watchdog Timeout error message and does not see any subsequent Tx Stop message so NXDN thinks that the FCS bridge is still talking and stays in listen mode. So the Tx Stop message does not get passed to the NXDN Bridge after the Network Watchdog Timeout message. I had a suggestion that possibly to prevent the Network Watchdog Timeout error message from occurring that in G4KLX's MMDVM.ini configuration file there is a software switch in the "System Fusion" stanza labeled "RemoteGateway=". Setting this switch to a numeric 1 might prevent the Network Watchdog Timeout error and resulting error message in the FCS MMDVM_Bridge. Looking at the DVSwitch MMDVM_Bridge configuration 'ini' file, there is no software switch suggested in the "System Fusion" stanza. Is it possible to add this switch or would this be of any help to my problem with the NXDN bridge? -- Dave WB6DTB
More All Messages By This Member
Steve N4IRS #7942 Dave, We thought this was resolved. I am going to setup a test FCS <-> NXDN bridge. I will report my findings. I expect I'll do it first thing tomorrow morning. Steve toggle quoted messageShow quoted text On 12/11/20 7:45 PM, David Young wrote: I posted an issue several months ago concerning getting the error message 'Network Watchdog Timeout' after any FCS transmission using an MMDVM_Bridge between FCS and DMR. Specifically this caused another bridge which I am running 'NXDN to DMR', same DMR TG, to stop working. What happens is that the NXDN MMDVM_Bridge log file sees the Network Watchdog Timeout error message and does not see any subsequent Tx Stop message so NXDN thinks that the FCS bridge is still talking and stays in listen mode. So the Tx Stop message does not get passed to the NXDN Bridge after the Network Watchdog Timeout message. I had a suggestion that possibly to prevent the Network Watchdog Timeout error message from occurring that in G4KLX's MMDVM.ini configuration file there is a software switch in the "System Fusion" stanza labeled "RemoteGateway=". Setting this switch to a numeric 1 might prevent the Network Watchdog Timeout error and resulting error message in the FCS MMDVM_Bridge. Looking at the DVSwitch MMDVM_Bridge configuration 'ini' file, there is no software switch suggested in the "System Fusion" stanza. Is it possible to add this switch or would this be of any help to my problem with the NXDN bridge? -- Dave WB6DTB smime.p7s
More All Messages By This Member
Steve N4IRS #7943 Dave, One question. You reference "Network Watchdog Timeout" Are you seeing those words in the log? You should be seeing this: M: 2020-12-12 14:37:26.510 YSF, received network end of transmission (expired), 1.5 seconds, 0% packet loss, BER: 1.3% toggle quoted messageShow quoted text On 12/11/20 7:45 PM, David Young wrote: I posted an issue several months ago concerning getting the error message 'Network Watchdog Timeout' after any FCS transmission using an MMDVM_Bridge between FCS and DMR. Specifically this caused another bridge which I am running 'NXDN to DMR', same DMR TG, to stop working. What happens is that the NXDN MMDVM_Bridge log file sees the Network Watchdog Timeout error message and does not see any subsequent Tx Stop message so NXDN thinks that the FCS bridge is still talking and stays in listen mode. So the Tx Stop message does not get passed to the NXDN Bridge after the Network Watchdog Timeout message. I had a suggestion that possibly to prevent the Network Watchdog Timeout error message from occurring that in G4KLX's MMDVM.ini configuration file there is a software switch in the "System Fusion" stanza labeled "RemoteGateway=". Setting this switch to a numeric 1 might prevent the Network Watchdog Timeout error and resulting error message in the FCS MMDVM_Bridge. Looking at the DVSwitch MMDVM_Bridge configuration 'ini' file, there is no software switch suggested in the "System Fusion" stanza. Is it possible to add this switch or would this be of any help to my problem with the NXDN bridge? -- Dave WB6DTB smime.p7s
More All Messages By This Member
k7wby@... #7946 I thought network watchdog errors were XLX/AMBED related?
More All Messages By This Member
David Young #7947 Steve, Tx on FCS00379 The log message is on the NXDN MMDVM_Bridge: "M: 2020-12-12 14:37:26.510 DMR Slot 2, received network voice header from WB6DTB to TG 30639" "M: 2020-12-12 14:37:26.510 DMR Slot 2, network watchdog has expired, 2.4 seconds, 12% packet loss, BER: 0.0%" So we are sending both NXDN and various FCS rooms to HBlink3 master using DVSwitch MMDVM_Bridge modules. FCS uses YSFGateway and I guess because we are then going from FCS through YSFGateway through MMDVM_Bridge to HBlink3 that is why the log shows DMR instead of YSF for the two log entries as above. This is all running on cloud servers. -- Dave WB6DTB
More All Messages By This Member
k7wby@... #7948 On Sun, Dec 13, 2020 at 09:09 AM, David Young wrote: network watchdog has expired, 2.4 seconds, 12% packet loss, BER: 0.0% That is an AMBE error. It's important to remember that when you bridge from YSF to DMR the transition is done by stripping the unique data from YSF leaving only what is common to both modes and then reapplying (when possible) the data to destination mode. The process of vocoding is important and both modes should use the same process. If one is using the md380 and the other OP25 you may experience these errors.
More All Messages By This Member
Steve N4IRS #7953 Dave, Please show me the result of: /opt/MMDVM_Bridge -v Also please show the log with some sample FCS transmissions. toggle quoted messageShow quoted text On 12/13/20 12:09 PM, David Young wrote: Steve, Tx on FCS00379 The log message is on the NXDN MMDVM_Bridge: "M: 2020-12-12 14:37:26.510 DMR Slot 2, received network voice header from WB6DTB to TG 30639" "M: 2020-12-12 14:37:26.510 DMR Slot 2, network watchdog has expired, 2.4 seconds, 12% packet loss, BER: 0.0%" So we are sending both NXDN and various FCS rooms to HBlink3 master using DVSwitch MMDVM_Bridge modules. FCS uses YSFGateway and I guess because we are then going from FCS through YSFGateway through MMDVM_Bridge to HBlink3 that is why the log shows DMR instead of YSF for the two log entries as above. This is all running on cloud servers. -- Dave WB6DTB smime.p7s
More All Messages By This Member
David Young #7967 Steve, Not sure about the command you are asking me to execute /opt/MMDVM_Bridge -v This results in command not found. I think you are asking for the version of MMDVM_Bridge which is 1.6.1 for the NXDN bridge. Attached are 2 log files, one from the NXDN bridge log and the second from the FCS bridge log. These were copied from the MMDVM_Bridge log showing my transmissions from FCS00479 and resulting log entries seen from the NXDN MMDVM_Bridge. As seen on the NXDN bridge log after each FCS transmission is received on NXDN at the end of those transmissions the log shows the Network Timeout error and no TX OFF log entry, causing NXDN to stay in receive mode. The last transmission shown in the NXDN bridge log is from me transmitting from TGIF DMR showing a valid NXDN TX OFF log entry which then allows NXDN to pass new NXDN transmissions back through the bridge to HBlink3 master. Dave -- Dave WB6DTB FCS log.txt NXDN log.txt
More All Messages By This Member
Steve N4IRS #7968 Sorry. Show the output of: /opt/MMDVM_Bridge/MMDVM_Bridge -v Sent by smoke signal (AT&T) toggle quoted messageShow quoted text From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of David Young <dly2@...> Sent: Sunday, December 13, 2020 11:59:05 PM To: main@DVSwitch.groups.io <main@DVSwitch.groups.io> Subject: Re: [DVSwitch] Followup on Network Watchdog timeout message FCS to DMR bridge Steve, Not sure about the command you are asking me to execute /opt/MMDVM_Bridge -v This results in command not found. I think you are asking for the version of MMDVM_Bridge which is 1.6.1 for the NXDN bridge. Attached are 2 log files, one from the NXDN bridge log and the second from the FCS bridge log. These were copied from the MMDVM_Bridge log showing my transmissions from FCS00479 and resulting log entries seen from the NXDN MMDVM_Bridge. As seen on the NXDN bridge log after each FCS transmission is received on NXDN at the end of those transmissions the log shows the Network Timeout error and no TX OFF log entry, causing NXDN to stay in receive mode. The last transmission shown in the NXDN bridge log is from me transmitting from TGIF DMR showing a valid NXDN TX OFF log entry which then allows NXDN to pass new NXDN transmissions back through the bridge to HBlink3 master. Dave -- Dave WB6DTB
More All Messages By This Member
Steve N4IRS #7969 Dave, Mike and I tested FCS bridging this weekend. Here is what we ran: Mike: FCS00290 to NXDN 3166 Steve FCS00290 to DMR 3112138 In each case, audio is clean and EOT is being received by a station monitoring to bridge output. Admittedly, we were listening to the output on DVSwitch based nodes. We did not test with HBlink3 in the mix. Can you give me a simple diagram of what your are doing to bridge the 3 modes? Steve toggle quoted messageShow quoted text On 12/13/2020 11:59 PM, David Young wrote: Steve, Not sure about the command you are asking me to execute /opt/MMDVM_Bridge -v This results in command not found. I think you are asking for the version of MMDVM_Bridge which is 1.6.1 for the NXDN bridge. Attached are 2 log files, one from the NXDN bridge log and the second from the FCS bridge log. These were copied from the MMDVM_Bridge log showing my transmissions from FCS00479 and resulting log entries seen from the NXDN MMDVM_Bridge. As seen on the NXDN bridge log after each FCS transmission is received on NXDN at the end of those transmissions the log shows the Network Timeout error and no TX OFF log entry, causing NXDN to stay in receive mode. The last transmission shown in the NXDN bridge log is from me transmitting from TGIF DMR showing a valid NXDN TX OFF log entry which then allows NXDN to pass new NXDN transmissions back through the bridge to HBlink3 master. Dave -- Dave WB6DTB
More All Messages By This Member
Steve N4IRS #7979 David, What processor are you running your bridges on? uname -a toggle quoted messageShow quoted text On 12/13/2020 11:59 PM, David Young wrote: Steve, Not sure about the command you are asking me to execute /opt/MMDVM_Bridge -v This results in command not found. I think you are asking for the version of MMDVM_Bridge which is 1.6.1 for the NXDN bridge. Attached are 2 log files, one from the NXDN bridge log and the second from the FCS bridge log. These were copied from the MMDVM_Bridge log showing my transmissions from FCS00479 and resulting log entries seen from the NXDN MMDVM_Bridge. As seen on the NXDN bridge log after each FCS transmission is received on NXDN at the end of those transmissions the log shows the Network Timeout error and no TX OFF log entry, causing NXDN to stay in receive mode. The last transmission shown in the NXDN bridge log is from me transmitting from TGIF DMR showing a valid NXDN TX OFF log entry which then allows NXDN to pass new NXDN transmissions back through the bridge to HBlink3 master. Dave -- Dave WB6DTB
More All Messages By This Member
David Young #7983 Steve, Result of -v command: MMDVM_Bridge version 20201105_V1.6.1 git #0a3bff0 We are running all bridging on cloud server running 'Debian 10 Buster x64' and using the DVSwitch module 'MMDVM_Bridge.amd64' Didn't consider that HBlink3 might be causing the problem. We have the HBlink3 configuration set to: Repeat=true I will attach with the simple bridge diagram additional config files including the hblink.cfg. This is the first time I have used HBlink3 so you may see something wrong in my configuration causing this problem. We are using the same TG number for both TGIF DMR and NXDN. Thanks for your help, Dave -- Dave WB6DTB hblink.cfg rules.py DVSwitch.ini MMDVM_Bridge_NXDN.ini DVSwitch.ini MMDVM_Bridge_FCS.ini YSFGateway.ini
More All Messages By This Member
Steve N4IRS #7984 Dave, I have uploaded a proposed for your FCS EOT issue. It is located in the testing branch on github at <https://github.com/DVSwitch/MMDVM_Bridge/blob/Testing/raw/MMDVM_Bridge.amd64> To install: cd /opt/MMDVM_Bridge systemctl stop mmdvm_bridge mv MMDVM_Bridge MMDVM_Bridge.old wget https://github.com/DVSwitch/MMDVM_Bridge/raw/Testing/bin/MMDVM_Bridge.amd64 mv MMDVM_Bridge.amd64 MMDVM_Bridge systemctl start mmdvm_bridge retest and report. For anyone else that wants to play, I also pushed a update to armhf. Steve N4IRS toggle quoted messageShow quoted text On 12/14/2020 12:12 PM, David Young wrote: Steve, Result of -v command: MMDVM_Bridge version 20201105_V1.6.1 git #0a3bff0 We are running all bridging on cloud server running 'Debian 10 Buster x64' and using the DVSwitch module 'MMDVM_Bridge.amd64' Didn't consider that HBlink3 might be causing the problem. We have the HBlink3 configuration set to: Repeat=true I will attach with the simple bridge diagram additional config files including the hblink.cfg. This is the first time I have used HBlink3 so you may see something wrong in my configuration causing this problem. We are using the same TG number for both TGIF DMR and NXDN. Thanks for your help, Dave -- Dave WB6DTB
More All Messages By This Member
David Young #8031 Steve, Yes, success!!! Works perfectly. On you install instructions, a note: Installing the new MMDVM_Bridge module, just doing the systemctl stop command and replacing the existing MMDVM_Bridge module and restarting using systemctl start, did not fix the problem although the module did restart. I needed to reboot the server and restart from cold and that then did the trick and all works now. I had to also do a: chmod +x MMDVM_Bridge, to get my script to execute without a permission denied error. Thanks much Steve, I've been struggling with this for some time. -- Dave WB6DTB
More All Messages By This Member

1 - 14 of 14

Previous Topic Next Topic

Home Messages Hashtags Subgroups Wiki About Features Pricing Updates Terms Help Twitter