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: Help with multiple instances of DV Switch
Alex MM7BDW
So Steve if I am understanding correctly. If I add a private node to my already existing configuration for the public node on ASL, then I can create two instances of each (MB,AB and MD380) and configure this to look at the private node with different USRP ports?
I've already copied MB,AB and MD380 into new directories and named them "2" and changed all the ports in the respective ini's. I'm sure I have read a doc somewhere before about the private node setup so should be able to follow that from there. To sum up, I just need to have a private node setup within the existing rpt.conf and as long as the USRP ports are different from the original then this should work? Thanks for your help Steve Alex
|
|
|
|
Re: Help with multiple instances of DV Switch
Based on what you already have built, the easiest is to do the
bridging in AllStar. You will need to add a second AllStar node to
you existing AllStar server. This is usually called a "private node"
or a non published node to be more accurate. (This does not HAVE to
be private) The second node would connect to your second
Analog_Bridge via USRP (again different ports then you used for your
first node) This way, DMR network 1 would be connected to you public
node and DMR network 2 would be connected to your second AllStar
node.
toggle quoted messageShow quoted text
Steve
On 4/23/2021 9:16 AM, Alex MM7BDW
wrote:
Connectivity to AllStar is more important. It started off with this "bridge node" being connected into our normal AllStar network bridging to one DMR network which was simple to setup until we decided to also want to be connected to another network as well. So I suppose in a way bridging DMR to DMR could be the solution. We don't need mobile device access or web browser access. As long as whatever happens on our AllStar side of things can be heard coming through the DMR networks and vice versa. Ideally I would be looking for the simplest approach as I am very new to this and just learning as I go
|
|
|
|
Re: Help with multiple instances of DV Switch
Alex MM7BDW
Connectivity to AllStar is more important. It started off with this "bridge node" being connected into our normal AllStar network bridging to one DMR network which was simple to setup until we decided to also want to be connected to another network as well. So I suppose in a way bridging DMR to DMR could be the solution. We don't need mobile device access or web browser access. As long as whatever happens on our AllStar side of things can be heard coming through the DMR networks and vice versa. Ideally I would be looking for the simplest approach as I am very new to this and just learning as I go
Alex
|
|
|
|
Re: Help with multiple instances of DV Switch
Alex,
toggle quoted messageShow quoted text
is the bridging the 2 DMR the primary purpose of the bridge or is connectivity to AllStar more important? If you need to shutdown the DMR bridge, does AllStar need to stay connected to one or more of the DMR networks? Do you need access from Mobile devices (cellular / WiFi) Do you need web browser access? I can see this as a full time DMR <-> DMR bridge with AllStar also connected. DMR <-> DMR would not need to be transcoded, so no loss of DMR quality. I see 2 instances of MMDVM_Bridge and 1 instance of Analog_Bridge. Steve
On 4/23/2021 8:41 AM, Alex MM7BDW
wrote:
Steve,
|
|
|
|
Re: Help with multiple instances of DV Switch
Alex MM7BDW
Steve,
Basically the setup is that my friend and I have started putting together a small network. We have a few nodes in the cloud and a couple of RF connected nodes. We have Echolink configured and coming into a couple of these nodes and at the moment have it bridging across to 2 different DMR talkgroups on 2 different networks. We have achieved this by having one node configured to bridge to one network and another node configured to bridge to the other network. These talkgroups are ours that we have set up so we know they aren't connected elsewhere and therefore we know that there are no loops being created. What I was hoping to do was to have this happening on one node only and therefore a couple of instances of DV Switch needed to do that. That way if there are any problems it means we can just disconnect that node and it doesn't interfere with anything else we are doing. Hope this makes sense. Alex MM7BDW
|
|
|
|
Re: Help with multiple instances of DV Switch
Alex,
To build your system the way you defined, yes, you need to define a second node in rpt.conf and use another pair of port numbers for USRP. My question is what is your end goal? Are you trying to access 2 different DMR networks at the same time? Are you trying to bridge the 2 DMR networks? (may not be a good idea) Tell us more about your goals and we can go from there. Steve N4IRS
|
|
|
|
Re: Help with multiple instances of DV Switch
Patrick Perdue
To avoid transcoding issues between multiple common AMBE codecs,
it's a better idea to use hblink and a single instance of
DVSwitch. Hblink connects to the master servers (if Brandmeister,
use OpenBridge or connect to an XLX reflector with interlink) and
let it do the digital bridging, then connect to your local hblink
as a master with MMDVM_Bridge. This works well for me, bridging
Brandmeister via XLX interlink, and two other DMR master servers. Note: DO *NOT* use hblink as a standard peer to Brandmeister.
On 4/22/2021 10:38 PM, mm7bdw@...
wrote:
Hi there, I am trying to bridge ASL to two different DMR networks and understand that I need to run two instances of DV Switch to make this happen. I have MMDVM_Bridge, MMDVM_Bridge2, Analog_Bridge and Analog_Bridge2. I have copied over the .service files as well and amended the path to the new instances in each service. I have chose different tx and rx ports in the second instance so that they are not the same as the first and changed the local ports on the DMR stanza to make them different as well. From what I can see, everything is set up correctly and the logs confirm that both instances have logged into their respective DMR masters correctly.
|
|
|
|
Help with multiple instances of DV Switch
Alex MM7BDW
Hi there, I am trying to bridge ASL to two different DMR networks and understand that I need to run two instances of DV Switch to make this happen. I have MMDVM_Bridge, MMDVM_Bridge2, Analog_Bridge and Analog_Bridge2. I have copied over the .service files as well and amended the path to the new instances in each service. I have chose different tx and rx ports in the second instance so that they are not the same as the first and changed the local ports on the DMR stanza to make them different as well. From what I can see, everything is set up correctly and the logs confirm that both instances have logged into their respective DMR masters correctly.
My question is, do I need to specify different USRP ports for the second instance and if so how do I also show this in the rpt.conf file on ASL? Basically I can only transmit and receive from ASL to one DMR network (the first instance) and not the second. This is the only thing I think that might be preventing it from working correctly. Any advice on what to look at here? Thanks in advance Alex MM7BDW
|
|
|
|
Re: Fusion node lists and tune string
Also, show me the startup of YSFGateway
toggle quoted messageShow quoted text
On 4/22/21 2:00 PM,
G4WXN@... wrote:
Files attached.
|
|
|
|
Re: Fusion node lists and tune string
Show me the output of:
toggle quoted messageShow quoted text
netstat -unap Steve N4IRS
On 4/22/21 2:00 PM,
G4WXN@... wrote:
Files attached.
|
|
|
|
Re: STFU
STFU is our implementation of the BrandMeister Open DMR Terminal
Protocol. BM is pushing all the software based developrs to use
ODMRTP to connect to BM. Simple Terminal Feature Update is our
answer to BrandMeister. ODMRTP has problems and more may have
cropped up today.
toggle quoted messageShow quoted text
Intercom mode is used to communicate between DVSwitch clients across the Analog_Reflector without going out over and of the supported digital protocols (DMR D-Star YSF NXDN P25 M17) Steve N4IRS
On 4/22/21 4:41 PM, Kenneth Grimard
wrote:
|
|
|
|
YSF reflector How-To
Benjamin ON5BGO
HI all, (sorry for this off-topic message but i don’t found the YSF group, if it’s exists)
|
|
|
|
Re: STFU
Kenneth Grimard
What is stfu mode? What is intercom mode? Ken n1dot
On Thu, Apr 22, 2021, 15:30 f0dei <f0dei@...> wrote:
|
|
|
|
Re: STFU
f0dei
yes, 7 digit (2080360) but it's not working. KENWOOD NX5300 decode as Broadcast call (not decode every Time) HYTERA and Motorola decode nothing.
|
|
|
|
Re: STFU
Do not use SSID, just 7 digit DMR ID
|
|
|
|
Re: STFU
f0dei
For your info :
On Motorola not OK no audio no talker alias On Hytera not OK no audio no talker alias OK on Kenwood NX5300 OK call received as brodcast call???
|
|
|
|
Re: STFU
f0dei
Ok no problem.
Something is always wrong since no audio on RF side. Good meeting and let me know if you found something. Thanks for your nice work !
|
|
|
|
Re: STFU
I'm in a meeting, I'll check in when I can
Sent via smoke signal (AT&T)
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of f0dei <f0dei@...>
Sent: Thursday, April 22, 2021 2:03:45 PM To: main@DVSwitch.groups.io <main@DVSwitch.groups.io> Subject: Re: [DVSwitch] STFU With DMR ID, call is routed to RF side but no audio and no ID or talker alias
|
|
|
|
Re: STFU
f0dei
With DMR ID, call is routed to RF side but no audio and no ID or talker alias
|
|
|
|
Re: STFU
Put in your dmr id
Sent via smoke signal (AT&T)
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of f0dei <f0dei@...>
Sent: Thursday, April 22, 2021 1:46:12 PM To: main@DVSwitch.groups.io <main@DVSwitch.groups.io> Subject: Re: [DVSwitch] STFU in DVSwitch.in
UserID = 208036002
|
|
|