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.
|
Welcome to the *official* place to go for discussion/support for DMRlink and HBlink?
I had to seed this somehow.
Steve N4IRS |
|
|
|
Re: Welcome to the *official* place to go for discussion/support for DMRlink and HBlink?
N3FE <n3fe@...>
It is working here! Sent from my iPhone On May 24, 2017, at 9:48 AM, Steve N4IRS <szingman@...> wrote:
|
|
|
|
Re: Welcome to the *official* place to go for discussion/support for DMRlink and HBlink?
Cort <n0mjs@...>
Anyone mind if I list this group as the *official* place to go for discussion/support for DMRlink and HBlink?
Cort Buffington 785-865-7206
|
|
|
|
Re: Welcome to the *official* place to go for discussion/support for DMRlink and HBlink?
Matthew Pitts N8OHU
Working here as well, and a good choice of sites to host the list.
Matthew N8OHU On May 24, 2017 9:48:06 AM EDT, Steve N4IRS <szingman@...> wrote: I had to seed this somehow. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
|
|
DMRmonitor
I have started to play with DMRmonitor. I think it may be a good way to display real time or near real time data from DMRlink, HBlink and maybe "other" programs.
Steve |
|
|
|
Re: Welcome to the *official* place to go for discussion/support for DMRlink and HBlink?
Works for me.I have changed the topic and will update the main page. Now all I have to do is learn how to use this thing.
|
|
|
|
Re: DMRmonitor
Cort <n0mjs@...>
Yeah… Like most things I do, I design by building and modifying. I don’t usually sit down and work out the details, then implement. I implement on the fly. The biggest thing will be the opcodes used between *link and DMRmonitor… at some point, need to standardize a set that can inform DMRmonitor what kinds of tables to build/populate, etc. Well, that and the fact that I know NO javascript…. Some things for the group that I feel really strongly about and hope to keep everyone on board with: Continue using a python-based web server for it — maybe a different, more robust module — but I just hate making folks have to run apache, or nginx behind it… and an sql server, etc. I’d like to keep this so folks only have to know how to run one program to make it work. The other is I *REALLY* want to keep it web socket based and avoid trying to support a gaggle of persistent http hacks (i.e. long polling). Why? I’ll explain by example: At the day job, we implemented IPv6 with full feature set parity back in 2003 (no shit)… because it’s the right thing to do, and someone needs to push forward instead of keep using a “it’ll-get-us-by” hack. Goals for DMRmonitor on the IPSC side include using the same messages sent as log messages to update fields in the main DMRlink table in real-time about transmissions, etc…. and also to use RCM messages to show what each repeater is actually reporting that it’s doing — not just lighting it up red b/c it *should* be transmitting (a la c-Bridge). There are some really important reasons for this — I’ll give one example. If you’re talking on a repeater and key up during BSID, you get bonked. If you’re talking away and when you let up the repeater sends a BSID, the channel is blocked. But the very nature of a call router isn’t going to “back block” that call through the entire network… So, you let up, the repeater goes into BSID, confbridge.py sends the other guy’s transmission back to you, consisting only of a short transmission like “See you at breakfast” and you never hear it. Then you say… well, the network is broken. There’s packet loss… something’s wrong…. I’d really like to get RCM in the mix because a repeater WILL REPORT if and why it blocks a call. I am pretty sure I’ve had COUNTLESS reports of problems for situations like this over the years - and sometimes actually gone chasing a problem that didn’t exist.
Cort Buffington 785-865-7206
|
|
|
|
Re: DMRmonitor
I'm starting to get my first look at the output of rcm.py I have to update my confbridge to support DMRmonitor. Here is a snip:
Call Monitor - Repeater State
TIME: 2017-05-24 11:16:11
DATA SOURCE: 911249, 911249
TS1 State: Idle
TS2 State: Idle
Call Monitor - Repeater State
TIME: 2017-05-24 11:17:51
DATA SOURCE: 911249, 911249
TS1 State: Repeating
TS2 State: Idle
Call Monitor - Call Status
TIME: 2017-05-24 11:17:51
DATA SOURCE: 911249, 911249
IPSC: IRSC
IPSC Source: 1911249, 1911249
Timeslot: 1
Status: Active
Type: Group Voice
Source Sub: 3134499, W2SWX
Target Sub: TGID: 3, North America
|
|
|
|
DMRlink, HBlink DVSwitch test / demo configuration.
Corey, N3FE and I are are talking about setting up a multi-site test environment to "play" with the features of the different applications and modules. The environment will be 2 sites connected via a DMRlink trunk. We plan to include both IPSC and HBR networks (c-bridge and BM) and repeaters (Motorola and MMDVM) We will bridge one TG to ASL just to be complete. I'm going to try to use DMRmonitor for display. Let's see how many things we can break at once.
|
|
|
|
Re: DMRlink, HBlink DVSwitch test / demo configuration.
Matthew Pitts N8OHU
Have to see if I can get at least my D-STAR side linked up tonight and help break things. But, who gets to keep the pieces?
toggle quoted message
Show quoted text
Matthew N8OHU On May 24, 2017 11:40:19 AM EDT, Steve N4IRS <szingman@...> wrote: Corey, N3FE and I are are talking about setting up a multi-site test environment to "play" with the features of the different applications and modules. The environment will be 2 sites connected via a DMRlink trunk. We plan to include both IPSC and HBR networks (c-bridge and BM) and repeaters (Motorola and MMDVM) We will bridge one TG to ASL just to be complete. I'm going to try to use DMRmonitor for display. Let's see how many things we can break at once. |
|
|
|
Re: DMRmonitor
Cort <n0mjs@...>
That file is a hot mess.... but it'll demonstrate what RCM is about. Note you need to set RCM True and 3rd party console app to True In the config to get full info from repeaters Sent from my iPhone On May 24, 2017, at 10:21 AM, Steve N4IRS <szingman@...> wrote:
|
|
|
|
Re: DMRlink, HBlink DVSwitch test / demo configuration.
If you break it, you get all the pieces. ;) Would that be "5 easy
pieces" ?
toggle quoted message
Show quoted text
On 05/24/2017 12:11 PM, Matthew Pitts
via Groups.Io wrote:
Have to see if I can get at least my D-STAR side linked up tonight and help break things. But, who gets to keep the pieces? |
|
|
|
HBlink configuration
Matthew Pitts N8OHU
Steve and Cort,
I'm trying to configure this so I can create an HB Master for bridging AllStar into DMR for Ohio Section ARES (one talkgroup for MMDVM repeaters in each ARES District in the Section, plus one Statewide one) and I'm not quite sure how to proceed. I think I know how to get the first Repeater linked, as that's going to be my system here that is running Jonathan's DMRGateway, but beyond that I'm slightly lost. Any helpful hints for me? Matthew N8OHU |
|
|
|
Re: HBlink configuration
Matthew,
in hblink.cfg [MASTER-1]
MODE: MASTER
ENABLED: True
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 62031
PASSPHRASE: passw0rd
GROUP_HANGTIME: 5 I changed the port and passphrase to match BM. You should be able to run python hblink.py Once it is running point your MMDVMHost at the IP of the machine running hblink.py. Steve |
|
|
|
DMR ID's for ASL
David KE6UPI
Does anyone know how to register a new DMR ID so when someone uses the ASL side. The name would show ASL XXXX? That way we know is a ASL user. Any thoughts? -- Thanks, David "Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one." Thomas Jefferson |
|
|
|
Re: DMR ID's for ASL
Dave,
As of now, ambe_audio uses a fixed DMR ID that all analog traffic appears to be coming from. Mike and I talked about the possibility that Analog_bridge could determine the ASL node actually transmitting. Something like, the analog traffic is coming from ASL node 2150. A lookup in the ASL node list points to N4IRS as the node call sign. A lookup in the subscriber_ids.csv would return 3112138. The Metadata could be synthesized so that the traffic is coming from 3112138 rather then a fixed DMR ID. This all take time. The updatenodelist script that creates the ASL node list COULD create a second node list containing associated DMR IDs so that a single lookup by Analog_bridge would be required. |
|
|
|
Wiki
I have started TRYING to add a format and content to the Wiki. It's early and I hope to add some commented samples. All of what I've done so far I directly copied content out of the programs and readme. If nothing else, the wiki will orginize the information.
|
|
|
|
DMRlink, HBlink DVSwitch test / demo configuration.
As part of testing and moving towards a permanent Demo / Test system, I am Feeding BM 3100 (RX Only) to ASL node 2600 and EchoLink 399058 (N4IRS-L) ASL node 2600 will be the permanent analog connection. I have yet to determine exactly what will be connected.
Mike is working hard towards releasing Analog_bridge, HB_bridge and IPSC_bridge for the weekend. Steve N4IRS AllStar Dashboard at http://stn2600.dvswitch.org/allmon/link.php?nodes=1998,1999,2600 -- "What are HB_bridge, IPSC_bridge and Analog_bridge?" |
|
|
|
Re: DMRmonitor
Might be a hot mess, I have DMRmonitor running.
http://stn2600.dvswitch.org:8080/ |
|
|
|
Re: DMRmonitor
Cort <n0mjs@...>
I started work on a real-time RCM-based table today. Imagine even seeing when repeaters are IDing! Sent from my iPhone On May 26, 2017, at 2:29 PM, Steve N4IRS <szingman@...> wrote:
|
|
|