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).
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) WHEREAS47 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.
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
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
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
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
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
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
The only way to bridge USRP across more then 2 connections is with ASL.
The other issue to consider is that you don't ALWAYS want to go analog for conversion. Consider this:
DMR, NXDN,
The only way to bridge USRP across more then 2 connections is with ASL.
The other issue to consider is that you don't ALWAYS want to go analog for conversion. Consider this:
DMR, NXDN,
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?
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?
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
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
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
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
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.
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.
Sorry,
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
Sorry,
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
In NXDNGateway.ini:
[Network]
HostsFile1=/var/lib/mmdvm/NXDNHosts.txt
HostsFile2=/var/lib/mmdvm/private_NXDNHosts.txt
Verify the hostfiles are current and have actual content.
In NXDNGateway.ini:
[Network]
HostsFile1=/var/lib/mmdvm/NXDNHosts.txt
HostsFile2=/var/lib/mmdvm/private_NXDNHosts.txt
Verify the hostfiles are current and have actual content.
