Home Messages Hashtags Subgroups Wiki

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).

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.

Between

and

Re: confbridge.py and TG Bridge state change fun

Mike Zingman - N4IRR

#505

You are probably right. The bridge needs to synthesize the end event from the incoming data when it sees the end of stream signal. I will add a fix for this.

Mike

Re: confbridge.py and TG Bridge state change fun

JJ Cummings

#504

Corey,

I appreciate the response, but I do not believe that the confbridge_rules have anything to do with this issue... it's a matter of the triggering event not happening across the IPSC_Bridge and HB_Bridge connection.

Re: confbridge.py and TG Bridge state change fun

Corey Dean N3FE <n3fe@...>

#503

Here is what mine looks like and works if you want a reference...

    'BMUSA': [
            {'SYSTEM': '3102',          'TS': 2, 'TGID': 3160, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [3160,], 'OFF': [10], 'RESET': []},
            {'SYSTEM': 'TEST',         'TS': 1, 'TGID': 3160, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'ON', 'ON': [3160,], 'OFF': [4000], 'RESET': []},
            {'SYSTEM': 'MASTER',    'TS': 1, 'TGID': 3160, 'ACTIVE': True, 'TIMEOUT': 10, 'TO_TYPE': 'ON', 'ON': [3160,], 'OFF': [4000], 'RESET': []}
        ],

Corey N3FE

Virus-free. www.avast.com

Show quoted text

On Wed, Nov 8, 2017 at 4:30 PM, JJ Cummings <cummingsj@...> wrote:

I have been playing with DMRLink and HBLink (using IPSC_Bridge and HB_Bridge branches) and have a system up and running that looks like follows:

<HB Repeaters><--> [HB_Bridge] <--> [IPSC_Bridge] <--> [confbridge.py] <--> <CBridge>

This setup is working very well, confbridge.py is of course used to define what TGs are allowed to bridge between the HB and IPSC sides. Today I decided to try and add some Timeout type bridges and have not had any luck. Below is an example bridge group:

BRIDGES = {

'BM-COLORADO': [

{'SYSTEM': 'IPSC_MASTER', 'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []},

{'SYSTEM': 'IPSC_BRIDGE_PEER', 'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON', 'ON': [3108,], 'OFF': [], 'RESET': []}

]

}

In the above, IPSC_MASTER is the Master that the CBridge connects to and IPSC_BRIDGE_PEER is the peer that connects into the Master listening on the IPSC_BRIDGE instance. So when a call is initiated on the HB side of the house it will come through the IPSC_Bridge and end up at the IPSC_BRIDGE_PEER.

Having said all of this I have debugged the problem back to a triggering event issue, and I don't know if I have misconfigured something or if it's just a thing that needs to be added. The CONNECT action for a Bridge triggers when a GROUP VOICE END event occurs (Line 372 in confbridge.py) and when a call initiates from HB -> IPSC there is only a GROUP VOICE START event (and the same is true for IPSC -> HB incidentally)..

Example: (when calling from HB -> IPSC)
Debug from confbridge.py
INFO 2017-11-08 14:20:39,635 (IPSC_BRIDGE_PEER) GROUP VOICE START: CallID: 144 PEER: 54324, SUB: 3108853, TS: 2, TGID: 3108

Debug from HB_Bridge

INFO 2017-11-08 14:20:39,606 Voice Transmission Start on TS 2 and TG BM_COLORADO (3108) from N0PKT

INFO 2017-11-08 14:20:53,457 Voice Transmission End 13.84 seconds loss rate: 0.43% (230/231)

So as you can see from the above the triggering event never actually makes it over to the IPSC side, I'm gonna continue stepping back through the code to see if I can't find what/when/where, but I thought that someone may have a simple answer for me...

Re: confbridge.py and TG Bridge state change fun

JJ Cummings

#502

You will see in the log that I posted a different TS than the one listed in the Bridges config, this is simply because I grabbed a log from a different transmission, the problem is still present regardless of TS...

Show quoted text

On Wed, Nov 8, 2017 at 2:30 PM, JJ Cummings <cummingsj@...> wrote:

I have been playing with DMRLink and HBLink (using IPSC_Bridge and HB_Bridge branches) and have a system up and running that looks like follows:

<HB Repeaters><--> [HB_Bridge] <--> [IPSC_Bridge] <--> [confbridge.py] <--> <CBridge>

This setup is working very well, confbridge.py is of course used to define what TGs are allowed to bridge between the HB and IPSC sides. Today I decided to try and add some Timeout type bridges and have not had any luck. Below is an example bridge group:

BRIDGES = {

'BM-COLORADO': [

{'SYSTEM': 'IPSC_MASTER', 'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []},

{'SYSTEM': 'IPSC_BRIDGE_PEER', 'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON', 'ON': [3108,], 'OFF': [], 'RESET': []}

]

}

In the above, IPSC_MASTER is the Master that the CBridge connects to and IPSC_BRIDGE_PEER is the peer that connects into the Master listening on the IPSC_BRIDGE instance. So when a call is initiated on the HB side of the house it will come through the IPSC_Bridge and end up at the IPSC_BRIDGE_PEER.

Having said all of this I have debugged the problem back to a triggering event issue, and I don't know if I have misconfigured something or if it's just a thing that needs to be added. The CONNECT action for a Bridge triggers when a GROUP VOICE END event occurs (Line 372 in confbridge.py) and when a call initiates from HB -> IPSC there is only a GROUP VOICE START event (and the same is true for IPSC -> HB incidentally)..

Example: (when calling from HB -> IPSC)
Debug from confbridge.py
INFO 2017-11-08 14:20:39,635 (IPSC_BRIDGE_PEER) GROUP VOICE START: CallID: 144 PEER: 54324, SUB: 3108853, TS: 2, TGID: 3108

Debug from HB_Bridge

INFO 2017-11-08 14:20:39,606 Voice Transmission Start on TS 2 and TG BM_COLORADO (3108) from N0PKT

INFO 2017-11-08 14:20:53,457 Voice Transmission End 13.84 seconds loss rate: 0.43% (230/231)

So as you can see from the above the triggering event never actually makes it over to the IPSC side, I'm gonna continue stepping back through the code to see if I can't find what/when/where, but I thought that someone may have a simple answer for me...

confbridge.py and TG Bridge state change fun

JJ Cummings

#501

I have been playing with DMRLink and HBLink (using IPSC_Bridge and HB_Bridge branches) and have a system up and running that looks like follows:

<HB Repeaters><--> [HB_Bridge] <--> [IPSC_Bridge] <--> [confbridge.py] <--> <CBridge>

This setup is working very well, confbridge.py is of course used to define what TGs are allowed to bridge between the HB and IPSC sides. Today I decided to try and add some Timeout type bridges and have not had any luck. Below is an example bridge group:

BRIDGES = {

'BM-COLORADO': [

{'SYSTEM': 'IPSC_MASTER', 'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []},

{'SYSTEM': 'IPSC_BRIDGE_PEER', 'TS': 1, 'TGID': 3108, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON', 'ON': [3108,], 'OFF': [], 'RESET': []}

]

}

In the above, IPSC_MASTER is the Master that the CBridge connects to and IPSC_BRIDGE_PEER is the peer that connects into the Master listening on the IPSC_BRIDGE instance. So when a call is initiated on the HB side of the house it will come through the IPSC_Bridge and end up at the IPSC_BRIDGE_PEER.

Having said all of this I have debugged the problem back to a triggering event issue, and I don't know if I have misconfigured something or if it's just a thing that needs to be added. The CONNECT action for a Bridge triggers when a GROUP VOICE END event occurs (Line 372 in confbridge.py) and when a call initiates from HB -> IPSC there is only a GROUP VOICE START event (and the same is true for IPSC -> HB incidentally)..

Example: (when calling from HB -> IPSC)
Debug from confbridge.py
INFO 2017-11-08 14:20:39,635 (IPSC_BRIDGE_PEER) GROUP VOICE START: CallID: 144 PEER: 54324, SUB: 3108853, TS: 2, TGID: 3108

Debug from HB_Bridge

INFO 2017-11-08 14:20:39,606 Voice Transmission Start on TS 2 and TG BM_COLORADO (3108) from N0PKT

INFO 2017-11-08 14:20:53,457 Voice Transmission End 13.84 seconds loss rate: 0.43% (230/231)

So as you can see from the above the triggering event never actually makes it over to the IPSC side, I'm gonna continue stepping back through the code to see if I can't find what/when/where, but I thought that someone may have a simple answer for me...

Re: DV4MINI or OPENSPOT CONVERT PROTOCOL WITH HB MMDVM OR HBLINK

Steve N4IRS

#500

As of today, nothing released. I have not seen anybody else working on such a program.

73, Steve N4IRS

Show quoted text

On 11/04/2017 06:23 AM, ea5gvk@... wrote:

Is there any software to convert the dv4mini protocol and openspot to the HB mmdvm protocol?
As for example if it exists for repeaters Hytera to HB repeater or DMRGateway thanks to OE8VIK / HB3YZE

DV4MINI or OPENSPOT CONVERT PROTOCOL WITH HB MMDVM OR HBLINK

EA5GVK Joaquin

#499

Is there any software to convert the dv4mini protocol and openspot to the HB mmdvm protocol?
As for example if it exists for repeaters Hytera to HB repeater or DMRGateway thanks to OE8VIK / HB3YZE

AllStar/DMR/D-Star Bridge

Steven Blackford

#498

Hello all,

A few weeks ago, with the assistance of Steve, N4IRS I was able to setup a DMR<->D-Star bridge using DummyRepeater, Analog_Bridge, & HB_Bridge. This has been running perfectly on an ODroid C1 for the past couple of weeks. Last night, I finally had time to patch the dahdi-linux-complete module to compile ODroid. I'm running Ubuntu Xenial btw. So I had to patch it be able to compile it w/ gcc-5.x. NP. I then compiled the latest asterisk-1.4.23-pre. The secret to getting asterisk-1.4.23-pre to compile on Xenial w/ gcc-5.x is to add "-fgnu89-inline" to your CFLAGS in case you're curious. So I got everything installed. I setup my node as a hub & configured EchoLink as well. I stopped Analog_Bridge, DummyRepeater, & HB_Bridge, started up asterisk, and then restarted everything else. Here's my problem & I know it probably has something to do w/ the chan_usrp configuration. As it stands, here's what I have in my rpt.conf:

[1999] ; Change this to your assigned node numb

rxchannel = USRP/127.0.0.1:34001:32001 ; Use the USRP channel driver. Must be e

nabled in modules.conf

In Analog_Bridge, I have the following config:

; Information for USRP channel driver

; This matches the rpt.conf ASL file with a setting like:

; rxchannel = usrp/127.0.0.1:34001:32001 It's invoked as usrp/SendToIP:SendToP

ORT:ListenOnPORT

[USRP]

server = 127.0.0.1 ; IP address of Allstar/Asterisk

toASLPort = 34001 ; PCM to ASL

fromASLPort = 32001 ; PCM from ASL

and my Dummy Repeater conf for USRP is as follows:

USRP_IP=127.0.0.1

USRP_TXPORT=34001

USRP_RXPORT=32001

Since I started asterisk first & everything afterwards as expected, here's the problem I have:

DMR passes fine over to D-Star as expected.

D-Star no longer passes over to DMR at all.

When I connect to the echolink node:

D-Star<->EchoLink works perfectly both ways.

DMR<->EchoLink nothing works. If I swap the ports in Analog_Bridge,

DMR-->EchoLink works like it should, but not vice versa.

So my question is, what's the best way to configure my USRP channels so I can have audio pass between all three modes? Do I need to setup a second node for EchoLink & connect them together? I don't have any plans on adding in anything analog at the momemt. Basically just wanting to allow others to connect to the AllStar node & via EchoLink. Sorry, I'm really new at this & was happy I got this far. :-) Thanks & 73 de K4SQI!

Steve, K4SQI

-----
Steve, kb7sqi@...

Re: Current status DMRlink, HBlink DVSwitch

david bencini ik5xmk

#497

Hi Steve and all,

I do not know the python language, I tried but I really need some help. Can anyone address me to modify HBLink's code so that you can skip that part where XLX returns incorrect information? I understand that it is not the right way and it would serve a proper analysis. But Luc does not answer because he is busy with the job and I just want to understand if it is possible to establish a simple connection between my dmrmaster and a XLX module to enable transcoding. If this works and makes sense, then it may be important to plan ahead with further steps. Thanks to everyone, every idea is well-received.

David IK5XMK

Re: Analog_Bridge update

Steve N4IRS

#496

There are 3 Analog_Bridge executables in the repository. One for the Pi, one for the Intel 32 bit and one for the Intel 64 bit.
I usually recommend people rename the proper program. What processor is your Ubuntu built for?

Show the output of uname -a

73, Steve N4IRS

Show quoted text

On 10/20/2017 06:37 PM, Ryan Collier wrote:

I must be doing something wrong on the Analog_bridge. This is what I get when I try and exec on ubuntu.

root@zipper:~/Analog_Bridge# ./Analog_Bridge
-bash: ./Analog_Bridge: cannot execute binary file: Exec format error
root@zipper:~/Analog_Bridge#

Re: Analog_Bridge update

Ryan Collier

#495

I must be doing something wrong on the Analog_bridge. This is what I get when I try and exec on ubuntu.

root@zipper:~/Analog_Bridge# ./Analog_Bridge
-bash: ./Analog_Bridge: cannot execute binary file: Exec format error
root@zipper:~/Analog_Bridge#

Re: Status update and welcome.

Steve N4IRS

#494

Mid October and not much change. I updated Analog_Bridge in the repository to exchange metadata with a Partner. This is mostly used with DummyRepeater to try to translate D-Star callsign data to CC7 data for DMR.

We are up to 108 members of the forum. If you are new or have not done it yet, PLEASE add you first name and callsign to your groups.io account. It makes it so much nicer when we know who everybody is.

73, Steve N4IRS

Re: Current status DMRlink, HBlink DVSwitch

Steve N4IRS

#493

I really should change this topic name...
No reply from Luc. I see there are 10 pending Pull requests, so I don't think this is going anywhere.

Steve

Re: Analog_Bridge update

Steven Blackford

#492

Steve,

Thanks for the update! It's working perfectly here! :-) 73 de K4SQI!

Steve, K4SQI

Show quoted text

On Wed, Oct 18, 2017 at 11:30 AM, Steve N4IRS <szingman@...> wrote:

There is still more work to do, but I have updated the github repository for Analog_Bridge to include DMRID <---> Callsign translation. This will ATTEMPT to show the proper DMRID for a callsign from DummyRepeater. In the other direction the TS/TG/ID is shown in the D-Star info field. This may get other changes later. See the Analog_Bridge.ini and get-subscriber-id.sh in the scripts directory.

Support for the DVMEGA AMBE 3000 still has to be added as well as refactoring. Software means never having to say you're finished. (apologies to Erich Segal)

73, Steve N4IRS

-----
Steve, kb7sqi@...

Analog_Bridge update

Steve N4IRS

#491

There is still more work to do, but I have updated the github repository for Analog_Bridge to include DMRID <---> Callsign translation. This will ATTEMPT to show the proper DMRID for a callsign from DummyRepeater. In the other direction the TS/TG/ID is shown in the D-Star info field. This may get other changes later. See the Analog_Bridge.ini and get-subscriber-id.sh in the scripts directory.

Support for the DVMEGA AMBE 3000 still has to be added as well as refactoring. Software means never having to say you're finished. (apologies to Erich Segal)

73, Steve N4IRS

Re: Smartphone apps

Matthew 2E0SIP

#490

On Tue, Oct 17, 2017 at 10:34 am, Steve N4IRS wrote:

Analog_Bridge will accept TG/TS commands externally (on the fly) See tune.sh in the scripts directory. "tune.sh 3112173 311246 31123 2 1"

Oh, nice! thanks for confirmation

Re: Smartphone apps

Bob N1XBM <N1XBM@...>

#489

Group,

Thanks for the replies, I have used the Android iax app, and yes that works, and the audio is good. The only issue I have is that it doesn't seem to stay connected, I've started to run in the background, but I often find it will disconnect after a short while.

Has anyone else experienced this using the app too?

N1XBM
Apparare Scientor
Paratus Communicare
Allstar Node # 27086, 41540, 41812, 42086, 42658, 42657
www.radioguysrepeaternetwork.com

Re: Smartphone apps

Steve N4IRS

#488

Analog_Bridge will accept TG/TS commands externally (on the fly) See tune.sh in the scripts directory. "tune.sh 3112173 311246 31123 2 1"
The Android app I posted the link to is a IAX client.

Steve

Show quoted text

On 10/17/2017 1:28 PM, Matthew 2E0SIP wrote:

Hi Bob,

With a combination of IPSC_Bridge, Analog_Bridge, Allstar Asterisk, and an AMBE chip you can connect a SIP client to a single DMR talk group, however changing talkgroup on the fly would require some additional code.

You'd also be limited to one talkgroup per AMBE chip. However several SIP users could connect to the same TG.

I *intend* to make a Web based client for Allstar Asterisk, which could be ported over as an app with some assistance, but it's a little way down my list of projects.

I hope that helps

Matthew

Re: Smartphone apps

Matthew 2E0SIP

#487

Hi Bob,

With a combination of IPSC_Bridge, Analog_Bridge, Allstar Asterisk, and an AMBE chip you can connect a SIP client to a single DMR talk group, however changing talkgroup on the fly would require some additional code.

You'd also be limited to one talkgroup per AMBE chip. However several SIP users could connect to the same TG.

I *intend* to make a Web based client for Allstar Asterisk, which could be ported over as an app with some assistance, but it's a little way down my list of projects.

I hope that helps

Matthew

Re: Smartphone apps

Steve N4IRS

#486

Well,
AllStar + Analog_Bridge + IPSC_Bridge Will do that.
There is a Android app for AllStarLink <https://play.google.com/store/apps/details?id=org.dvswitch>

73, Steve

Show quoted text

On 10/17/2017 1:18 PM, Chris Andrist wrote:

I use RadioPro, but it requires a dedicated Motorola XPR Mobile Radio.

I would love to see some software that would allow me to run a small node on a raspberry pi with a thumbdv and allow my phone to access the network.

—
Regards,

Chris Andrist, KC7WSU

DMR-UTAH

On Oct 17, 2017, at 10:05 AM, Bob N1XBM <N1XBM@...> wrote:

I honestly sometimes miss things while doing research for "whats out there" With all of the tools for building networks. Has anyone come up with a way to peer a smartphone to an ipsc network?

I know there is some commercial offerings that require some server software.

Thank you

N1XBM
Apparare Scientor
Paratus Communicare
Allstar Node # 27086, 41540, 41812, 42086, 42658, 42657
www.radioguysrepeaternetwork.com

10261 - 10280 of 10738

Home Hashtags Subgroups Wiki About Features Pricing Updates Terms Help Twitter