Date   

Re: Call routing cluster

Steve N4IRS
 

Petr,
Questions are no problem. We need to do a better job with the Wiki.
The short answers to your example: You will start hb_confbridge.py, it will start hblink for you.

hblink.py is the lowest level log the HB "stack" it handles connecting to servers and accepting connections from clients. It defines logging and table lookups for subscriber IDs etc. On it's own it does vary little BUT is is required. The first step in setting up a hblink application is to make sure hblink.py is properly configured. hb_confbridge will sub-class hblink.py Think of it as hb_confbridge calls hblink when it needs to communicate with Servers and Clients. (Don't shoot me guys)

You do not define repeaters or client s that can connect to the Master (Server). You define a a "place" where the repeater can connect to. in the sample config, that is [MASTER-1] Multiple clients can connect to that Master or you can define multiple Master sections.

To connect hblink to a BM master, you connect as a client. Setup the client the same way you would in MMDVMHost.

Hope this helps.

73, Steve N4IRS    

On 4/6/2018 4:20 AM, Petr Frank wrote:
Hi guys,

i've tried to play a bit and have some questions. It means dummy questions and I'd like to ask like an idiot :-)

  • I guess each *.PY script is a module so in case i want to use hb_confbridge do i have to start hblink.py + hb_confbridge.py or is particular module called/load by main script hblink.py?
  • Where and how i can define repeaters (including repeater ID, etc...) able to connect to the master
  • What's about requirements to connect hblink to DMR+ or BrandMeister as a repeater? I've tried but it ended in logging loop without success login.


Lets see my configuration

hblink.cfg:
[MASTER-1]
MODE: MASTER
ENABLED: True
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 62031
PASSPHRASE: passw0rd
GROUP_HANGTIME: 5

[REPEATER-1]
MODE: CLIENT
ENABLED: False
EXPORT_AMBE: False
IP:
PORT: 54001
MASTER_IP: 92.43.29.198
MASTER_PORT: 62031
PASSPHRASE: passw0rd
CALLSIGN: OK0TEST
RADIO_ID: 230116
RX_FREQ: 439000000
TX_FREQ: 431000000
TX_POWER: 25
COLORCODE: 1
SLOTS: 1
LATITUDE: 38.0000
LONGITUDE: -095.0000
HEIGHT: 75
LOCATION: Anywhere, EU
DESCRIPTION: This is a cool repeater
URL: www.w1abc.org
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS:

hb_confbridge_rules.py:

BRIDGES = {
    'WORLDWIDE': [
            {'SYSTEM': 'MASTER-1',    'TS': 1, 'TGID': 1,    'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON',  'ON': [2,], 'OFF': [9,10]},
            {'SYSTEM': 'REPEATER-1',    'TS': 1, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON',  'ON': [2,], 'OFF': [9,10]},
        ],
    'ENGLISH': [
            {'SYSTEM': 'MASTER-1',    'TS': 1, 'TGID': 13,   'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [3,], 'OFF': [8,10]},
            {'SYSTEM': 'REPEATER-1',    'TS': 1, 'TGID': 13,   'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [3,], 'OFF': [8,10]},
        ],
    'STATEWIDE': [
            {'SYSTEM': 'MASTER-1',    'TS': 2, 'TGID': 3129, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [4,], 'OFF': [7,10]},
            {'SYSTEM': 'REPEATER-1',    'TS': 2, 'TGID': 3129, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [4,], 'OFF': [7,10]},
        ],
    'PRAHA': [
            {'SYSTEM': 'MASTER-1',    'TS': 1, 'TGID': 111, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [5,], 'OFF': [6,10]},
            {'SYSTEM': 'REPEATER-1',    'TS': 1, 'TGID': 111, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [5,], 'OFF': [6,10]},
        ]
}

talkgroup_ids.csv:

1,MARC Wordlwide
2,Local 2
3,MARC North America
111,Praha

talkgroup_ids.json is deleted once hb_confbridge.py starts and it returns:
DEBUG 2018-04-06 09:58:41,802 Logging system started, anything from here on gets logged
INFO 2018-04-06 09:58:41,803 Routing bridges file found and bridges imported
ERROR: Conference bridges found for system not configured main configuration

Unfortunately i don't know what else i can check and modify.

Sorry for dummy questions but i was unable to find-out answers in wiki.

Petr, OK2ZAR.


Re: Call routing cluster

Petr Frank, OK2ZAR
 

Hi guys,

i've tried to play a bit and have some questions. It means dummy questions and I'd like to ask like an idiot :-)

  • I guess each *.PY script is a module so in case i want to use hb_confbridge do i have to start hblink.py + hb_confbridge.py or is particular module called/load by main script hblink.py?
  • Where and how i can define repeaters (including repeater ID, etc...) able to connect to the master
  • What's about requirements to connect hblink to DMR+ or BrandMeister as a repeater? I've tried but it ended in logging loop without success login.


Lets see my configuration

hblink.cfg:
[MASTER-1]
MODE: MASTER
ENABLED: True
REPEAT: True
EXPORT_AMBE: False
IP:
PORT: 62031
PASSPHRASE: passw0rd
GROUP_HANGTIME: 5

[REPEATER-1]
MODE: CLIENT
ENABLED: False
EXPORT_AMBE: False
IP:
PORT: 54001
MASTER_IP: 92.43.29.198
MASTER_PORT: 62031
PASSPHRASE: passw0rd
CALLSIGN: OK0TEST
RADIO_ID: 230116
RX_FREQ: 439000000
TX_FREQ: 431000000
TX_POWER: 25
COLORCODE: 1
SLOTS: 1
LATITUDE: 38.0000
LONGITUDE: -095.0000
HEIGHT: 75
LOCATION: Anywhere, EU
DESCRIPTION: This is a cool repeater
URL: www.w1abc.org
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM_HBlink
GROUP_HANGTIME: 5
OPTIONS:

hb_confbridge_rules.py:

BRIDGES = {
    'WORLDWIDE': [
            {'SYSTEM': 'MASTER-1',    'TS': 1, 'TGID': 1,    'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON',  'ON': [2,], 'OFF': [9,10]},
            {'SYSTEM': 'REPEATER-1',    'TS': 1, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'ON',  'ON': [2,], 'OFF': [9,10]},
        ],
    'ENGLISH': [
            {'SYSTEM': 'MASTER-1',    'TS': 1, 'TGID': 13,   'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [3,], 'OFF': [8,10]},
            {'SYSTEM': 'REPEATER-1',    'TS': 1, 'TGID': 13,   'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [3,], 'OFF': [8,10]},
        ],
    'STATEWIDE': [
            {'SYSTEM': 'MASTER-1',    'TS': 2, 'TGID': 3129, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [4,], 'OFF': [7,10]},
            {'SYSTEM': 'REPEATER-1',    'TS': 2, 'TGID': 3129, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [4,], 'OFF': [7,10]},
        ],
    'PRAHA': [
            {'SYSTEM': 'MASTER-1',    'TS': 1, 'TGID': 111, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [5,], 'OFF': [6,10]},
            {'SYSTEM': 'REPEATER-1',    'TS': 1, 'TGID': 111, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [5,], 'OFF': [6,10]},
        ]
}

talkgroup_ids.csv:

1,MARC Wordlwide
2,Local 2
3,MARC North America
111,Praha

talkgroup_ids.json is deleted once hb_confbridge.py starts and it returns:
DEBUG 2018-04-06 09:58:41,802 Logging system started, anything from here on gets logged
INFO 2018-04-06 09:58:41,803 Routing bridges file found and bridges imported
ERROR: Conference bridges found for system not configured main configuration

Unfortunately i don't know what else i can check and modify.

Sorry for dummy questions but i was unable to find-out answers in wiki.

Petr, OK2ZAR.


Re: DVSwitch Status update

Steve N4IRS
 

Yes it will. The plan is to decouple to Vocoders from Analog_Bridge and provide a method for someone to build the Vocoder separately.

On 4/5/2018 8:57 AM, Matthew 2E0SIP wrote:

Hi All,

This is an exciting update, thanks to all for the hard work.

One question, will the emulator run as a separate process, so it can be emulated on X86_64, without running Analog_Bridge in its entirety in an emulator? 

Cheers



Re: DVSwitch Status update

Matthew 2E0SIP
 

Hi All,

This is an exciting update, thanks to all for the hard work.

One question, will the emulator run as a separate process, so it can be emulated on X86_64, without running Analog_Bridge in its entirety in an emulator? 

Cheers


Re: ASL>DStar dummy repeater crashing

G7RPG - Peter Kendall
 

Thanks, Steve. I'll sit tight for a bit.

73

Peter


On 02/04/18 22:08, Steve N4IRS wrote:
DummyRepeater is not long for this world. We will be replacing it wit a simpler lighter solution. See my post a few weeks ago.

Steve

On 04/02/2018 04:46 PM, G7RPG - Peter Kendall wrote:

Hi Steve,

I'm running ASL on x68 debian on an esx vm, likewise I've got an x68 vm debian box that I've tried running dummy repeater on. I've got a couple of ambe devices NWDR Thumb DV and a DV-MEGA ambe300+carrier board makes no difference.

I tried running dummy repeater and ircddbgateway on a Pi and again the same thing happens.

My ASL > DMR is rock solid!

73

Peter


On 02/04/18 21:29, Steven Blackford wrote:
Hi Peter,
  ASL<->D-Star is rock solid for me.    It's been running currently for several weeks without a reboot or restart.  When I had my node setup to bridge over to DMR, i had an issue with the DMR->ASL going to sleep until someone keyed up on ASL.  Then it would start working again.  On your PI are you running the new ASL software or are you running the HamVOIP software?  What hardware are you using to do the transcoding?    I'm currently using a PiDV, but have used an original Blue DV-Dongle & a ThumbDV as well.   73 de K4SQI!

Steve, K4SQI


On Mon, Apr 2, 2018 at 4:23 PM, G7RPG - Peter Kendall <g7rpg@...> wrote:
Hi I wonder if anyone who is using dummy repeater to link to allstar has
a problem where dstar > asl stops working randomly sometimes an hour
sometimes a day or so. ASL > dstar is never a problem.

Restarting dummy repeater fixes the problem.

I've tried this on a VM and Rpi and get the same results.


73
Peter
G7RPG









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




Re: ASL>DStar dummy repeater crashing

Steve N4IRS
 

DummyRepeater is not long for this world. We will be replacing it wit a simpler lighter solution. See my post a few weeks ago.

Steve

On 04/02/2018 04:46 PM, G7RPG - Peter Kendall wrote:

Hi Steve,

I'm running ASL on x68 debian on an esx vm, likewise I've got an x68 vm debian box that I've tried running dummy repeater on. I've got a couple of ambe devices NWDR Thumb DV and a DV-MEGA ambe300+carrier board makes no difference.

I tried running dummy repeater and ircddbgateway on a Pi and again the same thing happens.

My ASL > DMR is rock solid!

73

Peter


On 02/04/18 21:29, Steven Blackford wrote:
Hi Peter,
  ASL<->D-Star is rock solid for me.    It's been running currently for several weeks without a reboot or restart.  When I had my node setup to bridge over to DMR, i had an issue with the DMR->ASL going to sleep until someone keyed up on ASL.  Then it would start working again.  On your PI are you running the new ASL software or are you running the HamVOIP software?  What hardware are you using to do the transcoding?    I'm currently using a PiDV, but have used an original Blue DV-Dongle & a ThumbDV as well.   73 de K4SQI!

Steve, K4SQI


On Mon, Apr 2, 2018 at 4:23 PM, G7RPG - Peter Kendall <g7rpg@...> wrote:
Hi I wonder if anyone who is using dummy repeater to link to allstar has
a problem where dstar > asl stops working randomly sometimes an hour
sometimes a day or so. ASL > dstar is never a problem.

Restarting dummy repeater fixes the problem.

I've tried this on a VM and Rpi and get the same results.


73
Peter
G7RPG









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



Re: ASL>DStar dummy repeater crashing

Steven Blackford
 

Hey Peter,
   Sounds like we need to compare notes then. :-)  I've sent you an email off list.  I'd be happy to try to help you get the ASL<->D-Star side working if I can.  Just a quick question.  Are you using an AMBEserver in the mix or are you going directly to the AMBE device with DummyRepeater?  73 de K4SQI.

Steve, K4SQI

On Mon, Apr 2, 2018 at 4:46 PM, G7RPG - Peter Kendall <g7rpg@...> wrote:

Hi Steve,

I'm running ASL on x68 debian on an esx vm, likewise I've got an x68 vm debian box that I've tried running dummy repeater on. I've got a couple of ambe devices NWDR Thumb DV and a DV-MEGA ambe300+carrier board makes no difference.

I tried running dummy repeater and ircddbgateway on a Pi and again the same thing happens.

My ASL > DMR is rock solid!

73

Peter


On 02/04/18 21:29, Steven Blackford wrote:
Hi Peter,
  ASL<->D-Star is rock solid for me.    It's been running currently for several weeks without a reboot or restart.  When I had my node setup to bridge over to DMR, i had an issue with the DMR->ASL going to sleep until someone keyed up on ASL.  Then it would start working again.  On your PI are you running the new ASL software or are you running the HamVOIP software?  What hardware are you using to do the transcoding?    I'm currently using a PiDV, but have used an original Blue DV-Dongle & a ThumbDV as well.   73 de K4SQI!

Steve, K4SQI


On Mon, Apr 2, 2018 at 4:23 PM, G7RPG - Peter Kendall <g7rpg@...> wrote:
Hi I wonder if anyone who is using dummy repeater to link to allstar has
a problem where dstar > asl stops working randomly sometimes an hour
sometimes a day or so. ASL > dstar is never a problem.

Restarting dummy repeater fixes the problem.

I've tried this on a VM and Rpi and get the same results.


73
Peter
G7RPG









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




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


Re: ASL>DStar dummy repeater crashing

G7RPG - Peter Kendall
 

Hi Steve,

I'm running ASL on x68 debian on an esx vm, likewise I've got an x68 vm debian box that I've tried running dummy repeater on. I've got a couple of ambe devices NWDR Thumb DV and a DV-MEGA ambe300+carrier board makes no difference.

I tried running dummy repeater and ircddbgateway on a Pi and again the same thing happens.

My ASL > DMR is rock solid!

73

Peter


On 02/04/18 21:29, Steven Blackford wrote:
Hi Peter,
  ASL<->D-Star is rock solid for me.    It's been running currently for several weeks without a reboot or restart.  When I had my node setup to bridge over to DMR, i had an issue with the DMR->ASL going to sleep until someone keyed up on ASL.  Then it would start working again.  On your PI are you running the new ASL software or are you running the HamVOIP software?  What hardware are you using to do the transcoding?    I'm currently using a PiDV, but have used an original Blue DV-Dongle & a ThumbDV as well.   73 de K4SQI!

Steve, K4SQI


On Mon, Apr 2, 2018 at 4:23 PM, G7RPG - Peter Kendall <g7rpg@...> wrote:
Hi I wonder if anyone who is using dummy repeater to link to allstar has
a problem where dstar > asl stops working randomly sometimes an hour
sometimes a day or so. ASL > dstar is never a problem.

Restarting dummy repeater fixes the problem.

I've tried this on a VM and Rpi and get the same results.


73
Peter
G7RPG









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


Re: ASL>DStar dummy repeater crashing

Steven Blackford
 

Hi Peter,
  ASL<->D-Star is rock solid for me.    It's been running currently for several weeks without a reboot or restart.  When I had my node setup to bridge over to DMR, i had an issue with the DMR->ASL going to sleep until someone keyed up on ASL.  Then it would start working again.  On your PI are you running the new ASL software or are you running the HamVOIP software?  What hardware are you using to do the transcoding?    I'm currently using a PiDV, but have used an original Blue DV-Dongle & a ThumbDV as well.   73 de K4SQI!

Steve, K4SQI


On Mon, Apr 2, 2018 at 4:23 PM, G7RPG - Peter Kendall <g7rpg@...> wrote:
Hi I wonder if anyone who is using dummy repeater to link to allstar has
a problem where dstar > asl stops working randomly sometimes an hour
sometimes a day or so. ASL > dstar is never a problem.

Restarting dummy repeater fixes the problem.

I've tried this on a VM and Rpi and get the same results.


73
Peter
G7RPG









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


ASL>DStar dummy repeater crashing

G7RPG - Peter Kendall
 

Hi I wonder if anyone who is using dummy repeater to link to allstar has
a problem where dstar > asl stops working randomly sometimes an hour
sometimes a day or so. ASL > dstar is never a problem.

Restarting dummy repeater fixes the problem.

I've tried this on a VM and Rpi and get the same results.


73
Peter
G7RPG


Re: Call routing cluster

Peter M0NWI
 

Petr,

I do exactly that using using bridge.py and define all the slots / TG / repeaters' in the bridge_rules.py, you can define them as always on, it user activated, UA can be made to switch on a specific transmission group or time.

Have a look at bridge_rules sample, its super flexible!

73,
Peter

Sent from Outlook
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Petr Frank <iogroups@...>
Sent: 28 March 2018 18:49:51
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Call routing cluster
 
Thanks Corey. I'll test it and maybe come back with another question ;-)


Re: Call routing cluster

Petr Frank, OK2ZAR
 

Thanks Corey. I'll test it and maybe come back with another question ;-)


Re: Call routing cluster

Corey Dean N3FE <n3fe@...>
 

I should have done my homework before responding...  You can run the hb confbridge and do that.  Here is the sample config.

https://github.com/n0mjs710/HBlink/blob/master/hb_confbridge_rules-SAMPLE.py

Corey N3FE

On Wed, Mar 28, 2018 at 1:27 PM, Petr Frank <iogroups@...> wrote:
Hi guys,

i've test HBlink approx 3 months ago and it really worked. ;-) Fantastic work. I used modified config sample a bit during my testing. I've some questions based on my experiences.

Is possible to create some clusters? It means to have group of repeaters assigned to specified talk group and when somebody talks on the TG then all assigned repeaters are transmitting but non-assigned repeaters are idle.
How i can define permanent linked group(s) for each repeater? Is possible to have on-demand groups?
Are DMR private calls supported? I haven't been able to establish private call via HBlink.

73 de Petr, OK2ZAR.



Re: Call routing cluster

Corey Dean N3FE <n3fe@...>
 

I know using dmrlink you define it in the confbrdge and each connection has its own login.  I haven't looked to see if there is a hb conference bridge but I am assuming it would work the same way if there is such a thing.

Corey  N3FE

On Wed, Mar 28, 2018 at 1:27 PM, Petr Frank <iogroups@...> wrote:
Hi guys,

i've test HBlink approx 3 months ago and it really worked. ;-) Fantastic work. I used modified config sample a bit during my testing. I've some questions based on my experiences.

Is possible to create some clusters? It means to have group of repeaters assigned to specified talk group and when somebody talks on the TG then all assigned repeaters are transmitting but non-assigned repeaters are idle.
How i can define permanent linked group(s) for each repeater? Is possible to have on-demand groups?
Are DMR private calls supported? I haven't been able to establish private call via HBlink.

73 de Petr, OK2ZAR.



Call routing cluster

Petr Frank, OK2ZAR
 

Hi guys,

i've test HBlink approx 3 months ago and it really worked. ;-) Fantastic work. I used modified config sample a bit during my testing. I've some questions based on my experiences.

Is possible to create some clusters? It means to have group of repeaters assigned to specified talk group and when somebody talks on the TG then all assigned repeaters are transmitting but non-assigned repeaters are idle.
How i can define permanent linked group(s) for each repeater? Is possible to have on-demand groups?
Are DMR private calls supported? I haven't been able to establish private call via HBlink.

73 de Petr, OK2ZAR.


Re: HB_Bridge 1 to 1 relationship

Peter M0NWI
 

Hi Steve,


Ah, that might be my issue then, I've one configured as a Master, and another as a client to connect out to another bridge using the MMDVM protocol.


I'd wondered if I just needed one repeater setup for MMDVM and it would handle multiple clients, unlike DMRLink where we need one entry per repeater.


Any thoughts on if 2 repeaters due to the mixed modes could be made to work, or am I best to have 2 sets of files?


73,

Peter



From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Sent: 27 March 2018 17:04
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] HB_Bridge 1 to 1 relationship
 
Peter,
I assume you have the HB_Bridge side configured as a Server. You should be able to connect the second MMDVM to the same IPO/Port as the first, without adding a second Server stanza.

Steve

On 3/27/2018 11:57 AM, Peter M0NWI wrote:

All,


I've got a DMRLink bridge that I wanted to add an MMDVM too, so setup HBLink and confirm it worked with the MMDVM OK, then configured IPSC_Bridge, and HB_Bridge, all worked OK and using bridge rules I could pass group voice between the 2 without issue.


Today I wanted to add a second MMDVM, so edited the hblink.cfg file to add a second repeater, ran hblink.py to confirm all was OK, then started HB_Bridge, which died due to the UDP socket already being in use.


root@www:/opt/HBlink# ./HB_Bridge.py
load config file config.file
Traceback (most recent call last):
  File "./HB_Bridge.py", line 237, in <module>
    systems[system] = HB_BRIDGE(system, CONFIG, logger)
  File "./HB_Bridge.py", line 101, in __init__
    self.hb_ambe = AMBE_HB(self, _name, _config, _logger, self._ambeRxPort)
  File "/opt/HBlink/dmr_utils/ambe_bridge.py", line 381, in __init__
    AMBE_BASE.__init__(self, _parent, _name, _config, _logger, _port)
  File "/opt/HBlink/dmr_utils/ambe_bridge.py", line 187, in __init__
    self.udp_port = reactor.listenUDP(self._ambeRxPort, UDP_IMPORT(self.import_datagramReceived))
  File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 374, in listenUDP
    p.startListening()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 175, in startListening
    self._bindSocket()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 195, in _bindSocket
    raise error.CannotListenError(self.interface, self.port, le)
twisted.internet.error.CannotListenError: Couldn't listen on any:31003: [Errno 98] Address already in use.


This threw me a little, and so I thought I'd re-used a port number by accident, but reading the error a little closer, so it was the 31003 port, which is what I use for pushing AMBE from HB to IPSC, but I didn't have another instance of HB_Bridge running, after some head scratching I edited my hblink.cfg file to comment out the original of the two repeater instances, and all went back to working, so both my repeater configs where OK.


Thinking a bit more, it must be that each instance will need to have it's own pair of HB to IPSC files, as otherwise the AMBE packets could all just hit the other partner from both HB repeaters at the same time, if they happen to be talking at the same time?


So the question is, do I need to setup an additional set of IPSC_Bridge and HB_Bridge files for each additional HB repeater I with to add into DMRLink, or am I missing something where there is a way for the tuple of repeater source ID, Slot, TG to be sent through along with AMBE audio to the partners and so multiple HB's can talk to multiple IPSC/DMRLink?


73,

Peter



Re: HB_Bridge 1 to 1 relationship

Steve N4IRS
 

Peter,
I assume you have the HB_Bridge side configured as a Server. You should be able to connect the second MMDVM to the same IPO/Port as the first, without adding a second Server stanza.

Steve

On 3/27/2018 11:57 AM, Peter M0NWI wrote:

All,


I've got a DMRLink bridge that I wanted to add an MMDVM too, so setup HBLink and confirm it worked with the MMDVM OK, then configured IPSC_Bridge, and HB_Bridge, all worked OK and using bridge rules I could pass group voice between the 2 without issue.


Today I wanted to add a second MMDVM, so edited the hblink.cfg file to add a second repeater, ran hblink.py to confirm all was OK, then started HB_Bridge, which died due to the UDP socket already being in use.


root@www:/opt/HBlink# ./HB_Bridge.py
load config file config.file
Traceback (most recent call last):
  File "./HB_Bridge.py", line 237, in <module>
    systems[system] = HB_BRIDGE(system, CONFIG, logger)
  File "./HB_Bridge.py", line 101, in __init__
    self.hb_ambe = AMBE_HB(self, _name, _config, _logger, self._ambeRxPort)
  File "/opt/HBlink/dmr_utils/ambe_bridge.py", line 381, in __init__
    AMBE_BASE.__init__(self, _parent, _name, _config, _logger, _port)
  File "/opt/HBlink/dmr_utils/ambe_bridge.py", line 187, in __init__
    self.udp_port = reactor.listenUDP(self._ambeRxPort, UDP_IMPORT(self.import_datagramReceived))
  File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 374, in listenUDP
    p.startListening()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 175, in startListening
    self._bindSocket()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 195, in _bindSocket
    raise error.CannotListenError(self.interface, self.port, le)
twisted.internet.error.CannotListenError: Couldn't listen on any:31003: [Errno 98] Address already in use.


This threw me a little, and so I thought I'd re-used a port number by accident, but reading the error a little closer, so it was the 31003 port, which is what I use for pushing AMBE from HB to IPSC, but I didn't have another instance of HB_Bridge running, after some head scratching I edited my hblink.cfg file to comment out the original of the two repeater instances, and all went back to working, so both my repeater configs where OK.


Thinking a bit more, it must be that each instance will need to have it's own pair of HB to IPSC files, as otherwise the AMBE packets could all just hit the other partner from both HB repeaters at the same time, if they happen to be talking at the same time?


So the question is, do I need to setup an additional set of IPSC_Bridge and HB_Bridge files for each additional HB repeater I with to add into DMRLink, or am I missing something where there is a way for the tuple of repeater source ID, Slot, TG to be sent through along with AMBE audio to the partners and so multiple HB's can talk to multiple IPSC/DMRLink?


73,

Peter



HB_Bridge 1 to 1 relationship

Peter M0NWI
 

All,


I've got a DMRLink bridge that I wanted to add an MMDVM too, so setup HBLink and confirm it worked with the MMDVM OK, then configured IPSC_Bridge, and HB_Bridge, all worked OK and using bridge rules I could pass group voice between the 2 without issue.


Today I wanted to add a second MMDVM, so edited the hblink.cfg file to add a second repeater, ran hblink.py to confirm all was OK, then started HB_Bridge, which died due to the UDP socket already being in use.


root@www:/opt/HBlink# ./HB_Bridge.py
load config file config.file
Traceback (most recent call last):
  File "./HB_Bridge.py", line 237, in <module>
    systems[system] = HB_BRIDGE(system, CONFIG, logger)
  File "./HB_Bridge.py", line 101, in __init__
    self.hb_ambe = AMBE_HB(self, _name, _config, _logger, self._ambeRxPort)
  File "/opt/HBlink/dmr_utils/ambe_bridge.py", line 381, in __init__
    AMBE_BASE.__init__(self, _parent, _name, _config, _logger, _port)
  File "/opt/HBlink/dmr_utils/ambe_bridge.py", line 187, in __init__
    self.udp_port = reactor.listenUDP(self._ambeRxPort, UDP_IMPORT(self.import_datagramReceived))
  File "/usr/lib/python2.7/dist-packages/twisted/internet/posixbase.py", line 374, in listenUDP
    p.startListening()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 175, in startListening
    self._bindSocket()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/udp.py", line 195, in _bindSocket
    raise error.CannotListenError(self.interface, self.port, le)
twisted.internet.error.CannotListenError: Couldn't listen on any:31003: [Errno 98] Address already in use.


This threw me a little, and so I thought I'd re-used a port number by accident, but reading the error a little closer, so it was the 31003 port, which is what I use for pushing AMBE from HB to IPSC, but I didn't have another instance of HB_Bridge running, after some head scratching I edited my hblink.cfg file to comment out the original of the two repeater instances, and all went back to working, so both my repeater configs where OK.


Thinking a bit more, it must be that each instance will need to have it's own pair of HB to IPSC files, as otherwise the AMBE packets could all just hit the other partner from both HB repeaters at the same time, if they happen to be talking at the same time?


So the question is, do I need to setup an additional set of IPSC_Bridge and HB_Bridge files for each additional HB repeater I with to add into DMRLink, or am I missing something where there is a way for the tuple of repeater source ID, Slot, TG to be sent through along with AMBE audio to the partners and so multiple HB's can talk to multiple IPSC/DMRLink?


73,

Peter


Re: DVSwitch Status update

Steven Blackford
 

Steve,
  Tnanks for the update & all the hard work by everyone involved!  As you know already, over the past several months one of my big projects has been the Carolina Link and without a lot of the software you guys provide, the task would've been a lot harder to do.  It's mostly streamlined now that we are taking advantage of the tanscoding system with the XLXD Reflector, but there are times I can honestly say while it works great, the DMR<->D-Star bridge solution you guys provide is 100 times more flexible.  Our group had actually started to get used to this & I still think @ times would prefer if I put this solution back in place. :-)  I continue to  provide a bridge between AllStar and D-Star.  After my presentation at both the GARA Club in Greensboro, NC and the Charlotte Hamfest this month, we've seen a lot more interest in what we're doing locally and in AllStar as well.  Besides our bridge, I provide an additional AllStar node our members can use to connect to other Allstar Nodes via the Android IAXRPT app & Zoiper.  Before my presentations, we maybe had 2-3 people taking advantage of this.  Now we have several people using it.  So, thanks again for all the hard work & 73 de K4SQI!

Steve, K4SQI


On Wed, Mar 21, 2018 at 9:25 AM, Steve N4IRS <szingman@...> wrote:
It has been quite a while since we posted a status update on all of the projects either in the works or deployed. The toolkit is growing and maturing. We are adding connections to more Networks and changing the method we use to connect.

I'll start with DMR. There are multiple DMR networks in use by Amateur Radio. Two of the biggest are HomeBrew based networks (BrandMeister) and IPSC based networks (DMR-MARC). The nice thing about a HB network is that it is open. Cort and Mike have done a lot of work to fix bugs and expand the capability of the HB and IPSC connection tools. Work is being done to enhance the handling of much of the Metadata received from and sent to a HB network. Talker Alias is only one example of the enhancement in the works. Work is being done to find and squash bugs in the IPSC connections. This is harder to do since we have to learn what is going on by reverse engineering.

The connection to D-Star is changing for the better. Again, we have the advantage of open source. The existing connection is built with a modification to DummyRepeater from G4KLX. It made sense at the time since the main purpose of connecting to D-Star was to replace a aging AllStarLink connection method. DummyRepeater gave us most everything we needed to connect and import / export analog audio. DummyRepeater came with a LOT of baggage we did not need and it required some neat tricks to make it work headless. With the next iteration of the D-Star connector, DummyRepeater will no longer be used. This will allow us to standardize the import /export. Metadata is one important part of the upcoming change.

For P25, a number of things are changing and there will be some additions. For P25_Bridge we connect to the MMDVM P25 Network of reflectors. The Network is quite simple and very effective. For each talk group there is a reflector. Each reflector can be on a single host or a host can have more then one reflector. There is at least one other P25 Network in use for Amateur Radio. That Network is P25NX. P25NX is built for Motorola Quantar repeaters. The Quantar (and other Motorola repeaters) is native P25. The P25NX network leverages the ability for a Quantar to be connected to another Quantar either locally or via a modem. P25NX expanded on that feature to allow a network of repeaters. They use a surplus Cisco router and a small host computer (RPi) to build the node. Thanks to the work of NX4Y and others, we decided to leverage the Cisco router to connect to the MMDVM P25 Network. We have built a proof of concept software connector. Quantar_Bridge runs on small host and uses P25Gateway to connect the Quantar to the MMDVM network. The software is still early and we would like to remove the need for the Cisco router. Stay tuned.

Analog_Bridge is continuing to go through changes (can you say feature creep?) Analog_Bridge started life with a different name. It was first called DMRGateway. We decided there were two things wrong with that name. One is it's not a gateway, it's a bridge and more importantly, it does more then DMR. We renamed it Analog_Bridge (days before G4KLX release what he called DMRGateway) Analog_Bridge has the ability to convert analog audio and signaling to digital. For audio, Analog_Bridge uses a Vocoder. That Vocoder can be a hardware Vocoder from a number of vendors including DVMega, Internet Labs and NW Digital Radio. Analog_Bridge will also support software based Vocoders like the MD380emu (on hosts that can run MD380emu) and others. The inclusion of support for other codecs can be added later. The method we used for import / export of analog data was borrowed from the AllStarLink USRP channel driver. Using USRP gave us a way to import / export audio from AllStarLink without any modifications to the channel_driver. USRP also provides signaling (COS, PTT) and a simple form of Metadata. The MetaData component will be expanded as needed. One of the requests we have had is the ability for connection to a network from a PC or SmartPhone / Tablet. USRP works quite well for this. Mike has built USRP client programs for Desktops (Python) and has a working on a iPhone version. The advantage of this approach, is that the client can be quite lightweight. The heavy lifting is done by Analog_Bridge.

A bridge to YSF is being added. YSF_Bridge will use parts from the MMDVM project, so we will have the same capabilities as existing connections. There are quite a few interesting things that will be possible.

A new entry to the family will be NXDN. We plan to add NXDN tools to DVSwitch. We will use the same concepts and methods to leverage the MMDVM project. Stay tuned.

All of the work being done to the bridge tools are intended to standardize the import and export of data. That data can be audio or metadata. Each target network has its own unique set of feature (and challenges) The work is to build a method of interchanging data. Some times that interchange is a one for one relationship. Callsign is a example of that type of relationship. Every network in some way supports the user callsign. On some networks, that callsign has to be derived from other data (DMR, P25...) On D-Star that data is explicit. Other data is unique to a network and may need to be derived. DMR Slot number is a example of this. For HB ---> IPSC this can be (but does not have to be) one to one. For DMR ---> P25, slot has little if any value. For P25 ---> DMR it will have to be derived. For audio the relationship is somewhat simpler. It is either one to one or it's not. A good example of one for one is DMR <---> YSF Narrow. These two modes use the same Vocoder. Some manipulation of the packaging of the data is needed but the AMBE is the same. Again, Metadata will require some manipulation. Digital to analog requires a conversion. This is the job of Analog_Bridge. For example DMR <---> AllStarLink the conversion is AMBE to PCM. When two networks do not share a common Vocoder (or the data is somewhat different) we have to transcode. We transcode by using a Vocoder to convert the data to PCM. That PCM data is exported to another instance of Analog_Bridge where the PCM is imported and converted by a second Vocoder.

Since quite a few of the bridges in uses include AllStarLink I'll update that status too. I have finished up the next release of AllStarLink. We have made quite a few changes to both installation method(s) and usability. With this release, the install is a simple "apt-get install allstarlink" This method uses the standard Debian APT package system. This will allow for much faster turn around of bug fixes and enhancements. As always, the source code is published on GitHub.

Are thing moving slower then we would like? You bet. The work take time and we pay a lot of attention to where we want to go. It does not make sense to code something and just push it out when we know the change will have to be removed down the road to get us where we want to go. This is like chess, we have to look a few moves ahead and pln how we get there. The feedback from the user base is invaluable. No developer in his (her) right mind is going to understand every use case. You have no idea how many e-mails get sent with "I never thought of that!" We are three guys with day jobs, families and lots of projects on our plates. The work is getting done and there is quite a bit of interaction between projects.

For DVSwitch,
73, Steve N4IRS






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


Re: HBLink Parrot Settings

DO1KBL, Kim
 

Its working fine! Thanks for the informations :-)

9641 - 9660 of 10557