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.
And I can tell you from experience, having done it on four different bridges, that it doesn't do anything at all if idrecording and idtalkover aren't defined.
I originally used your
And I can tell you from experience, having done it on four different bridges, that it doesn't do anything at all if idrecording and idtalkover aren't defined.
I originally used your
No, it definitely won't even try to send an ID if that line is commented out, so there's really no point in having it there in the first place on a USRP bridge.
No, it definitely won't even try to send an ID if that line is commented out, so there's really no point in having it there in the first place on a USRP bridge.
Make sure the lines starting with idrecording and idtalkover are either commented out or don't exist in /etc/asterisk/rpt.conf under the stanza for the node where your DMR bridge lives. You
Make sure the lines starting with idrecording and idtalkover are either commented out or don't exist in /etc/asterisk/rpt.conf under the stanza for the node where your DMR bridge lives. You
totime = 180000 ; transmit time-out time (in ms) (default 3 min 180000 ms)
idrecording = |ie ; id recording or morse string
idtalkover = |ie ; Talkover ID (optional) default is none
It's going to
totime = 180000 ; transmit time-out time (in ms) (default 3 min 180000 ms)
idrecording = |ie ; id recording or morse string
idtalkover = |ie ; Talkover ID (optional) default is none
It's going to
I finally got the DVswitch up and running. The Analog to dmr link is working fine.
The only issue I have, is every 10 minutes, this ID is played ONLY on the DMR TG (Not the analog side)
Anyone know
I finally got the DVswitch up and running. The Analog to dmr link is working fine.
The only issue I have, is every 10 minutes, this ID is played ONLY on the DMR TG (Not the analog side)
Anyone know
Hi,
I have noticed that when restarting services via the "dvs" menu “Restart DVSwitch Services” or using the “Drop Dynamic TGs” in the DVSM App, the DMR server always returns to a particular
Hi,
I have noticed that when restarting services via the "dvs" menu “Restart DVSwitch Services” or using the “Drop Dynamic TGs” in the DVSM App, the DMR server always returns to a particular