Welcome to DVSwitch
DVSwitch is a set of tools and programs related to provisioning and operating Amateur Radio digital voice networks.
Purpose
The purpose of DVSwitch is as follows:
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).
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
Our stated position is:
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.
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.
|
Re: Towards open-source infrastructure for DMR repost from OpenDV
G4KLX is saying what I've been thinking for at least a year now. The fact that BM and to a lesser extent DMR-MARC, DCI, TGIF and others have created a closed-source, walled-garden approach to interlinking leaves the individual repeater operators at the relative mercy of these networks. The recent UK master server crash is a clear indicator that the centralized technique needs some refactoring.
It's not original, sadly. Other analog-based interlinking tech has the same problems (I'm looking at IRLP and AllStarLink as two easy examples). Hams generally like the interconnection to be plug-and-play. A new approach would require people to actually do things like RTFM and test their changes in isolation before unleashing it on the network, possibly wreaking havoc. I'm all for an open and decentralized approach to interlinking. The obvious downsides is that it moves more of the work to the repeater operators to be on the lookout for bad actors, or at least LIDS. Some of what I'm getting at is that there needs to be tools to help a sysop/control op check that their configuration changes are going to do what they think it will. That's a tall order. I'd say that philosophically speaking, HBLink is aligned with this particular view of interlinking and interconnection. I think we have some real architectural challenges (not to mention devops, developer community, and all the rest) to become a robust contributor to this new approach. I also think that IPSC_Bridge and HB_Bridge (to a lesser extent) need to be brought up-to-date to Python 3 through a focus on creating a testable code base and then evolving it from there. I love this manifesto. I hope we can build something from it. --R -- Randy Hall AA6RH (not K7AGE, quit asking) 😁
|
|
|
|
Re: metadata management
Patrick Perdue
OK, so things are pretty much as I thought they were. Just wanted to make sure I wasn't missing anything should I decide to redesign this system. I'll probably keep things as-is for now, then add another private node for P25.
toggle quoted messageShow quoted text
Thanks.
On 11/25/2020 7:51 PM, Steve N4IRS wrote:
So,
|
|
|
|
Re: pyUC P25 "not linked"
You want to add it in 2 places.
toggle quoted messageShow quoted text
Add the reflector TG, IP and port in private_P25Hosts.txt Add the Name and TG in pyUC.ini in the P25 section. Steve N4IRS
On 11/25/20 9:45 PM, Scotty 2543G
KD2LWH wrote:
It seems to have fixed itself after a few times of opening and closing the application. Now I'm wondering how to add my private reflector to the list on USRP Client for P25. I have added it to the P25Hosts.txt file on the DV_Switch Server, but it doesn't show in the list on the client. Any ideas?
|
|
|
|
Re: pyUC P25 "not linked"
The app uses the configuration file pyUC.ini
|
|
|
|
Re: pyUC P25 "not linked"
Add it to pyUC.ini
toggle quoted messageShow quoted text
On 11/25/20 9:45 PM, Scotty 2543G
KD2LWH wrote:
It seems to have fixed itself after a few times of opening and closing the application. Now I'm wondering how to add my private reflector to the list on USRP Client for P25. I have added it to the P25Hosts.txt file on the DV_Switch Server, but it doesn't show in the list on the client. Any ideas?
|
|
|
|
Re: pyUC P25 "not linked"
Scotty 2543G KD2LWH
It seems to have fixed itself after a few times of opening and closing the application. Now I'm wondering how to add my private reflector to the list on USRP Client for P25. I have added it to the P25Hosts.txt file on the DV_Switch Server, but it doesn't show in the list on the client. Any ideas?
|
|
|
|
pyUC P25 "not linked"
Scotty 2543G KD2LWH
Hey guys,
The first time I started pyUC and switched modes to P25 it worked, no issues. Everytime after, I try to switch modes and it says "not linked" when I hit P25 and goes back to DMR. Any ideas why? I didn't ever "link or unlink" anything. Thanks in advance.
|
|
|
|
Re: metadata management
So,
toggle quoted messageShow quoted text
you have D-Star, DMR and AllStar. If you used AllStar to mix you could keep the number of vocoders to two and only have one transcoder. For the audio, you would have 2 private nodes. The first node would be DMR and pointed at TGIF. The second node would be D-Star and pointed at XLX. As you said in your first message, you issue would then be metadata. Steve
On 11/25/20 7:32 PM, Patrick Perdue wrote:
I'm not great at writing out flows.
|
|
|
|
Re: metadata management
Patrick Perdue
I'm not great at writing out flows.
toggle quoted messageShow quoted text
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:
|
|
|
|
Re: metadata management
I don't see how there are 2 vocoders to get from AllStar to D-Star. The flow would be:
toggle quoted messageShow quoted text
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.
|
|
|
|
Re: metadata management
Patrick Perdue
Sure, but I'm currently going through two of them to get from Allstar to DStar.
toggle quoted messageShow quoted text
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,
|
|
|
|
Re: metadata management
Patrick,
toggle quoted messageShow quoted text
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:
|
|
|
|
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
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
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:
|
|
|