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: Security password on Brandmeister
Ted Lawrence
Yes, that fixed it. Thanks!
|
|
Re: Security password on Brandmeister
Yes
toggle quoted messageShow quoted text
On 11/29/20 6:14 PM, Ted Lawrence via
groups.io wrote:
To be clear. You replace "passw0rd" with the Self care password ?
|
|
Re: Security password on Brandmeister
Ted Lawrence
To be clear. You replace "passw0rd" with the Self care password ?
|
|
BransMeister Self care password for a DVSwitch
Ted Lawrence
Hi folks! I need help with DVSwitch edit. With the recent BrandMeister server security change, it broke our DVSwitch to DMR configuration. What Stanza do you insert the Self care BrandMeister password for DVSwitch. Also, what is proper format needed in the line of code?
Thanks for you help! Ted KD4EG
|
|
Re: Coming to a browser near you
Jay
Amen, I am Mac OS and IOS, with a WinDoze box around to program radios with. It will be nice to have a web client I can run on everything.
-- jb N4NQY
|
|
Re: level differences between YSF and DMR (again)
k7wby@...
You might try changing to AUDIO_USE_GAIN. My ASL side is set to .25 but yours may be different. This is one of those things that you just have to test and test until you get it right. There are also gain settings in rpt.conf that you can play with for ASL.
All my AB instances have DV3000 hardware as well as the XLX so it tends to make it a little easier to balance the audio.
|
|
level differences between YSF and DMR (again)
Patrick Perdue
Hi:
I'm sure this has been brought up before. I have a system using DVSwitch, which involves an XLX reflector. Currently, the XLX module to which DVSwitch is connected is also configured as an autolinked YSF reflector. HBlink connects to that reflector, and MMDVM_Bridge connects to HBlink, with my XLX reflector as one peer and TGIF as another. The YSF reflector on XLX is rarely used compared to DStar and especially DMR, which is the most popular digital mode on the system, but I am told that audio level is significantly higher for audio received by YSF connected clients than DMR, regardless of if the source is ASL or some other mode. I'm already running the gain from ASL to digital below unity (0.38, I think) to avoid distortion. This seems to work well for DMR even with hot analog audio. So, my question is, other than perhaps moving YSF traffic to another module on the reflector, then using an instance of Analog_Bridge to route everything destined for YSF through ASL and turning the gain down on that stage, then pointing YSF outbound traffic back to the original MMDVM_Bridge instead of a second ASL private node to avoid transcoding, since there seems to be no problem in that direction, is there anything I can do about this? I assume probably not, but I honestly haven't paid too much attention to YSF implementation of DVSwitch, since I'm not actually using it to provide YSF connectivity at the moment.
|
|
locked
Notice to all DVSwitch users.
#brandmeister
This was posted a few days ago by N3FE
Due to issues that have been happening recently, we are going to need to start requiring users to set a hotspot security password to gain access to the US Masters. If you already have a hotspot security password set on the BM portal, you can ignore this post. We are going to start requiring this on master 3101 November 30th, 3102 will follow on December 4th, and 3103 on December 11th. This is already implemented on the RU masters, and other Master servers will follow. At this time this will just be for hotspots. The API is being worked on to allow repeater owners to make this change as well, but it is not quite ready to go.
Here is a link to a post on how to set your hotspot security on the bm portal. Please configure a personalized security password for your hotspots !
What does this mean for DVSwitch users? If you have a bridge or server connecting to BrandMeister, you will need to have set your HS password. Up till now, a user could use the default password and connect to BM. With the above change, you will need to set your own password. This is one password per CallSign/DMRID. If you have 2 DMR IDs you will need to set 2 passwords.
We HIGHLY suggest you set your HS passwords now. That way when the changes are applied across BM, you will not loose connectivity.
|
|
Re: Adding P25 to existing YSF and DMR bridge
Gary,
toggle quoted messageShow quoted text
Think of it this way. What modes do you need? MB can do each of the modes, once. You have a YSF <-> DMR You want to do P25 <-> DMR A P25 to DMR Bridge is one instance of MB and 2 instances of AB (the transcoder) In you YSF <-> DMR bridge, you cross connected the TLV ports. In you P25 <-> DMR bridge that cross connect needs to go through a transcoder. Think if it as 2 networks. P25 <-> AB and DMR <-> AB This is a single instance of MB and 2 instances of AB. Now, connect the 2 AB together at the USRP ports. You have a transcoder.
On 11/28/20 6:43 AM, Gary, KE8O wrote:
OK, I think I have my head wrapped around the AB side but I'm not sure on the number of MB instances. Below is how I currently have my /opt folder setup.
|
|
Re: Adding P25 to existing YSF and DMR bridge
Gary, KE8O
OK, I think I have my head wrapped around the AB side but I'm not sure on the number of MB instances. Below is how I currently have my /opt folder setup.
According to Steve's response and the port flow I need two AB instances for the DMR<--> P25 and one MB instance. Is that one MB instance my existing YSF/DMR instance or in addition ?
|
|
Re: Nextion screen install
#mmdvm_bridge
toggle quoted messageShow quoted text
On 11/28/20 5:16 AM, Glenn VK4NGA via
groups.io wrote:
Hi all,
|
|
Nextion screen install
#mmdvm_bridge
Hi all,
I'm new to the group. I did search this but didn't find all the information. I've installed a Nextion screen to my DVswitch server, an RPi 3B+ and have the hardware side of things correct. I'm new to Linux and I just need guidance, more so a "how to" install the Nextion driver and any other detail. Cheers Glenn Vk4nga
|
|
Re: Security password on Brandmeister
Steve - WB8GRS
Thanks Patrick, works great!
Steve_WB8GRS
|
|
Re: Adding P25 to existing YSF and DMR bridge
Gary, KE8O
Thanks Tony and Steve for the information. I will give this a try later tonight.
|
|
Re: Adding P25 to existing YSF and DMR bridge
Close.
toggle quoted messageShow quoted text
A DMR <-> P25 bridge would be one instance of MB and 2 instances of AB. DMR Network <-> MB <-> AB_DMR <-> AB_P25 <-> MB <-> P25Gateway <-> P25 Reflector. Here is the port map <https://dvswitch.groups.io/g/main/wiki/9379> Steve N4IRS
On 11/27/20 12:54 AM, Tony Langdon wrote:
On 27/11/20 4:03 pm, Gary, KE8O wrote:I currently have a test system where I have bridged YSF and DMR usingYou would need a second instance of MMDVM-Bridge, which is sitting on
|
|
Re: Adding P25 to existing YSF and DMR bridge
On 27/11/20 4:03 pm, Gary, KE8O wrote:
I currently have a test system where I have bridged YSF and DMR usingYou would need a second instance of MMDVM-Bridge, which is sitting on the same DMR TG as the original bridge. The way I see it is: DMR - MMDVM-Bridge - Analog_Bridge (1) - Analog_Bridge (2) - MMDVM_Bridge - P25Gateway - P25 Reflector. Analog_Bridge (1) would be configured to use the md380-emulator for DMR AMBE encoding, while Analog_Bridge (2) needs to use the software IMBE vocoder from op25. Of course, hardware vocoders can be used instead of the software options I've given, but the software vocoders are excellent for DMR and P25. So at the end of the day, you're running 3 instances of MMDVM_Bridge (including the existing DMR - YSF instance), plus 2 instances of Analog_Bridge. -- 73 de Tony VK3JED/VK3IRL http://vkradio.com
|
|
Adding P25 to existing YSF and DMR bridge
Gary, KE8O
I currently have a test system where I have bridged YSF and DMR using MMDVM_Bridge. I have the P25Reflector installed on the same system running as a standalone reflector. I would like to add P25 to the existing YSF / DMR bridge. I searched the existing message and found a discussion on bridging P25 to DMR that involved using Analog_Bridge. I'm just not sure on how to add a third mode into the mix. Any guidance would be appreciated.
|
|
Re: Towards open-source infrastructure for DMR repost from OpenDV
Skyler Fennell
Nvm, guess I haven’t played with hamvoip for a while to test that stuff lol. I can’t think of a reason why it would be better for the community of experimenters to not release the source code, but certainly respect it’s the authors work and not a requirement to release it.
On Thu, Nov 26, 2020 at 8:09 PM Steve N4IRS <szingman@...> wrote:
|
|
Re: Towards open-source infrastructure for DMR repost from OpenDV
It does not need to be compiled for Arch. The binary will run fine.
toggle quoted messageShow quoted text
On 11/26/20 10:08 PM, Skyler Fennell
wrote:
|
|
Re: Towards open-source infrastructure for DMR repost from OpenDV
Skyler Fennell
I'm guessing one reason is if you open source it HamVoip can then compile it for arch
On Thu, Nov 26, 2020 at 6:17 PM Steve N4IRS <szingman@...> wrote:
|
|