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: Connecting more that 2 Analog_Bridges
#analog_bridge
JJ Cummings
Maybe it's just a matter of what you and I are calling thing? I read "address" as an IP Address which does not need to be unique at all. All that needs to happen is each mode has an ASL node which listens for and sends USRP on a given set of ports. Those ports need to be unique per node, but note the IP Address.
On Tue, Mar 24, 2020 at 11:03 AM Mike KB8JNM <groupio@...> wrote:
|
|
|
|
Re: Connecting more that 2 Analog_Bridges
#analog_bridge
I was referring to the USRP address. One address set for each
node.
On 3/24/2020 12:57 PM, JJ Cummings
wrote:
|
|
|
|
Re: Connecting more that 2 Analog_Bridges
#analog_bridge
JJ Cummings
You are correct with your design. Not sure what "address" needs to be different.. but each would require it's own node entry in your ASL config and then you would need to link those ASL nodes together. We accomplish this by having each mode have it's own node (as noted already) and then link each of those into a central ASL hub node where we can connect/disconnect at will.
On Tue, Mar 24, 2020 at 10:54 AM Mike KB8JNM <groupio@...> wrote:
|
|
|
|
Re: Connecting more that 2 Analog_Bridges
#analog_bridge
The only thing I can see to note is that you will need 3 nodes. One for EACH AB you are showing. Each will need a unique address on the same server. Perhaps there
is more I am over looking.
On 3/24/2020 12:45 PM, davek wrote:
Would this seem like a appropriate all mode solution? Or am i over complicating this? I am not sure on the DStar
|
|
|
|
Re: Connecting more that 2 Analog_Bridges
#analog_bridge
davek
Would this seem like a appropriate all mode solution? Or am i over complicating this? I am not sure on the DStar
|
|
|
|
Re: Connecting more that 2 Analog_Bridges
#analog_bridge
davek
Exactly what i needed to know, thanks Steve
|
|
|
|
Re: Connecting more that 2 Analog_Bridges
#analog_bridge
The only way to bridge USRP across more then 2 connections is with
ASL.
toggle quoted messageShow quoted text
The other issue to consider is that you don't ALWAYS want to go analog for conversion. Consider this: DMR, NXDN, YSFn. No conversion required. All 3 are AMBE so it's a simple cross connected MMDVM single instance for 2 modes. YSFw and P25. No conversion required. All 3 ar IMBE so it's a simple cross connected MMDVM single instance for 2 modes. D-Star is stand alone. So, for example if you used 2 instances of AB to bridge DMR to NXDN you would loose quality by going to analog when it's not needed. Steve N4IRS
On 3/24/2020 11:40 AM, davek wrote:
Bridge more than one (all?) digital modes together
|
|
|
|
Re: Connecting more that 2 Analog_Bridges
#analog_bridge
davek
Bridge more than one (all?) digital modes together
|
|
|
|
Re: Connecting more that 2 Analog_Bridges
#analog_bridge
JJ Cummings
What exactly is your ultimate goal?
On Tue, Mar 24, 2020 at 8:39 AM davek <davidkierz@...> wrote: So i have a simple DMR to P25 Gateway working by piggybacking 2 instances of Analog_Bridge. I would like to add more modes, what process or component ties more than 2 Analog Bridges together?
|
|
|
|
Connecting more that 2 Analog_Bridges
#analog_bridge
davek
So i have a simple DMR to P25 Gateway working by piggybacking 2 instances of Analog_Bridge. I would like to add more modes, what process or component ties more than 2 Analog Bridges together?
|
|
|
|
Re: Working with MMDVM_Bridge and XLX
JJ Cummings
Oh, and when I start ircddbgateway up and it links to the XLX - I do get audio from ircddbgateway itself back to analog announcing the connection.. I know it has to be some trivial setting in ircddbgateway but I'm at a loss for what that setting is.
On Tue, Mar 24, 2020 at 8:24 AM JJ Cummings via Groups.Io <cummingsj=gmail.com@groups.io> wrote:
|
|
|
|
Re: Working with MMDVM_Bridge and XLX
JJ Cummings
So I managed to solve my first issue where ircddbgateway etc would not connect to XLX. Turns out that XLX is very picky about padding and I needed to add some additional padding in the ircddbgateway configuration. The issue that I have remaining is that I get one way audio (Analog to XLX) but not XLX to Analog. I have traced the issue down to ircddbgateway - where I see the voice packets come in from XLX but then ircddbgateway never passes them to MMDVM_Bridge, any thoughts from anyone?
On Fri, Mar 20, 2020 at 9:28 AM JJ Cummings via Groups.Io <cummingsj=gmail.com@groups.io> wrote:
|
|
|
|
Re: NXDN not passing thru to Dstar
Show a snip of your life when transmitting from NXDN ALL the way through to ircddbgateway.
Sent via smoke signal (AT&T)
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Kevin Halton <Khalton@...>
Sent: Monday, March 23, 2020 7:47:03 PM To: main@DVSwitch.groups.io <main@DVSwitch.groups.io> Subject: Re: [DVSwitch] NXDN not passing thru to Dstar MMDVM and DVswitch logs both show the proper headers being passed. When I keyup with NXDN radio I see my ID# and when I keyup with Dstar I see my callsign going to the correct TG.
|
|
|
|
Re: NXDN not passing thru to Dstar
Your caall sign should be passed to D-Star
toggle quoted messageShow quoted text
On 3/23/20 7:47 PM, Kevin Halton wrote:
MMDVM and DVswitch logs both show the proper headers being passed. When I keyup with NXDN radio I see my ID# and when I keyup with Dstar I see my callsign going to the correct TG.
|
|
|
|
Re: NXDN not passing thru to Dstar
Kevin Halton
MMDVM and DVswitch logs both show the proper headers being passed. When I keyup with NXDN radio I see my ID# and when I keyup with Dstar I see my callsign going to the correct TG.
|
|
|
|
Re: NXDN not passing thru to Dstar
Sorry,
toggle quoted messageShow quoted text
Wrong pointer. In MMDVM_Bridge.ini: [NXDN Id Lookup] File=/var/lib/mmdvm/NXDN.csv Time=24 Verify the userfile is current and has actual content. This is where MB looks up a user. I would also look at the ircddbgateway log when a signal is coming in from NXDN and see what the log says. I would also look at the MMDVM_Bridge log and the Analog_Bridge log. My guess is NXDN is not resolving a NXDN ID to a callsign which D-Star needs. Steve N4IRS
On 3/23/20 5:57 PM, Kevin Halton wrote:
This is what my NXDNGateway.ini looks like
|
|
|
|
Re: NXDN not passing thru to Dstar
Kevin Halton
I have one instance of Analog_Bridge.ini running. I have 3 instances of MMDVM_Bridge.ini running and 3 DVSwitch.ini running
DVSwitch.ini DVSwitch.ini.DMR DVSwitch.ini.NXDN MMDVM_Bridge.ini MMDVM_Bridge.ini.DMR MMDVM_Bridge.ini.NXDN
|
|
|
|
Re: NXDN not passing thru to Dstar
Kevin Halton
This is what my NXDNGateway.ini looks like
NXDNgateway.ini [Network]
Port=14050
HostsFile1=./NXDNHosts.txt
HostsFile2=./private/NXDNHosts.txt
ReloadTime=60
ParrotAddress=127.0.0.1
ParrotPort=42021
NXDN2DMRAddress=127.0.0.1
NXDN2DMRPort=42022 When I go to /var/lib/mmdvm I do not have NXDNHosts.txt or private_NXDNHosts.txt listed. There is a NXDN.csv only. In /opt/XDNGatewayhere is a NXDNHosts.txt and the talkgroup I am trying to access is listed.
|
|
|
|
Re: NXDN not passing thru to Dstar
In NXDNGateway.ini:
toggle quoted messageShow quoted text
[Network] HostsFile1=/var/lib/mmdvm/NXDNHosts.txt HostsFile2=/var/lib/mmdvm/private_NXDNHosts.txt Verify the hostfiles are current and have actual content. I would also look at the ircddbgateway log when a signal is coming in from NXDN and see what the log says. I would also look at the MMDVM_Bridge log and the Analog_Bridge log. My guess is NXDN is not resolving a NXDN ID to a callsign which D-Star needs. Steve N4IRS
On 3/23/2020 1:31 PM, Kevin Halton
wrote:
Yes, Everything passes fine
|
|
|
|
Re: NXDN not passing thru to Dstar
Kevin Halton
Yes, Everything passes fine
toggle quoted messageShow quoted text
On Mar 23, 2020, at 1:05 PM, Steve N4IRS <szingman@...> wrote:
|
|
|