Date   

Re: USRP Ports

Ed W8VT
 

That's great! How do I accomplish this? How do I get AB to talk to ASL and DVSM? Hence my original confused question about ports.
This system is a Pi3 with DV3000 and the private radioless node connects to my other node. Thanks Steve.


Re: USRP Ports

Steve N4IRS
 

It's not you. I needed to make sure what you were after. So, the answer is yes. You can build a server that has access to the digital modes. Those modes can be accessed from AllStar and DVSM. Think of it this way, you will have one digital node. That node is accessible from both AllStar and DVSM. As an added bonus if you call today (joke) you can also access the server from a web browser. The digital node is a shared resource. If AllStar tunes over to DMR TG 3166 then DVSM and HTML client are also tuned there. Another bonus is you can have full access to the AllStar node from DVSM or the HTML client. If you want to connect the AllStar node to node 2100, you can from DVSM or HTML. You will have the DVSwitch Dashboard with the RX Monitor. You can add Allmon2. I have not tested SuperMon. Here are the things you can't do:

If in the cloud, you should not use D-Star
If on a hardware host, you can not connect a radio. (well maybe)

So, cloud or hardware? Radio or not?

Steve N4IRS

On 3/3/2021 1:16 PM, Ed W8VT wrote:
That would be kind of cool, mainly as an easy way to control it. I ran it for several years just locked down to one DMR TG and we would connect to the private ASL node when needed. Being able to use the phone app would really expand the capabilities. Sorry for not articulating my question very well.


Re: USRP Ports

Ed W8VT
 

That would be kind of cool, mainly as an easy way to control it. I ran it for several years just locked down to one DMR TG and we would connect to the private ASL node when needed. Being able to use the phone app would really expand the capabilities. Sorry for not articulating my question very well.


Re: USRP Ports

Steve N4IRS
 

Ed,
Please excuse me if I'm trying to be too specific. So, you want AllStar and the Android Mobile client to both be able to connect to the digital voice networks.

Steve

On 3/3/2021 1:03 PM, Ed W8VT wrote:
Yes Sir. Have DVSwitch Server with DVSM and also have AB out to ASL so it can be connected to our analog system.


Re: USRP Ports

Ed W8VT
 

Yes Sir. Have DVSwitch Server with DVSM and also have AB out to ASL so it can be connected to our analog system.


Re: USRP Ports

Steve N4IRS
 

I think I understand the question. Yes.
Do you mean DVSwitch Server and AllStar?


On 3/3/2021 12:50 PM, Ed W8VT wrote:
Is it even possible to have a setup where we can have DVSM and ASL at the same time?


Re: USRP Ports

Ed W8VT
 

Is it even possible to have a setup where we can have DVSM and ASL at the same time?


Re: Reliable Transcoding with Brandmeister DMR - Who and How?

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


Re: Unable to connect to Brandmeister using HBlink #hblink

David BV3UN
 

Hi Steve 
it works .after i make TX/RX are different .for example TX=433800000 ,RX=433500000,it login BM success now


Re: Reliable Transcoding with Brandmeister DMR - Who and How?

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


Configuration script

IK7VXC Mike
 

Hi. I don't know if this has been asked before, so please bear with me.
Some friends have asked me to help them configure the server. And since having to do this all the time is a nuisance I wonder: is there a way to add a configuration file (something like the wpa_supplicant does with the hotspot) to the sd card so that the installation is automated?
Thank you


Re: Reliable Transcoding with Brandmeister DMR - Who and How?

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) 😁


Re: Reliable Transcoding with Brandmeister DMR - Who and How?

J M
 

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.


Re: Reliable Transcoding with Brandmeister DMR - Who and How?

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.


Re: Reliable Transcoding with Brandmeister DMR - Who and How?

J M
 

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.


Re: Reliable Transcoding with Brandmeister DMR - Who and How?

J M
 

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.


Re: Reliable Transcoding with Brandmeister DMR - Who and How?

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


Re: Where the heck is hUC?

Steve N4IRS
 

Analog_Reflector is released and available for install. See https://dvswitch.groups.io/g/Analog-Reflector/message/34


Reliable Transcoding with Brandmeister DMR - Who and How?

J M
 

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


USRP Ports

Ed W8VT
 

Decided to redo my setup that is several years old with the new DVSwitch ASL image that was just released. Got it working fine with the mobile app.
The question is what do I do about Allstar? Apparently the mobile app wants the tx and rx ports the same and Allstar rpt.conf wants them different.
In my setup it is important to be able to connect the digital world over to analog via Allstar. Am I missing something obvious?

Thanks,
Ed W8VT

1081 - 1100 of 9775