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: ASL to DMR Bridge...changing talkgroups
I don't know if you were directing this to me Mike/KB8JNM or not Your message is to the dvswitch main group @ goups.io --- Ports do not have to be 'any certain port number' except: to not conflict with any port number in use & to match the port number where it is handshaking TO or FROM. If you look at the HOW2, there is a nice graphic showing the
digital flow of ports for dmr to asl.
I use (analog_bridge.ini) fromDMRPort = 31100
It must match the port number it interfaces with in dvswitch.ini TXPort = 31100 ; Port to send AMBE TLV frames to
(export)
The port number you use are up to you. But they must match where they are going to or coming from without conflict. All modes/formats would be they same. ...mike/kb8jnm
On 11/13/2018 12:14 AM, Gregory
Heinrichs wrote:
hi Mike, i just wanted to confirm that the port 31000 is in reference to fromDMRPort, so i should change the script to 31100 correct? Below is from my ini.
|
|
|
|
Re: ASL to DMR Bridge...changing talkgroups
Gregory Heinrichs
hi Mike, i just wanted to confirm that the port 31000 is in reference to fromDMRPort, so i should change the script to 31100 correct? Below is from my ini.
[AMBE_AUDIO] server = 127.0.0.1 fromDMRPort = 31100 toDMRPort = 31103 . . .
|
|
|
|
Re: ASL to DMR Bridge...changing talkgroups
Gregory Heinrichs
hi Mike, i just wanted to confirm that the port 31000 is in reference to fromDMRPort, so i should change the script to 31100 correct? Below is from my ini.
[AMBE_AUDIO] server = 127.0.0.1 fromDMRPort = 31100 toDMRPort = 31103 . . .
|
|
|
|
Re: Bridging a P25Reflector and a YSFReflector?
Thanks for the replies. I'll give MMDVM_Bridge a go and see if I can get it working with my setup. I'll checkout MMDVM_CM too. Thanks Mike
On Sat, Nov 10, 2018 at 9:33 AM Steve N4IRS <szingman@...> wrote:
|
|
|
|
Re: DMR -> P25 issue
Andy,
toggle quoted messageShow quoted text
Thanks for the clarification. Steve N4IRS
On 11/11/18 5:38 AM,
andrew144500@... wrote:
So,
|
|
|
|
Re: DMR -> P25 issue
andrew (callsign)
So,
here is a little more information about what is/was going on. On October 4 a change to MMDVMHost was pushed to github. The change effected P25. https://github.com/g4klx/MMDVMHost/commit/85bc8357aa1967d692901addd6ebefd89a8f32f6 When Andy at Pi-Star updated the binaries for Pi-Star, he rolled in the changes. Those changes broke P25 RF. When the problem was reported to Pi-Star, Andy reverted to a older version of MMDVMHost. Here is his announcement: https://forum.pistar.uk/viewtopic.php?f=23&p=4003&sid=ffb1861eab2e15bd078550a906388b6b#p4003 If you are running Pi-Star, updating should fix the issue. If you compile your own MMDVMHost, revert to the above commit. A little more, more information... Actually, we never reverted back to the older version. We rewrote the broken P25 part of MMDVM host and pushed that out through the pistar updates, then offered the changes up to MMDVM and made Jon aware of the problem. 😀 Regards A.
|
|
|
|
Re: Bridging a P25Reflector and a YSFReflector?
That is intended to be used on a hotspot or repeater.
For reflector to reflector, MMDVM_Bridge will do that quite simply. No transcode required.
Steve N4IRS
Sent via smoke signal (AT&T)
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Alec-N1AJW <alec.wasserman@...>
Sent: Saturday, November 10, 2018 10:27:07 AM To: main@DVSwitch.groups.io Subject: Re: [DVSwitch] Bridging a P25Reflector and a YSFReflector? there's a ysf wide to p25 bridge made by Andy iin Chile. Juribeparada. I have never tried that one. https://github.com/juribeparada/MMDVM_CM
|
|
|
|
Re: Bridging a P25Reflector and a YSFReflector?
there's a ysf wide to p25 bridge made by Andy iin Chile. Juribeparada. I have never tried that one. https://github.com/juribeparada/MMDVM_CM
|
|
|
|
Re: DMR -> P25 issue
So,
here is a little more information about what is/was going on. On October 4 a change to MMDVMHost was pushed to github. The change effected P25. https://github.com/g4klx/MMDVMHost/commit/85bc8357aa1967d692901addd6ebefd89a8f32f6 When Andy at Pi-Star updated the binaries for Pi-Star, he rolled in the changes. Those changes broke P25 RF. When the problem was reported to Pi-Star, Andy reverted to a older version of MMDVMHost. Here is his announcement: https://forum.pistar.uk/viewtopic.php?f=23&p=4003&sid=ffb1861eab2e15bd078550a906388b6b#p4003 If you are running Pi-Star, updating should fix the issue. If you compile your own MMDVMHost, revert to the above commit. 73, Steve N4IRS
|
|
|
|
Re: DMR -> P25 issue
va3czk@...
FYI.
This issue is resolved now after last night Pi Star update. 73' va3czk
|
|
|
|
Re: DMR -> P25 issue
David Griffith NZ6D
Sorry guys. Didn't look at the recipient's... Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message -------- From: "David Griffith NZ6D via Groups.Io" <nz6d@...> Date: 11/9/18 7:48 PM (GMT-07:00) To: main@DVSwitch.groups.io Subject: Re: [DVSwitch] DMR -> P25 issue PS.. I am in Albuquerque New Mexico now so I don't really have access. Helping my Dad.... Sent from my Verizon, Samsung Galaxy smartphone -------- Original message -------- From: va3czk@... Date: 11/9/18 10:06 AM (GMT-07:00) To: main@DVSwitch.groups.io Subject: [DVSwitch] DMR -> P25 issue Not sure what have changed but since yesterday DMR ↔ P25 on our bridge is acting up. P25 -> DMR works well, however DMR ->25 is not getting through the digital squelch on the radio. When I manually open the squelch/monitor I can hear everything fine. (P25 to P25 on same TG is working fine) The bridge has been working seamlessly ever since it was set up several months ago. Thanks Jerry va3czk
|
|
|
|
Re: DMR -> P25 issue
David Griffith NZ6D
PS.. I am in Albuquerque New Mexico now so I don't really have access. Helping my Dad.... Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message -------- From: va3czk@... Date: 11/9/18 10:06 AM (GMT-07:00) To: main@DVSwitch.groups.io Subject: [DVSwitch] DMR -> P25 issue Not sure what have changed but since yesterday DMR ↔ P25 on our bridge is acting up. P25 -> DMR works well, however DMR ->25 is not getting through the digital squelch on the radio. When I manually open the squelch/monitor I can hear everything fine. (P25 to P25 on same TG is working fine) The bridge has been working seamlessly ever since it was set up several months ago. Thanks Jerry va3czk
|
|
|
|
Re: DMR -> P25 issue
David Griffith NZ6D
Hi Jerry. Yes we have had some same issues. Nothing changed In our config and it just stopped working. We are looking at the logs and configs. Did you find d anything? Dave NZ6D Sent from my Verizon, Samsung Galaxy smartphone
-------- Original message -------- From: va3czk@... Date: 11/9/18 10:06 AM (GMT-07:00) To: main@DVSwitch.groups.io Subject: [DVSwitch] DMR -> P25 issue Not sure what have changed but since yesterday DMR ↔ P25 on our bridge is acting up. P25 -> DMR works well, however DMR ->25 is not getting through the digital squelch on the radio. When I manually open the squelch/monitor I can hear everything fine. (P25 to P25 on same TG is working fine) The bridge has been working seamlessly ever since it was set up several months ago. Thanks Jerry va3czk
|
|
|
|
DMR -> P25 issue
va3czk@...
Does anyone else experiencing an issue with the transcoding from P25 to DMR ?
Not sure what have changed but since yesterday DMR ↔ P25 on our bridge is acting up. P25 -> DMR works well, however DMR ->25 is not getting through the digital squelch on the radio. When I manually open the squelch/monitor I can hear everything fine. (P25 to P25 on same TG is working fine) The bridge has been working seamlessly ever since it was set up several months ago. Thanks Jerry va3czk
|
|
|
|
Re: Why does not it show alias id in Europe in the HBlink Master?
EA5GVK Joaquin
Ok. Manuel THX. Crear work Corts
|
|
|
|
Re: hb_confbridge.py error after call ends...
Cort N0MJS <n0mjs@...>
Probably your hb_confbridge_rules.py file - if you send it to me, the actual file, not copy and paste, I’ll take a look.
Cort Buffington 785-865-7206
|
|
|
|
hb_confbridge.py error after call ends...
After call end with confbridge I get an error:
INFO 2018-11-09 13:56:54,659 (OLL-DMRMaster) *CALL END* STREAM ID: 2660614738 SUB: DL1BZ (2629315) PEER: 262931502 (262931502) TGID 7 (7), TS 2, Duration: 4.86109900475 Unhandled Error Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/twisted/python/log.py", line 86, in callWithContext return context.call({ILogContext: newCtx}, func, *args, **kw) File "/usr/local/lib/python2.7/dist-packages/twisted/python/context.py", line 122, in callWithContext return self.currentContext().callWithContext(ctx, func, *args, **kw) File "/usr/local/lib/python2.7/dist-packages/twisted/python/context.py", line 85, in callWithContext return func(*args,**kw) File "/usr/local/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 614, in _doReadOrWrite why = selectable.doRead() --- <exception caught here> --- File "/usr/local/lib/python2.7/dist-packages/twisted/internet/udp.py", line 249, in doRead self.protocol.datagramReceived(data, addr) File "/srv/HBlink/hblink.py", line 322, in master_datagramReceived self.dmrd_received(_peer_id, _rf_src, _dst_id, _seq, _slot, _call_type, _frame_type, _dtype_vseq, _stream_id, _data) File "/srv/HBlink/hb_confbridge.py", line 383, in dmrd_received if (_dst_id in _system['ON'] or _dst_id in _system['RESET']) and _slot == _system['TS']: exceptions.KeyError: 'RESET' INFO 2018-11-09 13:56:54,669 (OLL-DMRMaster) *CALL END* STREAM ID: 2660614738 SUB: DL1BZ (2629315) PEER: 262931502 (262931502) TGID 7 (7), TS 2, Duration: 4.8713619709 Unhandled Error Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/twisted/python/log.py", line 86, in callWithContext return context.call({ILogContext: newCtx}, func, *args, **kw) File "/usr/local/lib/python2.7/dist-packages/twisted/python/context.py", line 122, in callWithContext return self.currentContext().callWithContext(ctx, func, *args, **kw) File "/usr/local/lib/python2.7/dist-packages/twisted/python/context.py", line 85, in callWithContext return func(*args,**kw) File "/usr/local/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 614, in _doReadOrWrite why = selectable.doRead() --- <exception caught here> --- File "/usr/local/lib/python2.7/dist-packages/twisted/internet/udp.py", line 249, in doRead self.protocol.datagramReceived(data, addr) File "/srv/HBlink/hblink.py", line 322, in master_datagramReceived self.dmrd_received(_peer_id, _rf_src, _dst_id, _seq, _slot, _call_type, _frame_type, _dtype_vseq, _stream_id, _data) File "/srv/HBlink/hb_confbridge.py", line 383, in dmrd_received if (_dst_id in _system['ON'] or _dst_id in _system['RESET']) and _slot == _system['TS']: exceptions.KeyError: 'RESET' DEBUG 2018-11-09 13:56:55,135 Periodic reporting loop started 73 Heiko, DL1BZ
|
|
|
|
Bridging a P25Reflector and a YSFReflector?
I have a working P25Reflector and a YSFReflector. I would like to bridge the two together so if someone is connected to the P25Reflector they could talk to someone connected to the YSFReflector. Which DVSwitch program would be best for this? MMDVM_Bridge? I read through the Wiki, and searched the messages, but I'm drawing a blank.
Thanks Mike
|
|
|
|
Re: HBlink / HB_Bridge - "Loose Validation" (Enables connections to XLD, DMR+, etc)
that may be true but how to you direct it to the specific xlxreflector and module. its located on the same machine as xblink. i want the audio to be bridged with audio already on myhblink.cfg
|
|
|
|
Re: OpenBridge Support Nearing Completion
Peter M0NWI
Sounds great, I'll have a word with our DMR+ (IPSC2) provider, thanks for all your hard work!
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 08 November 2018 16:37 To: HBlink@DVSwitch.groups.io; DVSwitch@groups.io Subject: [DVSwitch] OpenBridge Support Nearing Completion Folks,
Excuse the cross-post, but this is kinda big news. Several of us have been running the OpenBridge branch of HBlink for a couple of weeks and it is close to being merged into the main branch. OpenBridge is a way to, essentially, trunk many call streams at the same time between HBlink, Brandmeister, DMR+ and DMR-MARC. Brandmeister has indicated willingness to provide OpenBridge connections to network operators using HBlink – in fact, it was the BM team who suggested we add support for it and they would happily allow those connections (they don’t like us using HBP connections for downstream network traffic). I do not yet know whether DMR+ or DMR-MARC will be willing to provide the same, but the technical capabilities are now available for an independent network operator to take “trunk” type feeds from all of the major networks, without masquerading as repeaters. Anyone looking to get upstream feeds OpenBridge feeds from the “big networks” must work those arrangements out with those network operators, and I strongly discourage chaining OB to OB to OB to avoid those upstream connections. The best way to use OB is between your independent network and a direct connection to one of the International networks, and direct connections between your network and other regional operators. Passing national/international network traffic between multiple independent regional networks is likely to cause performance problems sooner or later. 0x49 DE N0MJS Cort Buffington 785-865-7206
|
|
|