1. main@DVSwitch.groups.io
   Date   
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
Re: Configuring DVSwitch Mobile to access own AllStarLink node

Levi C. Maaia
 

Yep, that was the fix!
Re: Dynamically reconfigure MMDVM_Bridge and Analog_Bridge ? #analog_bridge #mmdvm_bridge

Steve N4IRS
 

Rewriting the .ini files is so 2019. ;)
Look at dvswitch.sh it will do everything you could want to do on the fly (Now, that's a bold statement) If it does not do it and you can make a case why it should it might be added.

run /opt/MMDVM_Bridge/dvswitch.sh to see the options available.

Steve N4IRS

On 11/20/2020 1:19 PM, Gerry Filby wrote:
Hi Folks,

Is there a way of dynamically configuring the bridges ?  Something along the lines of the management interface that Asterisk exposes ?

The immediate things would be - changing the target Talk Group and also receiving the telemetry to display to the user.

At the moment the best I can think of is rewriting the ".ini" files and then calling  :systemctl restart .._Bridge"

Best,
Gerry
W6WNG

Dynamically reconfigure MMDVM_Bridge and Analog_Bridge ? #analog_bridge #mmdvm_bridge

Gerry Filby
 

Hi Folks,

Is there a way of dynamically configuring the bridges ?  Something along the lines of the management interface that Asterisk exposes ?

The immediate things would be - changing the target Talk Group and also receiving the telemetry to display to the user.

At the moment the best I can think of is rewriting the ".ini" files and then calling  :systemctl restart .._Bridge"

Best,
Gerry
W6WNG
Re: Configuring DVSwitch Mobile to access own AllStarLink node

Steve N4IRS
 

There are 2 different things in play here. You have to consider the capabilities of DVSwitch Mobile (the Android client) and DVSwitch Server.
DVSwitch Mobile can be a IAX client. As a IAX client it can directly communicate with a AllStar node. That node can be AllStarLink or HAMVOIP.
DVSwitch Mobile can also communicate as a USRP client. This is primarily intended to communicate with DVSwitch Server which supports the 5 digital modes.

DVSwitch Server is available as a Raspbian image or can be installed on a existing Debian based system. DVSwitch Server can be installed on a existing AllStarLink node since that node is Debian based.
HAMVOIP is based on Arch, so the DVSwitch Server install packages can not easily be installed on HAMVOIP. ( we are working on a solution to this)

I hope I did not muddy the waters further.
73, Steve N4IRS

On 11/20/2020 12:48 PM, Aerodan wrote:
I may be off totally on this, but Steve doesn't the new drop of DVSwitch configure regular Allstar nicely, rather than using Hamvoip? I've been meaning to switch over from HV but... if it ain't broke :) AD

Re: Configuring DVSwitch Mobile to access own AllStarLink node

Aerodan
 

I may be off totally on this, but Steve doesn't the new drop of DVSwitch configure regular Allstar nicely, rather than using Hamvoip? I've been meaning to switch over from HV but... if it ain't broke :) AD
Re: ASL to DMR - not receiving inbound traffic

Gerry Filby
 

Thanks again Brad - I found my mistake in the AMBE_AUDIO section - once I put my DMR ID as the "gatewayDmrId" all started working correctly.

Thanks for your note on making the TG static - I ended removing that and I'm finding that the "auto-static" seems to work really well, the connection to the TG has stayed in place for several hours.

Cheers!

Gerry,
W6WNG
1141 - 1160 of 8654