Welcome to DVSwitch
Purpose
1) Allows “local” networking during an outage of the regional national/international network server.
2) Allows a local network operator to “blend” upstream feeds from different Networks (capital N on purpose). These Networks can’t get their act together and learn how to play nice with each other (everyone guilty as far as we are concerned). They may not like people doing this, but the solution is to grow up and work with each other, and not keep trying to force people to take sides.
3) Allows local segregation of localized traffic with more flexibility.
4) Allows experimentation with linking and how it’s done (part 97 specifies experimentation and advancement of the radio art are a core part of amateur radio).
Mission Statement/Position
WHEREAS the Networks continue to be largely islands and are not working together to create a unified network of Networks.
WHEREAS no firm reason has been given by any of the Networks why a *competent* local network operator cannot make this work effectively.
(US ONLY)
WHEREAS 47 CFR 97 (Amateur Radio Service) specifies that a core component of amateur radio is experimentation and advancement of the radio art [97.1(b)].
BE IT RESOLVED the core group of US amateur radio operators and experimenters organized around the DVSwitch project, and in the spirit of USA 47 CFR 97 and its intentions, support the *responsible* and *thoughtful* use of digital voice networking tools to create localized networks that will interconnect to the national/international Networks, and will support users of its tools in order to do this in the most effective and sustainable way possible.
Towards open-source infrastructure for DMR repost from OpenDV
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. I guess I’m just fascinated with how simple and straight forward the script is.
|
|
Re: Coming to a browser near you
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
First 2 way QSO (Thanks Ken!!!!!)
|
|
Re: Analog Bridge
Oh, I forgot.
toggle quoted messageShow quoted text
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:
|
|
Re: Analog Bridge
Aaron,
toggle quoted messageShow quoted text
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:
|
|
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:
|
|
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
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
No,
toggle quoted messageShow quoted text
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
Yep, that was the fix!
|
|
Re: Dynamically reconfigure MMDVM_Bridge and Analog_Bridge ?
#analog_bridge
#mmdvm_bridge
Rewriting the .ini files is so 2019. ;)
toggle quoted messageShow quoted text
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,
|
|
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
There are 2 different things in play here. You have to consider the
capabilities of DVSwitch Mobile (the Android client) and DVSwitch
Server.
toggle quoted messageShow quoted text
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
|
|