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: Using all digital modes
You will need another ASL node. But you should be clear on
terminology, an ASL server can host multiple nodes. So, yes, you
will need (want) another node, but you wont need another server.
toggle quoted messageShow quoted text
Hope that helps. Steve
On 10/23/2018 3:10 PM, AA4II wrote:
I'm sorry if this has been covered already. I have set up my DMR bridge and all is well. I would like to try to bridge D-Star and C4FM into my ASL node too. I was wondering if I could do this on the node I just set up or if I would need to create another ASL node for each of them?
|
|
|
|
Using all digital modes
K4VL
I'm sorry if this has been covered already. I have set up my DMR bridge and all is well. I would like to try to bridge D-Star and C4FM into my ASL node too. I was wondering if I could do this on the node I just set up or if I would need to create another ASL node for each of them?
|
|
|
|
locked
Re: Blocking users from a network and common sense.
That is a shame to see that. I hope it was a glitch. After all, that is what this stuff is all about. Un-fragmenting our networks.
toggle quoted messageShow quoted text
Chris
On Oct 23, 2018, at 10:50 AM, Steve N4IRS <szingman@msgstor.com> wrote:
|
|
|
|
locked
Blocking users from a network and common sense.
There has been some traffic lately about bridging modes to established Masters (Servers) and Talk Groups. Simply put, DO NOT just drop a bridge on any TG without checking first. I can understand wanting to listen to a active TG on some mode with your ASL node. I've done it for testing dozens of times. The key word here is LISTEN. Make sure there is no way you are transmitting into a active TG. Do not just drop a bridge from ANY mode to a TG without "permission" from the primary user or managing authority. When I'm testing a connection to BM DMR I use my DMRID (3112138) as the TG number. I can then be assured the only person I will bother is me. If you don't use a little simple common sense, it's a good bet you will receive a bunch of ugly e-mail and possible be banned from TG, server or network. THINK! Remember, DVSwitch has but a number of servers for testing. See the stickey on this sub group for login info.
While I'm on the subject of banning, There is a group that has started up a new "Network" That network is TGIF. They are using software from DVSwitch including HBlink to create the new network. I applaud the choice of SW. The interesting thing is I had been monitoring the new network on their Master tgif.network. My primary interest is to listen for problems and see if the problem could be solved withing the DVSwitch SW. I did not really care to talk there. I do not want ANYTHING to do with the politics of why they decided to build their own network. My interest is that I felt it was a good test of the SW in a real world environment. Well, long story longer, my IP address has been blocked by tgif.network. All I had connected was a single HotSpot running Pi-Star. Some time last weekend the HS could no longer connect. I could not bring up the status page on my browser. I figured they were making changes, it is a new network after all and change is to be expected. On Monday I decided to ask others if they were having a problem connecting to tgif.network. The answer I got back was no problem. After testing from a different IP address I surmised my IP was blocked. Again, I do not want to get into the politics of the new network. I can understand blocking a user that caused problems or a user that did nothing but "bad mouth" a network. I don't think just listening to a TG on a Server applies here. I guarantee, the people running tgif.network know how to reach me if there was something wrong with my node. Since I provided the P25 to DMR bridge for them and they knew how to reach me if there was a problem. Steve N4IRS
|
|
|
|
hb_parrot and hb_confbridge
Started playing with the pieces here to put together our own little network cluster with bridges to the outside world.
Got hb_confbridge working fine to our current BM cluster TG. Can not get parrot to work with hb_confbridge. Stand alone it works OK. Searching through old posts saw mention of a problem with this. Am I trying to make something work that won't? BTW, this is the HB_Bridge branch.
|
|
|
|
Parrot and master - bridging using hb_confbridge
Rob MW0CQU
Hi All, Moving forward with just enough knowledge to be dangerous. On the test bench I now have a working master server with a repeater that attaches, listening on 54000 I also now have a working parrot-master which - if I bind it to 54000, it echoes everything on the repeater. The last link in the chain is (If I understand the process correctly?) Is to confbridge the two masters together ?
and this is where I'm coming unstuck.
In MASTER hblink.cfg I have one master (MASTER-1) bound to 54000 and one peer PARROT in PARROT hblink.cfg (different folder) I have one master bound to 54001 I try to bridge these in hb_confbridge.py with the following bridge statement BRIDGES = { 'PARROT': [ {'SYSTEM': 'MASTER-1', 'TS': 2, 'TGID': 2, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON', 'ON': [2,], 'OFF': [9,10], 'RESET': []}, {'SYSTEM': 'PARROT', 'TS': 2, 'TGID': 2, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON', 'ON': [2,], 'OFF': [9,10], 'RESET': []}, ] } When I run Im getting an authentication failure for parrot on master
Ive checked the passphrase on both (infact I copy/pasted between the two shell windows to make sure there were no typos
I've fixed the logging config bug where both tried to bind to 4321
but this last config of the two hblink.cfg files is not gelling in my brain
My goal for this stage is to simply get TG2, Slot 2 as a parrot with TG 1 on slot 1 as a standard talkthrough
1) Is my approach correct please ?
2) Obviously I need:
a MASTER-1 stanza in the MASTER hblink.conf
a PARROT Master in the PARROT hblink.conf
but do I need to define , in each hblink.cfg, a reciprocal peer please ?
Im looking for the high level description of what peer/master/client definitions should go where - I can figure out the minutae as
long as I'm barking up the right tree.
MTIA & 73
Rob
|
|
|
|
Re: [Newbie!] Mute Parrot ?
Rob MW0CQU
Thanks for the reply Cort.
consider this thread closed due to finger trouble. I've recloned from the github and now have a working master, and a separate working parrot Still having an issue which I think I ought to start a separate thread on rather than take this thread off topic
73 ' de Rob
|
|
|
|
locked
Re: Zello interface will NOT happen.
Corey Dean N3FE <n3fe@...>
As a follow up to this. The US BM masters owners just talked about this and Zello is NOT to be used on a US BM master . This is the first and last warning anyone will receive and will be added to the BM wiki in the very near future! Corey N3FE
On Sat, Oct 20, 2018 at 11:08 AM Steve N4IRS <szingman@...> wrote:
|
|
|
|
locked
Zello interface will NOT happen.
I want to be very clear on this:
We are NOT interested in working on a interface to Zello. Not now, not ever. Please stop asking for it here. I will delete any thread on this subject. I will moderate anyone bringing it up. For DVSwitch Steve N4IRS
|
|
|
|
Re: Analog_Bridge Ignore TX
Dylan KI7SBI
Calls do come in from other talkers, and audio is outputting to the soundcard. The "Ignore TX" issue is not a blocker for me, although I'm still curious.
I did need Steve's advised latency timer fix for the DV3000 usb. echo 1 > /sys/bus/usb-serial/devices/ttyUSB0/latency_timer I: 2018-10-20 00:00:08.287 Begin TX: src=3153775 rpt=13153679 dst=8951 slot=2 cc=1 I: 2018-10-20 00:00:26.306 Begin TX: src=3153775 rpt=13153679 dst=310 slot=2 cc=1 I: 2018-10-20 00:00:40.567 Begin TX: src=3144026 rpt=13153679 dst=310 slot=2 cc=1 I: 2018-10-20 00:00:47.779 Begin TX: src=3153775 rpt=13153679 dst=310 slot=2 cc=1 I: 2018-10-20 00:00:55.027 Begin TX: src=3101849 rpt=13153679 dst=310 slot=2 cc=1 I: 2018-10-20 00:01:00.428 Begin TX: src=1139941 rpt=13153679 dst=310 slot=2 cc=1 KI7SBI
|
|
|
|
Analog_Bridge Ignore TX
Dylan KI7SBI
Anyone experienced this Ignore TX condition with Analog_Bridge before?
I: 2018-10-19 21:43:01.111 Begin TX: src=3153682 rpt=13153679 dst=9 slot=2 cc=1 I: 2018-10-19 21:43:01.611 Ignore TX: src=3153682 rpt=13153679 dst=9 slot=2 cc=1 (2) I: 2018-10-19 21:43:02.111 Ignore TX: src=3153682 rpt=13153679 dst=9 slot=2 cc=1 (2) I: 2018-10-19 21:43:02.611 Ignore TX: src=3153682 rpt=13153679 dst=9 slot=2 cc=1 (2) Analog_Bridge <=> HB_Bridge client1 <=> HB_Bridge master HT <=> pistar connects to the same <=> HB_Bridge master Above, is Analog_Bridge output of a call from the HT. The rpt id is the pistar hotspot. The src id is the HT. I've attempted changing the pistar's id, without success. Thanks. KI7SBI
|
|
|
|
Re: IPSC Peers not Registering with each other
Cort N0MJS <n0mjs@...>
It would have been handy to have included full debug log traces from both peers and the master if you want someone to try and figure out what’s going on. Common reasons for registration problems include two peers who have the same registration IP address (ie behind the same NAT), two peers trying to use the same radio ID… I can think of several other things that would tend to mess things up, but you’ve not included remotely adequate debug log output to look for them.
First off, thanks for reading it. I renamed it DO_NOT_README in the hopes people would actually read it if I said not to. Trying to get folks to read it before asking for help turned out to not work at all :) :) They both reach out to each other. Each peer has to register with each other…. you registering with me doesn’t mean I registered with you. We both have to actively register with each other. IPSC is very straightforward in this way.
Both peers have the same radio ID, both peers coming from the same IP address. Port conflicts. The master will drop them if it doesn’t seen master keep-alive requests for a matter of time. Watch the debug logs to see if the peers are still sending master keep alives and the master to see if it’s receiving them.
NO. If you manually had to configure every peer in the IPSC, there’d be no need for the master. That’s its only special role -- to maintain a list of registered peers to allow new systems to bootstrap – that’s what the peer list is all about. You can glean most of that from the MOTOTRBO system planner, BTW._._,_._,_ -- Cort Buffington H: +1-785-813-1501 M: +1-785-865-7206
|
|
|
|
IPSC Peers not Registering with each other
Michael Eckhoff (K5MRE)
I'm attempting to add a second IPSC peer to an existing peer group and finding that when the two peers attempt to register with each other, it's not working. In addition, after a while, they drop their connection to the master as well. On one peer, I get the following in the logs: INFO 2018-10-15 22:25:17,060 (MASTER) Registering with the Master: x.x.x.x:64835
WARNING 2018-10-15 22:25:17,702 (MASTER) Registration response (we requested reg) from the Master: 1315835, x.x.x.x:64835 (1 peers)
INFO 2018-10-15 22:25:22,064 (MASTER), No Peer List - Requesting One From the Master
INFO 2018-10-15 22:25:24,171 (MASTER) Peer List Received from Master: 2 peers in this IPSC
INFO 2018-10-15 22:25:27,063 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:32,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:37,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:42,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
INFO 2018-10-15 22:25:47,065 (MASTER) Registering with Peer 315835, 165.231.210.13:50000
And on the other peer, there's no registration attempt after it gets the alert that there's an additional peer from the master. I can see in the debug logs that both peers are getting a new peer list and that each of the peers is on it. It's just that the one peer never tries to do the registration with the other, but the second peer does. From the DO_NOT_README file, it makes it clear that all peers try to register with each other, and that process is part of the reason as to how the pinholes get setup in the NATs/FWs. But if one of the peers doesn't try, then the pinholes never get setup, which is I assume why the peer that is trying to register isn't actually able to do it. 1. Why wouldn't one of the two peers be attempting to reach out to the other, but one does? Is there some kind of election by highest/lowest ID or something that dictates who goes first or should they both always blinding just reach out to each other? 2. Why does the master drop the connection to both peers because the two peers can't talk to each other? I would expect the master to stay connected and the peers just end up being islands. Note: I don't see anything in the logs when the master does this, however, I can see on the C-Bridge that they've been disconnected. 3. I only have a configuration for the MASTER. I have no configuration setup for PEERS, as it appears to be getting that info from the master. Do I need a peer configuration? I've tried this with both the branches and get the same result - and it's always the same peer that tries to reach out to the other. Thanks!
|
|
|
|
Re: Newbie Problem
K4VL
Success I just talked to a friend in England. He was on DMR and I was on an analog handheld. Thanks for everything you guys do making this successful
On Thu, Oct 18, 2018 at 8:07 AM Steve N4IRS <szingman@...> wrote:
|
|
|
|
Re: Newbie Problem
K4VL
OK thanks for the howto. I just went through it and made changes to reflect the howto. Unfortunately I just ordered a DMR radio and can't test it out my self. I will have to wait for some of my friends to get home from work. Thanks and 73 AA4II Allstar 47424 (Not bridge) DMR tlkgrp 310286
On Thu, Oct 18, 2018 at 8:07 AM Steve N4IRS <szingman@...> wrote:
|
|
|
|
Re: Why no working 2 instancies different MMDVM_Bridge in one machine?
EA5GVK Joaquin
Many thx. always grateful
toggle quoted messageShow quoted text
On Thu, Oct 18, 2018 at 05:47 AM, Steve N4IRS wrote:
Glad to hear it is fixed. We will leave Zello to someone else to implement.
|
|
|
|
Re: Newbie Problem
Meinke, Rich
The telemetry should be off. Its is set when you are setting up the Private node (Node 1999, in the example documents)
[1999] rxchannel = USRP/127.0.0.1:34001:32001 ; Use the USRP channel driver. Must be enabled in modules.conf ; 127.0.0.1 = IP of the target application ; 34001 = UDP port the target application is listening on ; 32001 = UDP port ASL is listening on duplex = 0 ; 0 = Half duplex with no telemetry tones or hang time. Ah, but Allison STILL talks! hangtime = 0 ; squelch tail hang time 0 althangtime = 0 ; longer squelch tail hang time 0 holdofftelem = 1 ; Hold off all telemetry when signal is present on receiver or from connected nodes ; except when an ID needs to be done and there is a signal coming from a connected node. telemdefault = 0 ; 0 = telemetry output off. Don't send Allison to DMR !!!!!!!!!!!!!!!!! Trust me. telemdynamic = 0 ; 0 = disallow users to change the local telemetry setting with a COP command, linktolink = no ; disables forcing physical half-duplex operation of main repeater while ; still keeping half-duplex semantics (optional) nounkeyct = 1 ; Set to a 1 to eliminate courtesy tones and associated delays. totime = 180000 ; transmit time-out time (in ms) (optional, default 3 minutes 180000 ms) idrecording = |ie ; id recording or morse string see http://ohnosec.org/drupal/node/87 idtalkover = |ie ; Talkover ID (optional) default is none see http://ohnosec.org/drupal/node/129
|
|
|
|
Re: Newbie Problem
Russell is correct. You should use this as your template
<https://dvswitch.groups.io/g/allstarlink/wiki/home>
toggle quoted messageShow quoted text
The howto document is pointed to in <https://dvswitch.groups.io/g/allstarlink/topic/first_draft_of_asl_dmr/21794260?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,21794260> Steve N4IRS
On 10/18/2018 9:04 AM, Russell, KV4S
wrote:
|
|
|
|
Re: Newbie Problem
you may need to turn off your node telemetry, I had some issues with this as well. I'll see if i can find the guide i got... i think i got it from this group.
On Wed, Oct 17, 2018 at 10:33 AM AA4II <aa4ii@...> wrote:
|
|
|
|
Re: Why no working 2 instancies different MMDVM_Bridge in one machine?
Glad to hear it is fixed. We will leave Zello to someone else to
implement.
toggle quoted messageShow quoted text
Steve N4IRS
On 10/18/2018 8:45 AM, EA5GVK Joaquin
wrote:
PERFECT. MANY THX. WORKING PERFECTLY TWO INSTANCES MMDVM_BRIDGE.
|
|
|