1. Topics
  2. Reliable Transcoding with Brandmeister DMR - Who and How?

Reliable Transcoding with Brandmeister DMR - Who and How?

Charles Wiant
 

BM3103  74.91.118.251 A do you something like that in your interlink file and so I am following along you have dvswitch running on same machine

 

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> On Behalf Of J M
Sent: Thursday, March 04, 2021 12:56 PM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Reliable Transcoding with Brandmeister DMR - Who and How?

 

All of the functions are on the same system. XLXD is bound to the public IP of the system and ambed is running on 127.0.0.1. All inbound connections for D-STAR, DMR, and YSF come in to the XLX330 IP address.


Ambed <------> XLXD <---------> BM 3103 <> TG311070
                  |
                  +-----> UDP/42000 as YSF #83603
                  |
                  +-----> UDP/20001,30001,etc as D-STAR XRF330/DCS330/XLX330

I've started to look into using hblink3 between XLXD and BrandMeister. BM connection would be an OpenBridge to hblink3 and then DMR on TS2/TG9 <> XLX:4001. Not having much success so far.

Charles Wiant
 

Can you message me off list


On Mar 4, 2021, at 12:56 PM, J M <jason@...> wrote:

All of the functions are on the same system. XLXD is bound to the public IP of the system and ambed is running on 127.0.0.1. All inbound connections for D-STAR, DMR, and YSF come in to the XLX330 IP address.


Ambed <------> XLXD <---------> BM 3103 <> TG311070
                  |
                  +-----> UDP/42000 as YSF #83603
                  |
                  +-----> UDP/20001,30001,etc as D-STAR XRF330/DCS330/XLX330

I've started to look into using hblink3 between XLXD and BrandMeister. BM connection would be an OpenBridge to hblink3 and then DMR on TS2/TG9 <> XLX:4001. Not having much success so far.

Jason McCormick N8EI
 

All of the functions are on the same system. XLXD is bound to the public IP of the system and ambed is running on 127.0.0.1. All inbound connections for D-STAR, DMR, and YSF come in to the XLX330 IP address.


Ambed <------> XLXD <---------> BM 3103 <> TG311070
                  |
                  +-----> UDP/42000 as YSF #83603
                  |
                  +-----> UDP/20001,30001,etc as D-STAR XRF330/DCS330/XLX330

I've started to look into using hblink3 between XLXD and BrandMeister. BM connection would be an OpenBridge to hblink3 and then DMR on TS2/TG9 <> XLX:4001. Not having much success so far.

Charles Wiant
 

Is your ambed not ambe is on the same machine and if not do you have all ports open and if not on same machine do you have ip pointing to reflector.


On Mar 2, 2021, at 5:45 PM, J M <jason@...> wrote:

I'm back again and still looking for someone who can share some best practices for reliable transcoding with BrandMeister DMR. I realize this is not an XLX/Ambed support forum, but I think this description of the problem will help explain my struggle so please indulge me. I"ve searched in the messages, Wiki, and the Google machine in vain for a solution to my problem.

I run XLX330/YSF #83603 which is also transcoded to BM TG 311070. I have a consistent repeatable problem with BrandMeister DMR completely locking up xlxd/ambed when there is any sort of not-trivial communication stream (e.g. a net with a number of DMR users). A set of D-STAR and YSF users can talk forever without a hiccup. During a multi-mode net without fail, right in the middle of a DMR transmission coming into xlxd from BrandMeister, xlxd will start throwing errors like:

 

Feb 22 20:18:23 localhost xlxd: Opening stream on module A for client BM3103   with sid 34594
Feb 22 20:18:31 localhost xlxd: Closing stream of module A
Feb 22 20:18:31 localhost xlxd: ambed 1452 of 306 packets timed out
Feb 22 20:18:31 localhost ambed[5539]: Vocodec channel DVstick-33:1 -> DVstick-33:0 closed
Feb 22 20:18:31 localhost ambed[5539]: 0 of 306 packets lost
Feb 22 20:18:31 localhost ambed[5539]: Stream 18 closed
It is ALWAYS on a DMR connection this begins. After that, every subsequent transmission regardless of mode is broken. Every repeater that didn't have the originating RF traffic shows only a 0.1s transmission with no audio and the logging is always the "X of Y packets timed out" error. The only resolution is to restart both ambed and xlxd. The problem has never started with a YSF or D-STAR transmission, always and only DMR. I've tried putting MMDVM_Bridge/DVSwitch in the middle a few time, trying first to "unload" processing of YSF to a YSFReflector joined through MMDVM_Bridge. Then I tried using MMDVM_Bridge to interface with a DMRGateway process. Whatever the issue is, the root cause appears to be BM DMR traffic being processed with xlxd/ambed. So I'm trying to find another, reliable way.

When I was using xlx + MMDVM_Bridge + DMRGateway the lockup didn't occur but that was because there was a different problem. At the tail end of any RF transmission into a DMR repeater, the DMR repeater would then "hear" an echo from DMR network of the same transmission and then lock open with a "Net" transmission (Pi-Star) which would hang the repeater open until some 60-second timer seemed to trip. I tried fiddling with the hangTimerInFrames inside of DVSwitch.ini but that did not seem to make any difference.

So, if you read this far, I REALLY appreciate your reading to the end and would appreciate info from anyone who's linking with BrandMeister. I'm open to making any needed change to the environment to get it all working and stable. Only need is continue to use xlxd for D-STAR.

Thanks!
Jason N8EI

David BV3UN
 

is your diagram as below
                           ambed with Dvstick33 transcode                             interlink
XLX D-star MA<------------------------------------------->XLX DMR MA <----------------->BM 3103

and the problem is between XLXD DMR and BM 3103 ?.as i know the abmed is effect on X-Dstat <->X DMR
Randy AA6RH
 

I'd say you'd be doing everyone a favor if you provided a diagram of how everything is connected/interconnected.

--R
--
Randy Hall AA6RH (not K7AGE, quit asking) 😁
Jason McCormick N8EI
 

Sorry, maybe I wasn't clear. That's what I have right now. I have an interlink to BM3103 with my XLX server on Module A. That's what's not working properly.
Patrick Perdue
 

I'd just have BM create an interlink for your XLX reflector, and not use DVSwitch for that part. Oh yeah, I just said that on the DVSwitch mailing list... Seriously though, that's probably the cleanest way to do it.


On 3/2/2021 8:22 PM, J M wrote:
I also should have mentioned I'd be open to doing the transcoding in a different way too if there's a better way to interlink with BM through one of the DVSwitch tools.

Jason McCormick N8EI
 

I also should have mentioned I'd be open to doing the transcoding in a different way too if there's a better way to interlink with BM through one of the DVSwitch tools.
Jason McCormick N8EI
 

I should have mentioned that my transcoding is all local. It's a DVStick33 + DVStick30 on the local system. Currently it's connected to an ambed process. I'm on B3103 and currently, everything is being handled within xlxd (DSTAR, YSF, and DMR all in xlxd). I've taken several runs at MMDVM_Bridge/DVSwitch with YSFGateway and DMRGateway without success. I just don't understand why it's always a DMR stream that causes the hiccup. I was wondering if anyone is keeping DMR "at a distance". Wasn't sure if HBlink could handle that. I've wanted to add analog to Allstar, but I've got to get this working reliably before I try to add another piece.
Patrick Perdue
 

Hi:

Sounds like you're connecting DVSwitch to both Brandmeister and your XLX reflector. Is that correct?

On my system, using an XLX Interlink from Brandmeister 3101, and a remote transcoder that isn't too far from the datacenter where the reflector lives, I can leave things untouched for months. DVSwitch is only used to connect between my HBlink and Allstar. HBlink is bridging between both Prime and legacy TGIF, and XLX reflector 679, which is also hosting YSF, Peanut and Brandmeister on module A, as well as a couple of links from other systems. In other words, DVSwitch doesn't directly care about my XLX reflector, and Brandmeister is getting into the system through XLX Interlink on 3101 rather than connecting via DVSwitch or HBlink. If I take DVSwitch and HBlink out of the loop, I still have Brandmeister, YSF, Peanut and DStar interconnected.

My YSF reflector is hosted directly by XLXD, not an external process, with autolink compiled to connect YSF clients to module A.

All this is running extremely stable, but, yes, things do fall over when/if the ambed transcoder breaks, for example, if my home internet goes down, but I don't need to restart the reflector or the transcoder when it comes back online. Things just start working again.
I am eventually going to take the transcoders away from the XLX reflector, and assign one vocoder dongle to a second instance of DVSwitch so I can avoid a layer of transcoding between Allstar and DStar. Currently, stations that are communicating between these two modes have AMBE transcoding between the two endpoints. I've avoided doing this before due to losing metadata, which the DStar users, especially, would complain about, but analog reflector should fix that. Plus, there are far fewer DStar users on my system than DMR.

I don't know if any of this helps, but that's what I'm doing here.

On 3/2/2021 6:45 PM, J M wrote:
I'm back again and still looking for someone who can share some best practices for reliable transcoding with BrandMeister DMR. I realize this is not an XLX/Ambed support forum, but I think this description of the problem will help explain my struggle so please indulge me. I"ve searched in the messages, Wiki, and the Google machine in vain for a solution to my problem.

I run XLX330/YSF #83603 which is also transcoded to BM TG 311070. I have a consistent repeatable problem with BrandMeister DMR completely locking up xlxd/ambed when there is any sort of not-trivial communication stream (e.g. a net with a number of DMR users). A set of D-STAR and YSF users can talk forever without a hiccup. During a multi-mode net without fail, right in the middle of a DMR transmission coming into xlxd from BrandMeister, xlxd will start throwing errors like:

 

Feb 22 20:18:23 localhost xlxd: Opening stream on module A for client BM3103   with sid 34594
Feb 22 20:18:31 localhost xlxd: Closing stream of module A
Feb 22 20:18:31 localhost xlxd: ambed 1452 of 306 packets timed out
Feb 22 20:18:31 localhost ambed[5539]: Vocodec channel DVstick-33:1 -> DVstick-33:0 closed
Feb 22 20:18:31 localhost ambed[5539]: 0 of 306 packets lost
Feb 22 20:18:31 localhost ambed[5539]: Stream 18 closed
It is ALWAYS on a DMR connection this begins. After that, every subsequent transmission regardless of mode is broken. Every repeater that didn't have the originating RF traffic shows only a 0.1s transmission with no audio and the logging is always the "X of Y packets timed out" error. The only resolution is to restart both ambed and xlxd. The problem has never started with a YSF or D-STAR transmission, always and only DMR. I've tried putting MMDVM_Bridge/DVSwitch in the middle a few time, trying first to "unload" processing of YSF to a YSFReflector joined through MMDVM_Bridge. Then I tried using MMDVM_Bridge to interface with a DMRGateway process. Whatever the issue is, the root cause appears to be BM DMR traffic being processed with xlxd/ambed. So I'm trying to find another, reliable way.

When I was using xlx + MMDVM_Bridge + DMRGateway the lockup didn't occur but that was because there was a different problem. At the tail end of any RF transmission into a DMR repeater, the DMR repeater would then "hear" an echo from DMR network of the same transmission and then lock open with a "Net" transmission (Pi-Star) which would hang the repeater open until some 60-second timer seemed to trip. I tried fiddling with the hangTimerInFrames inside of DVSwitch.ini but that did not seem to make any difference.

So, if you read this far, I REALLY appreciate your reading to the end and would appreciate info from anyone who's linking with BrandMeister. I'm open to making any needed change to the environment to get it all working and stable. Only need is continue to use xlxd for D-STAR.

Thanks!
Jason N8EI

Jason McCormick N8EI
 

I'm back again and still looking for someone who can share some best practices for reliable transcoding with BrandMeister DMR. I realize this is not an XLX/Ambed support forum, but I think this description of the problem will help explain my struggle so please indulge me. I"ve searched in the messages, Wiki, and the Google machine in vain for a solution to my problem.

I run XLX330/YSF #83603 which is also transcoded to BM TG 311070. I have a consistent repeatable problem with BrandMeister DMR completely locking up xlxd/ambed when there is any sort of not-trivial communication stream (e.g. a net with a number of DMR users). A set of D-STAR and YSF users can talk forever without a hiccup. During a multi-mode net without fail, right in the middle of a DMR transmission coming into xlxd from BrandMeister, xlxd will start throwing errors like:

 

Feb 22 20:18:23 localhost xlxd: Opening stream on module A for client BM3103   with sid 34594
Feb 22 20:18:31 localhost xlxd: Closing stream of module A
Feb 22 20:18:31 localhost xlxd: ambed 1452 of 306 packets timed out
Feb 22 20:18:31 localhost ambed[5539]: Vocodec channel DVstick-33:1 -> DVstick-33:0 closed
Feb 22 20:18:31 localhost ambed[5539]: 0 of 306 packets lost
Feb 22 20:18:31 localhost ambed[5539]: Stream 18 closed
It is ALWAYS on a DMR connection this begins. After that, every subsequent transmission regardless of mode is broken. Every repeater that didn't have the originating RF traffic shows only a 0.1s transmission with no audio and the logging is always the "X of Y packets timed out" error. The only resolution is to restart both ambed and xlxd. The problem has never started with a YSF or D-STAR transmission, always and only DMR. I've tried putting MMDVM_Bridge/DVSwitch in the middle a few time, trying first to "unload" processing of YSF to a YSFReflector joined through MMDVM_Bridge. Then I tried using MMDVM_Bridge to interface with a DMRGateway process. Whatever the issue is, the root cause appears to be BM DMR traffic being processed with xlxd/ambed. So I'm trying to find another, reliable way.

When I was using xlx + MMDVM_Bridge + DMRGateway the lockup didn't occur but that was because there was a different problem. At the tail end of any RF transmission into a DMR repeater, the DMR repeater would then "hear" an echo from DMR network of the same transmission and then lock open with a "Net" transmission (Pi-Star) which would hang the repeater open until some 60-second timer seemed to trip. I tried fiddling with the hangTimerInFrames inside of DVSwitch.ini but that did not seem to make any difference.

So, if you read this far, I REALLY appreciate your reading to the end and would appreciate info from anyone who's linking with BrandMeister. I'm open to making any needed change to the environment to get it all working and stable. Only need is continue to use xlxd for D-STAR.

Thanks!
Jason N8EI
1 - 12 of 12