Date   

Re: confbridge.py and TG Bridge state change fun

JJ Cummings
 

Sounds like a plan, if I get the chance today I’ll see what I can do too and submit a pull request.  That said it’s already looking like a busy day of real life instead of radio fun

JJC 

Sent from the iRoad

On Nov 9, 2017, at 05:08, Mike Zingman - N4IRR <mike.zingman@...> wrote:

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

Mike Zingman - N4IRR
 

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
 

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

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

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
 

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

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
 

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
 

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

73, Steve N4IRS

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
 

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
 

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
er

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
 

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
 

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
 

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
 

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
 

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
 

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
 

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

Steve, K4SQI

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
 

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
 

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

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
 

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

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
 

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 

9661 - 9680 of 10139