1. main@DVSwitch.groups.io
   Date   
Re: metadata management

Patrick Perdue
 

I'm not great at writing out flows.

My setup currently doesn't use ircDDBGateway, since that's all handled at the XLX reflector end. So, it goes like this.

Allstar <-> AB <-> HBLink <-> MB <-> XLXD (DMR, since XLX is also handling a BM interlink and YSF traffic) <-> ambed (connected to the XLX reflector) <-> TGIF.

I'm sure I screwed that up.

So basically, native AMBE traffic is transcoded to analog using the MD380-emu vocoder back to Allstar. DStar is transcoded through the pair of ThumnDV's on the reflector, which is then sent to MD380emu and then Allstar. Between DMR or YSF and DStar, this is fine, but from Allstar to DStar, it's going through another AMBE transcode before A_B sees it, so more latency and lower quality audio.

If I connect to the reflector directly as DStar, then use ASL to connect to the other modes, perhaps on another module of the reflector and HBLink, then DMR-YSF would only see the call specified in A_B, correct?

On 11/25/2020 7:18 PM, Steve N4IRS wrote:
I don't see how there are 2 vocoders to get from AllStar to D-Star. The flow would be:
AllStar <-> AB <-> MB <-> ircDDBGateway <-> XLX for D-Star.
You could drop the ircDDBGateway and go to XLX DMR.

Steve

On 11/25/20 7:14 PM, Patrick Perdue wrote:
Sure, but I'm currently going through two of them to get from Allstar to DStar.

I'm just wondering if there's a way to drop one of them out and still maintain metadata. I could directly connect A_B and MMDVM_Bridge to the XLX reflector and only direct DStar traffic to the module, and audio between DStar and the other digital modes should be about the same as it is now, but audio from Allstar to DStar has one less generation of vocoding, but then I lose metadata between the digital modes. At least, this is how I understand it.


On 11/25/2020 6:55 PM, Steve N4IRS wrote:
Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.
Re: metadata management

Steve N4IRS
 

I don't see how there are 2 vocoders to get from AllStar to D-Star. The flow would be:
AllStar <-> AB <-> MB <-> ircDDBGateway <-> XLX for D-Star.
You could drop the ircDDBGateway and go to XLX DMR.

Steve

On 11/25/20 7:14 PM, Patrick Perdue wrote:
Sure, but I'm currently going through two of them to get from Allstar to DStar.

I'm just wondering if there's a way to drop one of them out and still maintain metadata. I could directly connect A_B and MMDVM_Bridge to the XLX reflector and only direct DStar traffic to the module, and audio between DStar and the other digital modes should be about the same as it is now, but audio from Allstar to DStar has one less generation of vocoding, but then I lose metadata between the digital modes. At least, this is how I understand it.


On 11/25/2020 6:55 PM, Steve N4IRS wrote:
Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.
Re: metadata management

Patrick Perdue
 

Sure, but I'm currently going through two of them to get from Allstar to DStar.

I'm just wondering if there's a way to drop one of them out and still maintain metadata. I could directly connect A_B and MMDVM_Bridge to the XLX reflector and only direct DStar traffic to the module, and audio between DStar and the other digital modes should be about the same as it is now, but audio from Allstar to DStar has one less generation of vocoding, but then I lose metadata between the digital modes. At least, this is how I understand it.

On 11/25/2020 6:55 PM, Steve N4IRS wrote:
Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.
Re: metadata management

Steve N4IRS
 

Patrick,
Either way, you have to go through a vocoder to go from analog to D-Star Same for P25, you still have to go through a vocoder.

Steve

On 11/25/20 6:28 PM, Patrick Perdue wrote:
Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.
metadata management

Patrick Perdue
 

Hi:

I have a system that incorporates ASL, XLX, HBLink and DVSwitch. I'm toying with the idea of adding P25.

Currently, DStar is handled by XLX and a pair of transcoders connected to the XLX reflector, not DVSwitch. I would like to connect ASL directly to the XLX reflector in DStar mode, so that the audio to and from DStar to ASL is not transcoded through AMBE, but still pass metadata to DStar from the other digital modes. Is this at all possible? Similar question in regards to P25.

Basically, I want to do the least amount of transcoding possible to and from analog, while maintaining the greatest compatibility across digital modes. What I have now works, but I'd love to get rid of that extra layer of transcoding between analog and DStar without sacrificing metadata.

Thanks.
Re: Coming to a browser near you

Ted Holdahl
 
Edited

Terrific.  I can't wait.  This will be the first time that we can communicate with IOS devices.   I will be glad to help beta test.
Towards open-source infrastructure for DMR repost from OpenDV

Steve N4IRS
 

DMR, after D-Star, is the most political of the digtial voice modes. Unlike the other modes, most DMR systems connect to a centralised server, known as a "master" and that is responsible for all of the talk group routine, personal calls, and position data interpretation and forwarding. There are three main centralised systems: BrandMeister, DMR+ (known as Phoenix in the UK), and TGIF.
 
What these systems have in common is that they are closed source. This is not good for the amateur community. There were mutterings about them having signed NDAs with Hytera and Motorola to get details of their internet connection protocols, which may or may not be true. Even if true, why not make the non-NDA parts of the source code open?
 
In the commercial world, digital voice repeaters, be they for DMR, P25, NXDN, or dPMR have limited abilities within themselves for call routing. They do include CPUs of course, but for anything other than simple point-to-point links, they are useless. This limitation is fine for what they were originally designed for, small centrally controlled networks, with or without a dispatching console function. The YCS system for System Fusion is looking to do the same for YSF and that is why I oppose it.
 
This model of a centralised control structure carried through to the amateur DMR networks. In its simplest form, a repeater would simply have a point-to-point network connection to the master and things would be fine. Even with a semi-distributed system, with one or more master per country, there is still some central control of the system with the power to overrule the decisions made at the local level. Such central control is also not conducive to supporting each countries requirements, and leads to much used functionality being arbitrarily removed. In the extereme case the countries master may also be removed. When such things happen you have to ask from where did they derive their authority? Who voted for them? Who made the decision and how do they know that it is correct?
 
In the amateur world we have gone beyond having dumb repeaters. Most MMDVM systems for example have a Raspberry Pi or similar running the system, and have the potential to provide a lot of local processing power which can be used for more complex tasks than simply routing traffic over a point-to-point link. Many sysops expressed the wish to be able to have access to multiple masters, simultaneously, and hence the DMR Gateway was born in 2017. It does complex call routing, and almost everything else, bar the position data interpretation.
 
In some quarters this development was opposed. I believe that the sysop should have the choice on how to route their traffic and so development went ahead and it has been enhanced since. It has been a huge success.
 
I think that the time has come to look at having an open source, non-centralised, DMR network. A network where no one person or group has control. We already have the beginnings of this with the HBLink and with XLX projects. If more people get involved with these projects then they will grow and offer more features as time goes on.
 
Some may say, what about integration of commercial repeaters like Hyteras and Motorolas? There is already a program available that converts the Hytera repeater protocol to the protocol used by the MMDVM, and integration of Motorola repeaters is possible all be it with a number of programs in series. Maybe someone will rationalise this into something simpler.
 
Things are already moving on this, and I hope that in the future we will see such systems appear and then DMR will be free of the tyranny of what we have now. Sysops and their users are sovereign and should not be dictated to by anybody (the same goes for software developers :-) ).
 
Jonathan  G4KLX
 
Re: Coming to a browser near you

rogerd111
 

Great work. Thanks.
Can't wait to try it.
Re: Analog Bridge

Aaron Groover
 

Thanks steve. Now it all makes sense. I was just wondering.

Digging around the forums, Educating my mind with this program.

I guess I’m just fascinated with how simple and straight forward the script is. 

I have tested all 4 modes and just blown away with the ease of it. 
Re: Coming to a browser near you

Mike KB8JNM
 

I want some !   ...LOL...

On 11/23/2020 11:40 PM, Mike Zingman - N4IRR wrote:
First 2 way QSO (Thanks Ken!!!!!)
Re: Coming to a browser near you

Mike Zingman - N4IRR
 

First 2 way QSO (Thanks Ken!!!!!)
Re: Analog Bridge

Steve N4IRS
 

Oh, I forgot.
Yes, for "like to like" AMBE <-> AMBE all you need is MMDVM_Bridge It's a "loop back"
if you take MB apart, it's 5 different modes. All sending data out through UDP ports (TLV)
If you loop the TLV port for DMR to the TLV port for YSF. (TX to RX and RX to TX) You have a bridge.

On 11/23/20 7:42 PM, Aaron Groover wrote:

I just gotta know. How in the world is analog bridge not used for YSF to DMR?

 

How does this communicate?

Where is the PTT going? As in transmission.

I see nothing on MMDVM when I key it up.

The point of analog bridge is to bridge the analog OVER to the DMR/Fusion/Dstar or whatever flavor suits your side right?

Where is the audio exactly coming and going to and from?

 

15 years in radio development, and I still cant understand how or why this is…. NEVER have I seen just a MMDVM bridge running.

 

Because we use the same method to cross over any trunked county radio system to analog aka Berks County, City of Allentown, With an analog bridged system. MMDVM “Bridge” to me is simply just only logging into the networks.

 

I think this a good topic I guess, lets all the curious minds know 😉

 

Thanks for what you do Steve.

 

 

 

 

 

 

 

 

--

 

Thank You,

 

Aaron Groover

(610) 379 6148

K3ALG@...

agroover@...

 

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

 
Re: Analog Bridge

Steve N4IRS
 

Aaron,
Both YSF and DMR are AMBE. The only difference is the wrapper. Let me try to explain it this way.
You write a letter and put it in a envelope addressed to me. You mail it off trough the post office. When the post office receives it, they take you letter out of the envelope. They put your letter, unaltered, into a a new envelop and deliver it to me. The only thing taht changed it the envelop. The letter is unchanged.

MB receives the YSF. It extracts the raw AMBE. It builds a new DMR transmission containing the raw AMBE wrapped in such a way that a DRM radio can understand it.

DMR, YSF (narrow) and NXDN are all AMBE.
P25 and YSF (wide) are IMBE
D-Star is AMBE (more or less) at a different rate.

A transcoder is 2 vocoders back to back (AB <-> AB)
AMBE to AMBE does not need a transcoder (Analog_Bridge)
AMBE to IMBE needs a transcoder.
AMBE to D-Star needs a transcoder.
IMBE to D-Star needs a transcoder.
 
Anything to analog needs a vocoder. (Digital <-> Analog) Analog_Bridge

Hope this helps, Steve N4IRS

On 11/23/20 7:42 PM, Aaron Groover wrote:

I just gotta know. How in the world is analog bridge not used for YSF to DMR?

 

How does this communicate?

Where is the PTT going? As in transmission.

I see nothing on MMDVM when I key it up.

The point of analog bridge is to bridge the analog OVER to the DMR/Fusion/Dstar or whatever flavor suits your side right?

Where is the audio exactly coming and going to and from?

 

15 years in radio development, and I still cant understand how or why this is…. NEVER have I seen just a MMDVM bridge running.

 

Because we use the same method to cross over any trunked county radio system to analog aka Berks County, City of Allentown, With an analog bridged system. MMDVM “Bridge” to me is simply just only logging into the networks.

 

I think this a good topic I guess, lets all the curious minds know 😉

 

Thanks for what you do Steve.

 

 

 

 

 

 

 

 

--

 

Thank You,

 

Aaron Groover

(610) 379 6148

K3ALG@...

agroover@...

 

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

 
Re: Analog Bridge

Patrick Perdue
 

Analog_Bridge is only used to transcode uncommon audio formats, like DMR to P25, or DStar to YSF.

DMR, NXDN and YSF use the same codec, so MMDVM_Bridge handles that with no need to translate through A_B.

On 11/23/2020 7:42 PM, Aaron Groover wrote:

I just gotta know. How in the world is analog bridge not used for YSF to DMR?

 

How does this communicate?

Where is the PTT going? As in transmission.

I see nothing on MMDVM when I key it up.

The point of analog bridge is to bridge the analog OVER to the DMR/Fusion/Dstar or whatever flavor suits your side right?

Where is the audio exactly coming and going to and from?

 

15 years in radio development, and I still cant understand how or why this is…. NEVER have I seen just a MMDVM bridge running.

 

Because we use the same method to cross over any trunked county radio system to analog aka Berks County, City of Allentown, With an analog bridged system. MMDVM “Bridge” to me is simply just only logging into the networks.

 

I think this a good topic I guess, lets all the curious minds know 😉

 

Thanks for what you do Steve.

 

 

 

 

 

 

 

 

--

 

Thank You,

 

Aaron Groover

(610) 379 6148

K3ALG@...

agroover@...

 

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

 
Analog Bridge

Aaron Groover
 

I just gotta know. How in the world is analog bridge not used for YSF to DMR?

 

How does this communicate?

Where is the PTT going? As in transmission.

I see nothing on MMDVM when I key it up.

The point of analog bridge is to bridge the analog OVER to the DMR/Fusion/Dstar or whatever flavor suits your side right?

Where is the audio exactly coming and going to and from?

 

15 years in radio development, and I still cant understand how or why this is…. NEVER have I seen just a MMDVM bridge running.

 

Because we use the same method to cross over any trunked county radio system to analog aka Berks County, City of Allentown, With an analog bridged system. MMDVM “Bridge” to me is simply just only logging into the networks.

 

I think this a good topic I guess, lets all the curious minds know 😉

 

Thanks for what you do Steve.

 

 

 

 

 

 

 

 

--

 

Thank You,

 

Aaron Groover

(610) 379 6148

K3ALG@...

agroover@...

 

The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

 
Can you use MMDVM bridge to link DMR to YSF on Brandmeister? #brandmeister #mmdvm_bridge

@hamzahradio
 

Hello,

I have setup a bridge between DMR and Brandmeister. I was talking to a brandmeister admin,  N3FE, who said regarding the bridge "You are also linking your talkgroup using an open spot which is not the preferred method. "

I explained I was using MMDVM bridge on a server. Is it OK to use MMDVM bridge, even if it's not the "preferred" method? Anyone have experience with this?

Thanks 73
Re: YSF to DMR

Aaron Groover
 

Hey Steve, sorry for the late reply. Figured it out somehow, somehow "TXPort" in the YSF settings was "T/Port"

So I knew right there and then that was the problem. No idea how the slash got in that place, but gotta love linux!

I took a copy of my backup files that i keep in case my node crashes compared them via microsoft word, did a ctrl find, place the entire file in the search box and it highlighted it right to the slash and then thats when i knew that was the problem. 

All is good now. Thanks again sir. 
Re: Configuring DVSwitch Mobile to access own AllStarLink node

Steve N4IRS
 

No,
It would be the other way around. Start with the AllStar image, then add DVSwitch Server.

On 11/20/20 10:01 PM, Aerodan wrote:
Does DVSwitch Server have an option to install AllStarlLink from the new menu system, with the DVSwitch Mobile option working?

Re: Configuring DVSwitch Mobile to access own AllStarLink node

Aerodan
 

Does DVSwitch Server have an option to install AllStarlLink from the new menu system, with the DVSwitch Mobile option working?
Re: Dynamically reconfigure MMDVM_Bridge and Analog_Bridge ? #analog_bridge #mmdvm_bridge

Gerry Filby
 

Thank you Steve ...

That's exactly what I was looking for ... that should keep me busy for a while ...

Best,
Gerry.
W6WNG
1141 - 1160 of 8660