Topics

YSFGateway with FCS bridging


David Young
 

With the new DVSwitch Server package, is it still required to use YSFGateway when bridging an FCS room to DMR?
Reason I'm asking, when bridging FCS to DMR with the previous DVSwitch, YSFGateway was required but I would get Network Watchdog timeout errors after each FCS transmission. 
--
Dave WB6DTB


Steve N4IRS
 

Yes, you need YSFGateway. Let us know if you see the timeout message.

On 11/4/2020 2:14 PM, David Young wrote:
With the new DVSwitch Server package, is it still required to use YSFGateway when bridging an FCS room to DMR?
Reason I'm asking, when bridging FCS to DMR with the previous DVSwitch, YSFGateway was required but I would get Network Watchdog timeout errors after each FCS transmission. 
--
Dave WB6DTB


Steve N4IRS
 

Can you tell me what HBlink you are connecting to so I can try to recreate it?

On 11/4/2020 2:14 PM, David Young wrote:
With the new DVSwitch Server package, is it still required to use YSFGateway when bridging an FCS room to DMR?
Reason I'm asking, when bridging FCS to DMR with the previous DVSwitch, YSFGateway was required but I would get Network Watchdog timeout errors after each FCS transmission. 
--
Dave WB6DTB


David Young
 

Hi Steve,

I downloaded your latest MMDVM_Bridge files off github and replaced the MMDVM_Bridge.amd64 new over to my FCS to DMR bridge.  Also replaced the old with new MMDVM_Bridge.ini and DVSwitch.ini files.  I still receive the Network Watchdog timeout error after each FCS transmission.  Yes, I did rename the MMDVM_Bridge.amd64 to MMDVM_Bridge.
We are using DVSwitch apps to bridge multiple modes over to a HBLink3 virtual server also running on an NFO cloud server.  I before updating to the new MMDVM_Bridge files which seem to have the same Watchdog error I tried various other configuration changes to both YSFGateway.ini and MMDVM_Bridge.ini files with no success, always generating the Network Watchdog error message when transmitting from any FCS room we have bridged to the HBLink3 server.  The best solution I could come up with was bridging the FCS rooms to our XLX server and then bridging the XLX server to DMR using DVSwitch modules.  This cut down my Network Watchdog errors to only approximately 30 percent of the time.  Kind of a round-about way of doing the bridging but still not completely eliminating the errors.  Going to attach a PDF file block diagram of how we are doing our bridging system.  Hope this will help.
--
Dave WB6DTB


Steve N4IRS
 

What FCS room can I point MB at to see the error?

On 11/4/20 5:20 PM, David Young wrote:
Hi Steve,

I downloaded your latest MMDVM_Bridge files off github and replaced the MMDVM_Bridge.amd64 new over to my FCS to DMR bridge.  Also replaced the old with new MMDVM_Bridge.ini and DVSwitch.ini files.  I still receive the Network Watchdog timeout error after each FCS transmission.  Yes, I did rename the MMDVM_Bridge.amd64 to MMDVM_Bridge.
We are using DVSwitch apps to bridge multiple modes over to a HBLink3 virtual server also running on an NFO cloud server.  I before updating to the new MMDVM_Bridge files which seem to have the same Watchdog error I tried various other configuration changes to both YSFGateway.ini and MMDVM_Bridge.ini files with no success, always generating the Network Watchdog error message when transmitting from any FCS room we have bridged to the HBLink3 server.  The best solution I could come up with was bridging the FCS rooms to our XLX server and then bridging the XLX server to DMR using DVSwitch modules.  This cut down my Network Watchdog errors to only approximately 30 percent of the time.  Kind of a round-about way of doing the bridging but still not completely eliminating the errors.  Going to attach a PDF file block diagram of how we are doing our bridging system.  Hope this will help.
--
Dave WB6DTB


David Young
 

I have been using FCS00479 to test with.


Steve N4IRS
 

David,
What we are seeing is that a FCS reflector unlike a YSF reflector is not always sending a EOT. The issue is not in the gateway or MB. to alleviate the issue, MB synthesizes a EOT sent across the bridge.
We have changed the message to keep the logs cleaner. I will push out the change this weekend.

Steve N4IRS

On 11/4/2020 5:20 PM, David Young wrote:
Hi Steve,

I downloaded your latest MMDVM_Bridge files off github and replaced the MMDVM_Bridge.amd64 new over to my FCS to DMR bridge.  Also replaced the old with new MMDVM_Bridge.ini and DVSwitch.ini files.  I still receive the Network Watchdog timeout error after each FCS transmission.  Yes, I did rename the MMDVM_Bridge.amd64 to MMDVM_Bridge.
We are using DVSwitch apps to bridge multiple modes over to a HBLink3 virtual server also running on an NFO cloud server.  I before updating to the new MMDVM_Bridge files which seem to have the same Watchdog error I tried various other configuration changes to both YSFGateway.ini and MMDVM_Bridge.ini files with no success, always generating the Network Watchdog error message when transmitting from any FCS room we have bridged to the HBLink3 server.  The best solution I could come up with was bridging the FCS rooms to our XLX server and then bridging the XLX server to DMR using DVSwitch modules.  This cut down my Network Watchdog errors to only approximately 30 percent of the time.  Kind of a round-about way of doing the bridging but still not completely eliminating the errors.  Going to attach a PDF file block diagram of how we are doing our bridging system.  Hope this will help.
--
Dave WB6DTB


David Young
 

Hi Steve,
Thank you for looking into this.  I know you are busy and I appreciate all the work you and your team put into the DVSwitch project.
Even before the new release of DVSwitch Server your team has developed an amazing set of bridges for use by the digital ham community.  If you have a PayPal contribution account I would be happy to contribute money to your efforts.
--
Dave WB6DTB


Steve N4IRS
 

David,
Thanks for the offer. We are not setup for that at this time.
I have updated MMDVM_Bridge on github and built updated apt packages for all 4 architectures. 
Please let me know when you have had a chance to test it.

73, Steve N4IRS

On 11/5/2020 7:46 PM, David Young wrote:
Hi Steve,
Thank you for looking into this.  I know you are busy and I appreciate all the work you and your team put into the DVSwitch project.
Even before the new release of DVSwitch Server your team has developed an amazing set of bridges for use by the digital ham community.  If you have a PayPal contribution account I would be happy to contribute money to your efforts.
--
Dave WB6DTB


David Young
 

Steve,

Ok, I downloaded the new MMDVM_Bridge off github and replaced the old with new for FCS00479 bridge.  After reboot I setup a test and looking at the FCS00479 MMDVM_Bridge log I see that now, yes I received the EOT message after the Network Watchdog timeout on the FCS00479 bridge.  Here's the problem, the EOT is not being passed to the NXDN MMDVM_Bridge log, only the Network Watchdog timeout message.  Thus, NXDN stays in receive mode waiting for the EOT.  If I key up DMR from the TGIF MMDVM_Bridge that will then clear the NXDN MMDVM_Bridge and NXDN will then Tx through the bridge until I Tx again on FCS00479, which then causes NXDN to stay in listening mode again.  The other bridges don't have this problem, XLX, P25, or DMR, only NXDN, maybe it is an ID issue since NXDN uses a unique ID, just a thought.
--
Dave WB6DTB