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: Call routing cluster
Petr,
toggle quoted messageShow quoted text
Questions are no problem. We need to do a better job with the Wiki. The short answers to your example: You will start hb_confbridge.py, it will start hblink for you. hblink.py is the lowest level log the HB "stack" it handles connecting to servers and accepting connections from clients. It defines logging and table lookups for subscriber IDs etc. On it's own it does vary little BUT is is required. The first step in setting up a hblink application is to make sure hblink.py is properly configured. hb_confbridge will sub-class hblink.py Think of it as hb_confbridge calls hblink when it needs to communicate with Servers and Clients. (Don't shoot me guys) You do not define repeaters or client s that can connect to the Master (Server). You define a a "place" where the repeater can connect to. in the sample config, that is [MASTER-1] Multiple clients can connect to that Master or you can define multiple Master sections. To connect hblink to a BM master, you connect as a client. Setup the client the same way you would in MMDVMHost. Hope this helps. 73, Steve N4IRS
On 4/6/2018 4:20 AM, Petr Frank wrote:
Hi guys,
|
|
|
|
Re: Call routing cluster
Hi guys,
i've tried to play a bit and have some questions. It means dummy questions and I'd like to ask like an idiot :-)
Lets see my configuration hblink.cfg: [MASTER-1]
MODE: MASTER
ENABLED: True
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 62031
PASSPHRASE: passw0rd
GROUP_HANGTIME: 5
[REPEATER-1] MODE: CLIENT ENABLED: False EXPORT_AMBE: False IP: PORT: 54001 MASTER_IP: 92.43.29.198 MASTER_PORT: 62031 PASSPHRASE: passw0rd CALLSIGN: OK0TEST RADIO_ID: 230116 RX_FREQ: 439000000 TX_FREQ: 431000000 TX_POWER: 25 COLORCODE: 1 SLOTS: 1 LATITUDE: 38.0000 LONGITUDE: -095.0000 HEIGHT: 75 LOCATION: Anywhere, EU DESCRIPTION: This is a cool repeater URL: www.w1abc.org SOFTWARE_ID: 20170620 PACKAGE_ID: MMDVM_HBlink GROUP_HANGTIME: 5 OPTIONS: hb_confbridge_rules.py: BRIDGES = {
'WORLDWIDE': [
{'SYSTEM': 'MASTER-1', 'TS': 1, 'TGID': 1, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON', 'ON': [2,], 'OFF': [9,10]},
{'SYSTEM': 'REPEATER-1', 'TS': 1, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON', 'ON': [2,], 'OFF': [9,10]},
],
'ENGLISH': [
{'SYSTEM': 'MASTER-1', 'TS': 1, 'TGID': 13, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [3,], 'OFF': [8,10]},
{'SYSTEM': 'REPEATER-1', 'TS': 1, 'TGID': 13, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [3,], 'OFF': [8,10]},
],
'STATEWIDE': [
{'SYSTEM': 'MASTER-1', 'TS': 2, 'TGID': 3129, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [4,], 'OFF': [7,10]},
{'SYSTEM': 'REPEATER-1', 'TS': 2, 'TGID': 3129, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [4,], 'OFF': [7,10]},
],
'PRAHA': [
{'SYSTEM': 'MASTER-1', 'TS': 1, 'TGID': 111, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [5,], 'OFF': [6,10]},
{'SYSTEM': 'REPEATER-1', 'TS': 1, 'TGID': 111, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [5,], 'OFF': [6,10]},
]
}
talkgroup_ids.csv: 1,MARC Wordlwide
2,Local 2
3,MARC North America
111,Praha
talkgroup_ids.json is deleted once hb_confbridge.py starts and it returns: DEBUG 2018-04-06 09:58:41,802 Logging system started, anything from here on gets logged
INFO 2018-04-06 09:58:41,803 Routing bridges file found and bridges imported
ERROR: Conference bridges found for system not configured main configuration
Unfortunately i don't know what else i can check and modify. Sorry for dummy questions but i was unable to find-out answers in wiki. Petr, OK2ZAR.
|
|
|
|
Re: DVSwitch Status update
Yes it will. The plan is to decouple to Vocoders from Analog_Bridge
and provide a method for someone to build the Vocoder separately.
toggle quoted messageShow quoted text
On 4/5/2018 8:57 AM, Matthew 2E0SIP
wrote:
|
|
|
|
Re: DVSwitch Status update
Matthew 2E0SIP
Hi All, This is an exciting update, thanks to all for the hard work. Cheers
|
|
|
|
Re: ASL>DStar dummy repeater crashing
G7RPG - Peter Kendall
Thanks, Steve. I'll sit tight for a bit. 73 Peter
On 02/04/18 22:08, Steve N4IRS wrote:
DummyRepeater is not long for this world. We will be replacing it wit a simpler lighter solution. See my post a few weeks ago.
|
|
|
|
Re: ASL>DStar dummy repeater crashing
DummyRepeater is not long for this world. We will be replacing it
wit a simpler lighter solution. See my post a few weeks ago.
toggle quoted messageShow quoted text
Steve
On 04/02/2018 04:46 PM, G7RPG - Peter
Kendall wrote:
|
|
|
|
Re: ASL>DStar dummy repeater crashing
Steven Blackford
Hey Peter, Sounds like we need to compare notes then. :-) I've sent you an email off list. I'd be happy to try to help you get the ASL<->D-Star side working if I can. Just a quick question. Are you using an AMBEserver in the mix or are you going directly to the AMBE device with DummyRepeater? 73 de K4SQI. Steve, K4SQI
On Mon, Apr 2, 2018 at 4:46 PM, G7RPG - Peter Kendall <g7rpg@...> wrote:
--
|
|
|
|
Re: ASL>DStar dummy repeater crashing
G7RPG - Peter Kendall
Hi Steve, I'm running ASL on x68 debian on an esx vm, likewise I've got an x68 vm debian box that I've tried running dummy repeater on. I've got a couple of ambe devices NWDR Thumb DV and a DV-MEGA ambe300+carrier board makes no difference. I tried running dummy repeater and ircddbgateway on a Pi and again the same thing happens.
My ASL > DMR is rock solid! 73 Peter
On 02/04/18 21:29, Steven Blackford wrote:
|
|
|
|
Re: ASL>DStar dummy repeater crashing
Steven Blackford
Hi Peter, ASL<->D-Star is rock solid for me. It's been running currently for several weeks without a reboot or restart. When I had my node setup to bridge over to DMR, i had an issue with the DMR->ASL going to sleep until someone keyed up on ASL. Then it would start working again. On your PI are you running the new ASL software or are you running the HamVOIP software? What hardware are you using to do the transcoding? I'm currently using a PiDV, but have used an original Blue DV-Dongle & a ThumbDV as well. 73 de K4SQI! Steve, K4SQI
On Mon, Apr 2, 2018 at 4:23 PM, G7RPG - Peter Kendall <g7rpg@...> wrote: Hi I wonder if anyone who is using dummy repeater to link to allstar has --
|
|
|
|
ASL>DStar dummy repeater crashing
G7RPG - Peter Kendall
Hi I wonder if anyone who is using dummy repeater to link to allstar has
a problem where dstar > asl stops working randomly sometimes an hour sometimes a day or so. ASL > dstar is never a problem. Restarting dummy repeater fixes the problem. I've tried this on a VM and Rpi and get the same results. 73 Peter G7RPG
|
|
|
|
Re: Call routing cluster
Peter M0NWI
Petr,
I do exactly that using using bridge.py and define all the slots / TG / repeaters' in the bridge_rules.py, you can define them as always on, it user activated, UA can be made to switch on a specific transmission group or time. Have a look at bridge_rules sample, its super flexible! 73, Peter Sent from Outlook From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Petr Frank <iogroups@...>
Sent: 28 March 2018 18:49:51 To: main@DVSwitch.groups.io Subject: Re: [DVSwitch] Call routing cluster Thanks Corey. I'll test it and maybe come back with another question ;-)
|
|
|
|
Re: Call routing cluster
Thanks Corey. I'll test it and maybe come back with another question ;-)
|
|
|
|
Re: Call routing cluster
Corey Dean N3FE <n3fe@...>
I should have done my homework before responding... You can run the hb confbridge and do that. Here is the sample config. Corey N3FEhttps://github.com/n0mjs710/HBlink/blob/master/hb_confbridge_rules-SAMPLE.py
On Wed, Mar 28, 2018 at 1:27 PM, Petr Frank <iogroups@...> wrote: Hi guys,
|
|
|
|
Re: Call routing cluster
Corey Dean N3FE <n3fe@...>
I know using dmrlink you define it in the confbrdge and each connection has its own login. I haven't looked to see if there is a hb conference bridge but I am assuming it would work the same way if there is such a thing. Corey N3FE
On Wed, Mar 28, 2018 at 1:27 PM, Petr Frank <iogroups@...> wrote: Hi guys,
|
|
|
|
Call routing cluster
Hi guys,
i've test HBlink approx 3 months ago and it really worked. ;-) Fantastic work. I used modified config sample a bit during my testing. I've some questions based on my experiences. Is possible to create some clusters? It means to have group of repeaters assigned to specified talk group and when somebody talks on the TG then all assigned repeaters are transmitting but non-assigned repeaters are idle. How i can define permanent linked group(s) for each repeater? Is possible to have on-demand groups? Are DMR private calls supported? I haven't been able to establish private call via HBlink. 73 de Petr, OK2ZAR.
|
|
|
|
Re: HB_Bridge 1 to 1 relationship
Peter M0NWI
Hi Steve,
Ah, that might be my issue then, I've one configured as a Master, and another as a client to connect out to another bridge using the MMDVM protocol.
I'd wondered if I just needed one repeater setup for MMDVM and it would handle multiple clients, unlike DMRLink where we need one entry per repeater.
Any thoughts on if 2 repeaters due to the mixed modes could be made to work, or am I best to have 2 sets of files?
73, Peter
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Sent: 27 March 2018 17:04 To: main@DVSwitch.groups.io Subject: Re: [DVSwitch] HB_Bridge 1 to 1 relationship Peter,
I assume you have the HB_Bridge side configured as a Server. You should be able to connect the second MMDVM to the same IPO/Port as the first, without adding a second Server stanza. Steve On 3/27/2018 11:57 AM, Peter M0NWI wrote:
|
|
|
|
Re: HB_Bridge 1 to 1 relationship
Peter,
toggle quoted messageShow quoted text
I assume you have the HB_Bridge side configured as a Server. You should be able to connect the second MMDVM to the same IPO/Port as the first, without adding a second Server stanza. Steve
On 3/27/2018 11:57 AM, Peter M0NWI
wrote:
|
|
|
|
HB_Bridge 1 to 1 relationship
Peter M0NWI
All,
I've got a DMRLink bridge that I wanted to add an MMDVM too, so setup HBLink and confirm it worked with the MMDVM OK, then configured IPSC_Bridge, and HB_Bridge, all worked OK and using bridge rules I could pass group voice between the 2 without issue.
Today I wanted to add a second MMDVM, so edited the hblink.cfg file to add a second repeater, ran hblink.py to confirm all was OK, then started HB_Bridge, which died due to the UDP socket already being in use.
root@www:/opt/HBlink# ./HB_Bridge.py
load config file config.file Traceback (most recent call last): File "./HB_Bridge.py", line 237, in <module> systems[system] = HB_BRIDGE(system, CONFIG, logger) File "./HB_Bridge.py", line 101, in __init__ self.hb_ambe = AMBE_HB(self, _name, _config, _logger, self._ambeRxPort) File "/opt/HBlink/dmr_utils/ambe_bridge.py", line 381, in __init__ AMBE_BASE.__init__(self, _parent, _name, _config, _logger, _port) File "/opt/HBlink/dmr_utils/ambe_bridge.py", line 187, in __init__ self.udp_port = reactor.listenUDP(self._ambeRxPort, UDP_IMPORT(self.import_datagramReceived)) File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 374, in listenUDP p.startListening() File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 175, in startListening self._bindSocket() File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 195, in _bindSocket raise error.CannotListenError(self.interface, self.port, le) twisted.internet.error.CannotListenError: Couldn't listen on any:31003: [Errno 98] Address already in use. This threw me a little, and so I thought I'd re-used a port number by accident, but reading the error a little closer, so it was the 31003 port, which is what I use for pushing AMBE from HB to IPSC, but I didn't have another instance of HB_Bridge running, after some head scratching I edited my hblink.cfg file to comment out the original of the two repeater instances, and all went back to working, so both my repeater configs where OK.
Thinking a bit more, it must be that each instance will need to have it's own pair of HB to IPSC files, as otherwise the AMBE packets could all just hit the other partner from both HB repeaters at the same time, if they happen to be talking at the same time?
So the question is, do I need to setup an additional set of IPSC_Bridge and HB_Bridge files for each additional HB repeater I with to add into DMRLink, or am I missing something where there is a way for the tuple of repeater source ID, Slot, TG to be sent through along with AMBE audio to the partners and so multiple HB's can talk to multiple IPSC/DMRLink?
73, Peter
|
|
|
|
Re: DVSwitch Status update
Steven Blackford
Steve, Tnanks for the update & all the hard work by everyone involved! As you know already, over the past several months one of my big projects has been the Carolina Link and without a lot of the software you guys provide, the task would've been a lot harder to do. It's mostly streamlined now that we are taking advantage of the tanscoding system with the XLXD Reflector, but there are times I can honestly say while it works great, the DMR<->D-Star bridge solution you guys provide is 100 times more flexible. Our group had actually started to get used to this & I still think @ times would prefer if I put this solution back in place. :-) I continue to provide a bridge between AllStar and D-Star. After my presentation at both the GARA Club in Greensboro, NC and the Charlotte Hamfest this month, we've seen a lot more interest in what we're doing locally and in AllStar as well. Besides our bridge, I provide an additional AllStar node our members can use to connect to other Allstar Nodes via the Android IAXRPT app & Zoiper. Before my presentations, we maybe had 2-3 people taking advantage of this. Now we have several people using it. So, thanks again for all the hard work & 73 de K4SQI! Steve, K4SQI
On Wed, Mar 21, 2018 at 9:25 AM, Steve N4IRS <szingman@...> wrote: It has been quite a while since we posted a status update on all of the projects either in the works or deployed. The toolkit is growing and maturing. We are adding connections to more Networks and changing the method we use to connect. --
|
|
|
|
Re: HBLink Parrot Settings
DO1KBL, Kim
Its working fine! Thanks for the informations :-)
|
|
|