Welcome to DVSwitch
Purpose
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
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: Setup of a Bridge YSF to DMR - Anyone out there who can solve this mystery ?
#mmdvm_bridge
KC1JFN
I did some experiment, since the bridge and the YSF reflector are on the same LAN. I change the GatewayAddress=to the local ip address of the YSF Reflector server, which is also on the same network with the YSF to DMR Bridge.
KC1JFN
|
|
Re: Need help please have issues with connecting to 1999
Vince Pimentel
OH! I think you gents nailed it! Yes, I was on a substantial sized network and yes there were two other nodes that had 1999 running that I know of. Also DVSwitch bridges I believe. I'm still on that network but those nodes are no longer connected.
I'll give that a go but would put money on it that you're right. Huge thank you!
|
|
Re: Need help please have issues with connecting to 1999
Valid point. Need to test and come up with a unique private or number.
Sent by smoke signal (AT&T)
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Mike KB8JNM <groupio@...>
Sent: Friday, January 29, 2021 5:12:25 PM To: main@DVSwitch.groups.io <main@DVSwitch.groups.io> Subject: Re: [DVSwitch] Need help please have issues with connecting to 1999 Could it be that a node you were connected to or a node connected to you also had a 1999 private node ? If so, it will not allow you to connect as long as one is present in the 'connected network'. Suggest using a odd number like 1325. everyone seems to use 1999 for there first private node. Something to look for next time.
On 1/29/2021 5:02 PM, Vince Pimentel wrote:
|
|
Re: Need help please have issues with connecting to 1999
Could it be that a node you were connected to or a node connected to you also had a 1999 private node ? If so, it will not allow you to connect as long as one is present in the 'connected network'. Suggest using a odd number like 1325. everyone seems to use 1999
for there first private node. Something to look for next time.
On 1/29/2021 5:02 PM, Vince Pimentel
wrote:
|
|
Re: Need help please have issues with connecting to 1999
Vince Pimentel
Yep, looks good. [radio-secure] exten => ${NODE},1,rpt,${NODE} exten => ${NODE1},1,rpt,${NODE1} startup_macro = *31999 /var/log/asterisk/messages.1:[Jan 28 18:51:19] NOTICE[480] app_rpt.c: Normal Repeater Init 1999 /var/log/asterisk/messages.1:[Jan 28 20:01:16] NOTICE[480] app_rpt.c: Normal Repeater Init 1999
/var/log/asterisk/messages.1:[Jan 29 02:30:16] NOTICE[481] app_rpt.c: Normal Repeater Init 1999
Welp, I just tried to connect to it again to see if I could get anything to show in the logs that would easier to find and it worked. Disconnected and reconnected like 5 times with success. No file changes, reboots or anything like that.
Thanks for the replies and help but it's a mystery still. Will see if I can learn anything more if it happens again. Any further thoughts or things to check/confirm are welcome but with it working. We won't be able to confirm that it was a fix.
|
|
Re: Need help please have issues with connecting to 1999
Check for:
toggle quoted messageShow quoted text
[radio-secure] exten => ${NODE1},1,rpt,${NODE1} In extensions.conf
On 1/29/2021 3:52 PM, Vince Pimentel
wrote:
Copy that, and that is also present. Sorry, didn't even think about that. #doh
|
|
Re: Need help please have issues with connecting to 1999
Vince Pimentel
Copy that, and that is also present. Sorry, didn't even think about that. #doh
1999 = radio@....0.1:4569/1999,NONE ; and iax port number if not the default
|
|
Re: Need help please have issues with connecting to 1999
You need to have 1999 in your nodes stanza or rpt.conf
toggle quoted messageShow quoted text
Search rpt.conf for "[nodes] Add: 1999 = radio@....0.1:4569/1999,NONE ; assuming you are using 4569 as your IAX port.
On 1/29/2021 2:57 PM, Vince Pimentel
wrote:
Greetings,
|
|
Re: Need help please have issues with connecting to 1999
Greetings,
I'm having a similar issue and found this thread via search, since the OP didn't come back figured I'd continue the thread. My issue only occurs if I need to drop 1999 for some reason and then try to reconnect to it. My extensions.conf have a line for 1999 in the globals stanza [globals] NODE1 = 1999; This is a private node [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 $
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 f$ ; except when an ID needs to be done and there is a signal comin$
telemdefault = 0 ; 0 = telemetry output off. Don't send Allison to DMR !!!!!!!!!!$
telemdynamic = 0 ; 0 = disallow users to change the local telemetry setting with $
linktolink = no ; disables forcing physical half-duplex operation of main repeat$ ; 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 18$
idrecording = |ie ; id recording or morse string see http://ohnosec.org/drupal/nod$ idtalkover = |ie ; Talkover ID (optional) default is none see http://ohnosec.org/$
|
|
Re: Allstar <--> DMR & DVSWITCH Was working...
#brandmeister
#mmdvm_bridge
#analog_bridge
On 1/29/2021 11:28 AM, Peter Buckley
via groups.io wrote:
I had a working DVSWITCH Allstar <--> DMR/BrandMeister Gateway. Only using Allstar to DMR Gateway to Brandmeister....
|
|
Re: Allstar <--> DMR & DVSWITCH Was working...
#brandmeister
#mmdvm_bridge
#analog_bridge
The ID is your DMRID + the SSID that identifies the hot spot that
you are logging into BM as.
toggle quoted messageShow quoted text
The password is the HotSpot password you setup. Steve N4IRS
On 1/29/2021 11:28 AM, Peter Buckley
via groups.io wrote:
I had a working DVSWITCH Allstar <--> DMR/BrandMeister Gateway. Only using Allstar to DMR Gateway to Brandmeister....
|
|
Allstar <--> DMR & DVSWITCH Was working...
#brandmeister
#mmdvm_bridge
#analog_bridge
Peter Buckley
I had a working DVSWITCH Allstar <--> DMR/BrandMeister Gateway. Only using Allstar to DMR Gateway to Brandmeister....
I believe my configuration (error?) has to do with how MMDVM_Bridge.ini is trying to connect to BrandMeister TG 31085 (since confirmed the Allstar side & node working OK) From MMDVM_Bridge.ini [General] Callsign=N0ECT Id=110824502 (question should this just be 1108245 ) Timeout=180 Duplex=0 ModeHang=0 RFModeHang=0 NetModeHang=0 Display=None Daemon=0 [DMR Network] Enable=0 Address=127.0.0.1 Port=62031 Jitter=360 Local=62032 Password=passw0rd (question should this be my BM Talk Group new password I created at BrandMeister) Slot1=1 Slot2=1 ModeHang=0 Debug=0 Any HINTS? Configuration TIPs greatly appreciated. 73s N0ECT
|
|
Addressing D-STAR reflectors via dvswitch.sh
I have a (mostly) working ASL to DVSwitch working. I have discovered an
issue that I can't resolve with DTMF handling. As I normally drive the system from the commandline, I can work around that issue by calling dvswitch.sh directly, which works perfectly. However, when I use asterisk -rx "rpt fun $SRCNODE $CMD" to link to the TG I want, I sometimes get "3199" appended to the TG. I have no idea where that 3199 is coming from. My AllStar ($SRCNODE) node is 2199. For example, when connecting to P25 TG 10400, DVSwitch attempts to connect to 104003199. This appears to happen within AllStar (any AllStar gurus here?). However, if I directly call "dvswitch.sh tune <tg>" from the same script, I am linked to the correct talkgroup. At this point in time, this is of no consequence, because I have changed the script that I run to call dvswitch.sh directly. However, if I change to directly using DTMF (or calling Asterisk to make the change), then I will have an issue. But even that's not certain, because I may process DTMF via a different route. The other thing I'm wanting to know is how to link to D-STAR reflectors using dvswitch.sh. I haven't yet worked out how to do that. Any ideas? For reference, here's the relevant section of my rpt.conf Under the [functions] stanza ; DVSwitch mode commands sent via DTMF 00 = cmd, /opt/MMDVM_Bridge/dvswitch.sh ; unused 01 = cmd, /opt/MMDVM_Bridge/dvswitch.sh ; unused 02 = cmd, /opt/MMDVM_Bridge/dvswitch.sh ; unused 03 = cmd, /opt/MMDVM_Bridge/dvswitch.sh tune unlink ; Unlink from last TG / reflector 04 = cmd, /opt/MMDVM_Bridge/dvswitch.sh mode DMR 05 = cmd, /opt/MMDVM_Bridge/dvswitch.sh mode DSTAR 06 = cmd, /opt/MMDVM_Bridge/dvswitch.sh mode YSF 07 = cmd, /opt/MMDVM_Bridge/dvswitch.sh mode P25 08 = cmd, /opt/MMDVM_Bridge/dvswitch.sh mode NXDN ; connect to TG/REF on current DV mode 09=autopatchup,context=tgtune,dialtime=90000,farenddisconnect=1,noct,quiet=1 ; end of DVSwitch commands And in extensions.conf, I have: [tgtune] exten = _X.,1,noop ; Wait,1 exten = _X.,n,System(/opt/MMDVM_Bridge/dvswitch.sh mute TLV) exten = _X.,n,Playback(connecting) exten = _X.,n,SayDigits(${EXTEN}) exten = _X.,n,System(/opt/MMDVM_Bridge/dvswitch.sh tune ${EXTEN}) exten = _X.,n,System(/opt/MMDVM_Bridge/dvswitch.sh mute OFF) exten = _X.,n,Hangup And the node does speak the extra "3199", suggesting that ${EXTEN} contains these extra digits. Odd thing is my first attempt today via AllStar worked perfectly, but subsequent attempts had the extra "3199". -- 73 de Tony VK3JED/VK3IRL http://vkradio.com
|
|
Re: Autobahn Python
Steve Siesel [K4KSA]
Thank you!
From: main@DVSwitch.groups.io [mailto:main@DVSwitch.groups.io] On Behalf Of Steve N4IRS
Sent: Thursday, January 28, 2021 9:55 PM To: main@DVSwitch.groups.io Subject: Re: [DVSwitch] Autobahn Python
What address is it listening on? I think this be best asked in the HB subgroup. On 1/28/21 9:52 PM, Steve Siesel [K4KSA] wrote:
|
|
Re: Autobahn Python
What address is it listening on? I think this be best asked in the
HB subgroup.
toggle quoted messageShow quoted text
On 1/28/21 9:52 PM, Steve Siesel
[K4KSA] wrote:
|
|
Re: Autobahn Python
Well, If memory serves, HBmonitor uses it.
toggle quoted messageShow quoted text
On 1/28/21 9:49 PM, Steve Siesel
[K4KSA] wrote:
|
|
Re: Autobahn Python
Steve Siesel [K4KSA]
Is this a security issue? Should I be worried about this?
From: main@DVSwitch.groups.io [mailto:main@DVSwitch.groups.io] On Behalf Of Steve N4IRS
Sent: Thursday, January 28, 2021 9:49 PM To: main@DVSwitch.groups.io Subject: Re: [DVSwitch] Autobahn Python
No it does not. HBlink installed? HBMonitor? On 1/28/21 9:44 PM, Steve Siesel [K4KSA] wrote:
|
|
Re: Autobahn Python
Steve Siesel [K4KSA]
Yes…
From: main@DVSwitch.groups.io [mailto:main@DVSwitch.groups.io] On Behalf Of Steve N4IRS
Sent: Thursday, January 28, 2021 9:49 PM To: main@DVSwitch.groups.io Subject: Re: [DVSwitch] Autobahn Python
No it does not. HBlink installed? HBMonitor? On 1/28/21 9:44 PM, Steve Siesel [K4KSA] wrote:
|
|
Re: Autobahn Python
No it does not. HBlink installed? HBMonitor?
toggle quoted messageShow quoted text
On 1/28/21 9:44 PM, Steve Siesel
[K4KSA] wrote:
|
|
Autobahn Python
Steve Siesel [K4KSA]
When installing DVswitch server, does it install Autobahn Python? I seem to have it running and providing a web socket on port 9000.
Thanks, Steve
|
|