Date   

Re: A couple of items over the past week

Steve N4IRS
 

I have not seen that issue with parrot. As to revert, yes it should unless P25Gateway is seeing traffic of some kind. Again, the logs.

Steve

On 12/1/18 9:44 AM, Mike AE4ML wrote:
has anyone expierenced this with parrot. I have had two repeaters do this to me. 
I use TG10 and send my voice message and two minutes later it responds.  Seemed odd. I power cycled the pi and that didn’t help. 
Next trip up I need to pull the logs. 

Another site. 
I have a private TG and I also allow other talkgroups. The system is locking on the last talkgroup. I thought there was a timeout that would revert to a preset talkgroup. 

Mike


A couple of items over the past week

Mike AE4ML
 

has anyone expierenced this with parrot. I have had two repeaters do this to me. 
I use TG10 and send my voice message and two minutes later it responds.  Seemed odd. I power cycled the pi and that didn’t help. 
Next trip up I need to pull the logs. 

Another site. 
I have a private TG and I also allow other talkgroups. The system is locking on the last talkgroup. I thought there was a timeout that would revert to a preset talkgroup. 

Mike


IPSC Bridge intalation manual

Juan Carlos Pérez <km4nno@...>
 

Hi, I am looking for a basic instalation manual for IPSC Bridge. I foung the manual for MMDVM Bridge very helpfull, so I am wondering if there is one fot IPSC.

cheers,
Juan Carlos
XE1F


Re: ASL <> D-Star

Mike Zingman - N4IRR
 

AB can use a software codec which has somewhat limited quality but will allow you to configure and test. 


Re: Issues With mmdvm modem

Steve N4IRS
 

Kyle,
This is really not the place for MMDVM modem support. I suggest you ask your question on https://groups.yahoo.com/neo/groups/mmdvm/info

Steve n4IRS


Issues With mmdvm modem

Kyle Robinson <K4KTR@...>
 

Hello i have an mmdvm modem that i got from ebay i have it hooked up and paired with a tkr-850 well trying to set it up i have ran in to this issues the modem RX is fine im using nxdn but when the thing goes to tx it will not key up the repeater the ptt light on the mmdvm does not activate any ideas?


Re: ASL <> D-Star

 

well here's to my memory, i was trying to do this software only.
you need a hardware option for D-Star :(

On Fri, Nov 30, 2018 at 11:43 AM Steven Blackford <kb7sqi@...> wrote:

Hey Russel,

    I run an additional DMR <->D-Star bridge on the Carolina Link on Tues/Sat nights.  Here’s the MMDVM.ini setup info for D-Star:

 

[D-Star Network]

Enable=1

GatewayAddress=192.168.0.250

GatewayPort=20010

LocalPort=20012

Debug=0

 

 

In the D-Star section, you need to point the GatewayAddress & GatewayPort to where you have your ircDDBGateway running.  In the above, I have one instance of ircDDBGateway running on a different PI2.  It’s where I have a DVAP setup.  It’s easy enough to have more than one “device” setup in ircDDBGateway.  In your ircDDBGateway you need to point your module to where the “new device” is running so here’s the section of ircDDBGateway:

 

repeaterCall2=

repeaterBand2=D

repeaterType2=0

repeaterAddress2=192.168.0.240

repeaterPort2=20012

reflector2=

atStartup2=0

reconnect2=0

frequency2=0.00000

offset2=0.0000

rangeKms2=0.000

 

I use “repeater 2” in ircDDBGateway for the additional bridge.   The bridge is ran on an ODroid C1 w/ the IP of 192.168.0.240.  ircDDBGateway is running on a PI2 w/ the IP of 192.168.0.250.  Make sense?  Hope that helps.  73 de K4SQI!

 

Steve, K4SQI

 

Sent from Mail for Windows 10

 

From: Russell, KV4S
Sent: Friday, November 30, 2018 12:13 PM
To: main@dvswitch.groups.io
Subject: [DVSwitch] ASL <> D-Star

 

I just started a new project for a D-STAR to ASL bridge.

If anyone has done this before can you send me an example MMDVM_Bridge.ini?

if not can someone point me in the right direction? around the settings for network and ircdbb?

 

also, in the analog bridge ini does this look right?

; Information for xx_Bridges (Where xx is MMDVM, HB, IPSC)

[AMBE_AUDIO]

server = 127.0.0.1                      ; IP address of xx_Bridge.py

fromDMRPort = 32100                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" in x$

toDMRPort = 32103                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort" in$

ambeMode = DSTAR                        ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW

minTxTimeMS = 2000                      ; Minimum time in MS for hang delay

gatewayDmrId = 3136665                  ; ID to use when transmitting from Analog_Bridge

repeaterID = 313666508                  ; ID of source repeater

txTg = XRF749D                          ; TG to use for all frames received from Analog_Bridge -> xx_Br$

txTs = 2                                ; Slot to use for frames received from Analog_Bridge -> xx_Brid$

colorCode = 1                           ; Color Code to assign DMR frames

 


Re: Tip of the day...

Cort N0MJS <n0mjs@...>
 

You got it!

So the next question someone is going to have is “why didn’t you just do something cool like JJ did and not make us write python”? Because a lot of different systems will work differently. I never came up with a reasonable configuration parser that captured all of the possibilities of that file format without being equally difficult to manage. The only solution would have been to pick a subset of possible paradigms and then force users to pick one. That’s the exact opposite of my goals with these programs.

Thanks for looking at what I posted and coming up with your own solution JJ, that’s what this is all about!

0x49 DE N0MJS

On Nov 30, 2018, at 1:12 PM, JJ Cummings <cummingsj@...> wrote:

Cort - Nice example that got me thinking!  Here is another example of what one might do to manage larger TG lists if you still want things done per TG etc.... Note that this is a simple example and does _NOT_ account for different TO_TYPE values but could be trivially modified to do such dynamically through the BuildBridges function or just define the custom values by updating the dict later on, like in the below example.

----BEGIN SNIP----

TS1_TGS = [310815,31088,31087]
SYSTEMS = ['MMDVM', 'MOTOTRBO', 'BRANDMEISTER']

def BuildBridges(ts,tgids,systems):
    BRIDGE = {}
    for tgid in tgids:
        export_dict = []
        for system in systems:
            export_dict.append({'SYSTEM': system, 'TS': ts, 'TGID': tgid, 'ACTIVE': True, 'TIMEOUT': {}, 'TO_TYPE': 'NONE',  'ON': [], 'OFF': [], 'RESET': []})
        TMPBRIDGE = {tgid:export_dict}
        BRIDGE.update(TMPBRIDGE)
    return BRIDGE

BRIDGES = BuildBridges(1,TS1_TGS,SYSTEMS)
BRIDGES.update(BuildBridges(2,[311,310,3100,3108],SYSTEMS))
BRIDGES.update({'BM-TAC312': [
           {'SYSTEM': 'BRANDMEISTER',    'TS': 2, 'TGID': 312, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [1312], 'RESET': []},
            {'SYSTEM': 'MMDVM',    'TS': 2, 'TGID': 312, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [1312], 'RESET': []},
            {'SYSTEM': 'IPSC_TS2',    'TS': 2, 'TGID': 312, 'ACTIVE': True, 'TIMEOUT': 5, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}
        ]})

if __name__ == '__main__':
    from pprint import pprint
    pprint(BRIDGES)

----END SNIP----

On Thu, Nov 29, 2018 at 2:02 PM Cort N0MJS via Groups.Io <n0mjs=me.com@groups.io> wrote:
Thought I’d share this with you guys in case anyone is interested.

The K0USY group doesn’t use “channel based” linking, we use “contact based”. This is where you talk on the same TGID all of the time, and only use the other TGIDs for in-band signaling to tell confbridge/hb_confbridge to turn things on and off, etc.

This requires a pretty big list of “off” TGIDs be listed in the BRIDGES section of the confbridge_rules file. One of the reasons I left the rules file a python file instead of an intermediate syntax is to allow using actual python code in it as well. Think of this like the SCOM analog controllers where nearly everything is built on macros, as opposed to the ACC style, where everything is an individual command.

To make things easier for myself, I defined a python list of all of the TGIDs that I use on the linked timeslot (I only use one timeslot for linking). One place to keep track of them all – that’s the first line in the paste below.

Then I wrote a function (that’s the block of code that starts with “def”) that takes two lists as arguments. The first list is the big list of TGIDs I just made, and the second is a list of TGIDs I want removed. Because the only TGID I do not want to turn off a linked TGID is the TGID used to turn it on, I put that in the 2nd list. For example:

MARC Worldwide uses TGID 1 to trigger it on. If any other TGID is used (other than 9, where we run voice traffic) I want it to turn back off - in other words, I want the entire list of TGIDs minus TGID 1 to be the turn-off list. With me so far?

Then in the actual BRIDGES data structure, instead of having to copy big long lists of TGIDs and take out the one TGID to turn that bridge on, I insert the function call instead. You see this below as:

 'OFF': exclude(K0USY_LINKED, [1])

Instead of

‘OFF’:  [2,3,13,91,310,311,3105,3120,3129,3131,3140,31201,31203,31207,98006]

The best part is, that this extra code only runs once when the rules file is imported, so it takes no extra processing at runtime. Well, there it is, tip of the day. I hope it helps someone out there manage their rules file more easily. It sure does help me!

0x49 DE N0MJS


–––-begin paste–––-
K0USY_LINKED = [1,2,3,13,91,310,311,3105,3120,3129,3131,3140,31201,31203,31207,98006]

def exclude(tglist, exlist):
    returnlist = tglist
    for tgid in exlist:
        returnlist = [tg for tg in returnlist if tg != tgid]
    return returnlist

BRIDGES = {
    'MARC: Worldwide': [
            {'SYSTEM': 'K0USY RPTRS',   'TS': 1, 'TGID': 9,    'ACTIVE': False, 'TIMEOUT': LINK_TIME_K0USY, 'TO_TYPE': 'ON',   'ON': [1],     'OFF': exclude(K0USY_LINKED, [1]),    'RESET': [9]},
–––-end paste–––-




Cort Buffington
785-865-7206





Cort Buffington
785-865-7206


Re: Tip of the day...

JJ Cummings
 

I also had a thing that I didn't need in there:

Remove the TMPBRIDGE and change BRIDGE to:
        BRIDGE.update({tgid:export_dict})

in the BuildBridges function


On Fri, Nov 30, 2018 at 12:12 PM JJ Cummings via Groups.Io <cummingsj=gmail.com@groups.io> wrote:
Cort - Nice example that got me thinking!  Here is another example of what one might do to manage larger TG lists if you still want things done per TG etc.... Note that this is a simple example and does _NOT_ account for different TO_TYPE values but could be trivially modified to do such dynamically through the BuildBridges function or just define the custom values by updating the dict later on, like in the below example.

----BEGIN SNIP----

TS1_TGS = [310815,31088,31087]
SYSTEMS = ['MMDVM', 'MOTOTRBO', 'BRANDMEISTER']

def BuildBridges(ts,tgids,systems):
    BRIDGE = {}
    for tgid in tgids:
        export_dict = []
        for system in systems:
            export_dict.append({'SYSTEM': system, 'TS': ts, 'TGID': tgid, 'ACTIVE': True, 'TIMEOUT': {}, 'TO_TYPE': 'NONE',  'ON': [], 'OFF': [], 'RESET': []})
        TMPBRIDGE = {tgid:export_dict}
        BRIDGE.update(TMPBRIDGE)
    return BRIDGE

BRIDGES = BuildBridges(1,TS1_TGS,SYSTEMS)
BRIDGES.update(BuildBridges(2,[311,310,3100,3108],SYSTEMS))
BRIDGES.update({'BM-TAC312': [
           {'SYSTEM': 'BRANDMEISTER',    'TS': 2, 'TGID': 312, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [1312], 'RESET': []},
            {'SYSTEM': 'MMDVM',    'TS': 2, 'TGID': 312, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [1312], 'RESET': []},
            {'SYSTEM': 'IPSC_TS2',    'TS': 2, 'TGID': 312, 'ACTIVE': True, 'TIMEOUT': 5, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}
        ]})

if __name__ == '__main__':
    from pprint import pprint
    pprint(BRIDGES)

----END SNIP----

On Thu, Nov 29, 2018 at 2:02 PM Cort N0MJS via Groups.Io <n0mjs=me.com@groups.io> wrote:
Thought I’d share this with you guys in case anyone is interested.

The K0USY group doesn’t use “channel based” linking, we use “contact based”. This is where you talk on the same TGID all of the time, and only use the other TGIDs for in-band signaling to tell confbridge/hb_confbridge to turn things on and off, etc.

This requires a pretty big list of “off” TGIDs be listed in the BRIDGES section of the confbridge_rules file. One of the reasons I left the rules file a python file instead of an intermediate syntax is to allow using actual python code in it as well. Think of this like the SCOM analog controllers where nearly everything is built on macros, as opposed to the ACC style, where everything is an individual command.

To make things easier for myself, I defined a python list of all of the TGIDs that I use on the linked timeslot (I only use one timeslot for linking). One place to keep track of them all – that’s the first line in the paste below.

Then I wrote a function (that’s the block of code that starts with “def”) that takes two lists as arguments. The first list is the big list of TGIDs I just made, and the second is a list of TGIDs I want removed. Because the only TGID I do not want to turn off a linked TGID is the TGID used to turn it on, I put that in the 2nd list. For example:

MARC Worldwide uses TGID 1 to trigger it on. If any other TGID is used (other than 9, where we run voice traffic) I want it to turn back off - in other words, I want the entire list of TGIDs minus TGID 1 to be the turn-off list. With me so far?

Then in the actual BRIDGES data structure, instead of having to copy big long lists of TGIDs and take out the one TGID to turn that bridge on, I insert the function call instead. You see this below as:

 'OFF': exclude(K0USY_LINKED, [1])

Instead of

‘OFF’:  [2,3,13,91,310,311,3105,3120,3129,3131,3140,31201,31203,31207,98006]

The best part is, that this extra code only runs once when the rules file is imported, so it takes no extra processing at runtime. Well, there it is, tip of the day. I hope it helps someone out there manage their rules file more easily. It sure does help me!

0x49 DE N0MJS


–––-begin paste–––-
K0USY_LINKED = [1,2,3,13,91,310,311,3105,3120,3129,3131,3140,31201,31203,31207,98006]

def exclude(tglist, exlist):
    returnlist = tglist
    for tgid in exlist:
        returnlist = [tg for tg in returnlist if tg != tgid]
    return returnlist

BRIDGES = {
    'MARC: Worldwide': [
            {'SYSTEM': 'K0USY RPTRS',   'TS': 1, 'TGID': 9,    'ACTIVE': False, 'TIMEOUT': LINK_TIME_K0USY, 'TO_TYPE': 'ON',   'ON': [1],     'OFF': exclude(K0USY_LINKED, [1]),    'RESET': [9]},
–––-end paste–––-




Cort Buffington
785-865-7206





Re: Tip of the day...

JJ Cummings
 

Cort - Nice example that got me thinking!  Here is another example of what one might do to manage larger TG lists if you still want things done per TG etc.... Note that this is a simple example and does _NOT_ account for different TO_TYPE values but could be trivially modified to do such dynamically through the BuildBridges function or just define the custom values by updating the dict later on, like in the below example.

----BEGIN SNIP----

TS1_TGS = [310815,31088,31087]
SYSTEMS = ['MMDVM', 'MOTOTRBO', 'BRANDMEISTER']

def BuildBridges(ts,tgids,systems):
    BRIDGE = {}
    for tgid in tgids:
        export_dict = []
        for system in systems:
            export_dict.append({'SYSTEM': system, 'TS': ts, 'TGID': tgid, 'ACTIVE': True, 'TIMEOUT': {}, 'TO_TYPE': 'NONE',  'ON': [], 'OFF': [], 'RESET': []})
        TMPBRIDGE = {tgid:export_dict}
        BRIDGE.update(TMPBRIDGE)
    return BRIDGE

BRIDGES = BuildBridges(1,TS1_TGS,SYSTEMS)
BRIDGES.update(BuildBridges(2,[311,310,3100,3108],SYSTEMS))
BRIDGES.update({'BM-TAC312': [
           {'SYSTEM': 'BRANDMEISTER',    'TS': 2, 'TGID': 312, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [1312], 'RESET': []},
            {'SYSTEM': 'MMDVM',    'TS': 2, 'TGID': 312, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [1312], 'RESET': []},
            {'SYSTEM': 'IPSC_TS2',    'TS': 2, 'TGID': 312, 'ACTIVE': True, 'TIMEOUT': 5, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': [], 'RESET': []}
        ]})

if __name__ == '__main__':
    from pprint import pprint
    pprint(BRIDGES)

----END SNIP----


On Thu, Nov 29, 2018 at 2:02 PM Cort N0MJS via Groups.Io <n0mjs=me.com@groups.io> wrote:
Thought I’d share this with you guys in case anyone is interested.

The K0USY group doesn’t use “channel based” linking, we use “contact based”. This is where you talk on the same TGID all of the time, and only use the other TGIDs for in-band signaling to tell confbridge/hb_confbridge to turn things on and off, etc.

This requires a pretty big list of “off” TGIDs be listed in the BRIDGES section of the confbridge_rules file. One of the reasons I left the rules file a python file instead of an intermediate syntax is to allow using actual python code in it as well. Think of this like the SCOM analog controllers where nearly everything is built on macros, as opposed to the ACC style, where everything is an individual command.

To make things easier for myself, I defined a python list of all of the TGIDs that I use on the linked timeslot (I only use one timeslot for linking). One place to keep track of them all – that’s the first line in the paste below.

Then I wrote a function (that’s the block of code that starts with “def”) that takes two lists as arguments. The first list is the big list of TGIDs I just made, and the second is a list of TGIDs I want removed. Because the only TGID I do not want to turn off a linked TGID is the TGID used to turn it on, I put that in the 2nd list. For example:

MARC Worldwide uses TGID 1 to trigger it on. If any other TGID is used (other than 9, where we run voice traffic) I want it to turn back off - in other words, I want the entire list of TGIDs minus TGID 1 to be the turn-off list. With me so far?

Then in the actual BRIDGES data structure, instead of having to copy big long lists of TGIDs and take out the one TGID to turn that bridge on, I insert the function call instead. You see this below as:

 'OFF': exclude(K0USY_LINKED, [1])

Instead of

‘OFF’:  [2,3,13,91,310,311,3105,3120,3129,3131,3140,31201,31203,31207,98006]

The best part is, that this extra code only runs once when the rules file is imported, so it takes no extra processing at runtime. Well, there it is, tip of the day. I hope it helps someone out there manage their rules file more easily. It sure does help me!

0x49 DE N0MJS


–––-begin paste–––-
K0USY_LINKED = [1,2,3,13,91,310,311,3105,3120,3129,3131,3140,31201,31203,31207,98006]

def exclude(tglist, exlist):
    returnlist = tglist
    for tgid in exlist:
        returnlist = [tg for tg in returnlist if tg != tgid]
    return returnlist

BRIDGES = {
    'MARC: Worldwide': [
            {'SYSTEM': 'K0USY RPTRS',   'TS': 1, 'TGID': 9,    'ACTIVE': False, 'TIMEOUT': LINK_TIME_K0USY, 'TO_TYPE': 'ON',   'ON': [1],     'OFF': exclude(K0USY_LINKED, [1]),    'RESET': [9]},
–––-end paste–––-




Cort Buffington
785-865-7206





Re: ASL <> D-Star

Steven Blackford
 

Hey Russel,

    I run an additional DMR <->D-Star bridge on the Carolina Link on Tues/Sat nights.  Here’s the MMDVM.ini setup info for D-Star:

 

[D-Star Network]

Enable=1

GatewayAddress=192.168.0.250

GatewayPort=20010

LocalPort=20012

Debug=0

 

 

In the D-Star section, you need to point the GatewayAddress & GatewayPort to where you have your ircDDBGateway running.  In the above, I have one instance of ircDDBGateway running on a different PI2.  It’s where I have a DVAP setup.  It’s easy enough to have more than one “device” setup in ircDDBGateway.  In your ircDDBGateway you need to point your module to where the “new device” is running so here’s the section of ircDDBGateway:

 

repeaterCall2=

repeaterBand2=D

repeaterType2=0

repeaterAddress2=192.168.0.240

repeaterPort2=20012

reflector2=

atStartup2=0

reconnect2=0

frequency2=0.00000

offset2=0.0000

rangeKms2=0.000

 

I use “repeater 2” in ircDDBGateway for the additional bridge.   The bridge is ran on an ODroid C1 w/ the IP of 192.168.0.240.  ircDDBGateway is running on a PI2 w/ the IP of 192.168.0.250.  Make sense?  Hope that helps.  73 de K4SQI!

 

Steve, K4SQI

 

Sent from Mail for Windows 10

 

From: Russell, KV4S
Sent: Friday, November 30, 2018 12:13 PM
To: main@dvswitch.groups.io
Subject: [DVSwitch] ASL <> D-Star

 

I just started a new project for a D-STAR to ASL bridge.

If anyone has done this before can you send me an example MMDVM_Bridge.ini?

if not can someone point me in the right direction? around the settings for network and ircdbb?

 

also, in the analog bridge ini does this look right?

; Information for xx_Bridges (Where xx is MMDVM, HB, IPSC)

[AMBE_AUDIO]

server = 127.0.0.1                      ; IP address of xx_Bridge.py

fromDMRPort = 32100                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" in x$

toDMRPort = 32103                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort" in$

ambeMode = DSTAR                        ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW

minTxTimeMS = 2000                      ; Minimum time in MS for hang delay

gatewayDmrId = 3136665                  ; ID to use when transmitting from Analog_Bridge

repeaterID = 313666508                  ; ID of source repeater

txTg = XRF749D                          ; TG to use for all frames received from Analog_Bridge -> xx_Br$

txTs = 2                                ; Slot to use for frames received from Analog_Bridge -> xx_Brid$

colorCode = 1                           ; Color Code to assign DMR frames

 


ASL <> D-Star

 

I just started a new project for a D-STAR to ASL bridge.
If anyone has done this before can you send me an example MMDVM_Bridge.ini?
if not can someone point me in the right direction? around the settings for network and ircdbb?

also, in the analog bridge ini does this look right?
; Information for xx_Bridges (Where xx is MMDVM, HB, IPSC)
[AMBE_AUDIO]
server = 127.0.0.1                      ; IP address of xx_Bridge.py
fromDMRPort = 32100                     ; AMBE frames from xx_Bridge (should match "toGatewayPort" in x$
toDMRPort = 32103                       ; AMBE frames from xx_Bridge (should match "fromGatewayPort" in$
ambeMode = DSTAR                        ; DMR, DMR_IPSC, DSTAR, NXDN, P25, YSFN, YSFW
minTxTimeMS = 2000                      ; Minimum time in MS for hang delay
gatewayDmrId = 3136665                  ; ID to use when transmitting from Analog_Bridge
repeaterID = 313666508                  ; ID of source repeater
txTg = XRF749D                          ; TG to use for all frames received from Analog_Bridge -> xx_Br$
txTs = 2                                ; Slot to use for frames received from Analog_Bridge -> xx_Brid$
colorCode = 1                           ; Color Code to assign DMR frames


Re: Is this even possible?

Cort N0MJS <n0mjs@...>
 

Inline --

On Nov 29, 2018, at 4:33 PM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Fully understand, and wasn't pushing,

Great, because I didn’t think you were :)

just wondering around OpenBridge as a philosophy, but checking the code, it seems that its only implemented in the big networks on slot 1.

Not exactly. OpenBridge allows sending an arbitrary number of call streams simultaneously. There’s no concept of “timeslot” because of that, so they just clear the TS bit in the header…. A cleared TS bit just happens to correspond to TS1. That means the packets are going to look like TS1 and I have to treat them that way, i.e. re-write the TS bit if a call stream is destined for TS2.

In the UK we do international/national on S1 and regional on S2, so it probably won't make difference to my current design.

Again, think of OpenBridge as a server to server protocol that doesn’t have a timeslot.

Can I ask if you or any of the others do anything with DMR data,

So far I’ve not been able to satisfy the group voice to-do list and have enough time to work with subscriber-to subscriber voice or data.

I've been asked about routing GPS, and although I've done some tests with a Moto into bridge.py,on DMRkink with rules for private data, it doesn't seem to route the traffic.

It was never completed and shouldn’t be expected to work as it is.

I maybe doing something wrong, or that its not been fully implemented.

Correct, never even remotely fully implemented.

I'm trying to route this up stream to a DMR+ IPSC2, who do push on these private TG5057 messages to APRS.fi
As I understand it, your radio when configured for GPS, sends the data as a private call to 5057 on whatever routed TG your using.  Again, I'm not sure if private calls are supported either.
Any pointers, or just info as to whether its worth continuing testing would be useful.

Group Voice is the only thing functional.

Thanks
Peter





Sent from Outlook
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 27 November 2018 00:30:46
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Is this even possible?
 
To make DMRlink use OpenBridge requires all of the same internals as IPSC_Bridge.py and HB_Bridge.py. OpenBridge is based on the Home-brew Repeater Protocol. It was reasonable to incorporate it into HBlink because of that.

DMRlink is probably going to be #2 now. I just did a LOT of work with HBlink… I can trickle those changes into DMRlink over time, but like all of you, I’m also running a pretty sizable repeater network too. So just remember, I’m doing that AND trying to write the software. So go easy on me guys :)


On Nov 26, 2018, at 5:32 PM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Reference the below, can I ask is OpenBridge not compatible with DMRlink, or just that you've made the decision to not implement?

As you know I've always kept DMRlink as the core routing for the network, linking out using IPSCBridge / HBlink as needed to bring in the odd MMDVM box, and its served me well, as the bulk of my connections are moto IPSC.

I see OpenBridge as a super way to link networks, and would like to try this, at present I have one link per repeater upstream, and bridge the traffic, so OpenBridge would be a good win.

So I'm contemplating, do I move to HBLink as the centre, and use IPSCBridge for the motos to gain the benefits?

Regards
Peter


Cort Buffington
785-865-7206


Re: Strange announcement after each keyup after about a day of running

Chris WB4ULK
 

Yeah,
Steve figured it out.
It’s a timer you have to set up to at least 2500 milliseconds.

I think it is in analogbridge.ini

Anyway, the message was coming from BM saying “Blocked”

It is a loop back detector that is getting tripped. Upping that time keeps it from doing that.

I think the thread got moved over to support. Look in there.

Fixed my prob and no issues since.

Chris
WB4ULK 

On Nov 29, 2018, at 4:57 PM, KM6IRY <casper14209@...> wrote:

Hey there Chris, long time and funny running into you here.

Just setup a bridge here as well and have run into the same thing. Kicking services on and off narrowed it down to being on the MMDVM Bridge side but still not sure where it's coming from. Have you had any advancements on this or does anybody have any info to share?

Vince


Re: Is this even possible?

Peter M0NWI
 

Hi Cort,

Fully understand, and wasn't pushing, just wondering around OpenBridge as a philosophy, but checking the code, it seems that its only implemented in the big networks on slot 1.  In the UK we do international/national on S1 and regional on S2, so it probably won't make difference to my current design.

Can I ask if you or any of the others do anything with DMR data, I've been asked about routing GPS, and although I've done some tests with a Moto into bridge.py,on DMRkink with rules for private data, it doesn't seem to route the traffic.  I maybe doing something wrong, or that its not been fully implemented. I'm trying to route this up stream to a DMR+ IPSC2, who do push on these private TG5057 messages to APRS.fi

As I understand it, your radio when configured for GPS, sends the data as a private call to 5057 on whatever routed TG your using.  Again, I'm not sure if private calls are supported either.

Any pointers, or just info as to whether its worth continuing testing would be useful.

Thanks
Peter





Sent from Outlook
From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 27 November 2018 00:30:46
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Is this even possible?
 
To make DMRlink use OpenBridge requires all of the same internals as IPSC_Bridge.py and HB_Bridge.py. OpenBridge is based on the Home-brew Repeater Protocol. It was reasonable to incorporate it into HBlink because of that.

DMRlink is probably going to be #2 now. I just did a LOT of work with HBlink… I can trickle those changes into DMRlink over time, but like all of you, I’m also running a pretty sizable repeater network too. So just remember, I’m doing that AND trying to write the software. So go easy on me guys :)


On Nov 26, 2018, at 5:32 PM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Reference the below, can I ask is OpenBridge not compatible with DMRlink, or just that you've made the decision to not implement?

As you know I've always kept DMRlink as the core routing for the network, linking out using IPSCBridge / HBlink as needed to bring in the odd MMDVM box, and its served me well, as the bulk of my connections are moto IPSC.

I see OpenBridge as a super way to link networks, and would like to try this, at present I have one link per repeater upstream, and bridge the traffic, so OpenBridge would be a good win.

So I'm contemplating, do I move to HBLink as the centre, and use IPSCBridge for the motos to gain the benefits?

Regards
Peter


Tip of the day...

Cort N0MJS <n0mjs@...>
 

Thought I’d share this with you guys in case anyone is interested.

The K0USY group doesn’t use “channel based” linking, we use “contact based”. This is where you talk on the same TGID all of the time, and only use the other TGIDs for in-band signaling to tell confbridge/hb_confbridge to turn things on and off, etc.

This requires a pretty big list of “off” TGIDs be listed in the BRIDGES section of the confbridge_rules file. One of the reasons I left the rules file a python file instead of an intermediate syntax is to allow using actual python code in it as well. Think of this like the SCOM analog controllers where nearly everything is built on macros, as opposed to the ACC style, where everything is an individual command.

To make things easier for myself, I defined a python list of all of the TGIDs that I use on the linked timeslot (I only use one timeslot for linking). One place to keep track of them all – that’s the first line in the paste below.

Then I wrote a function (that’s the block of code that starts with “def”) that takes two lists as arguments. The first list is the big list of TGIDs I just made, and the second is a list of TGIDs I want removed. Because the only TGID I do not want to turn off a linked TGID is the TGID used to turn it on, I put that in the 2nd list. For example:

MARC Worldwide uses TGID 1 to trigger it on. If any other TGID is used (other than 9, where we run voice traffic) I want it to turn back off - in other words, I want the entire list of TGIDs minus TGID 1 to be the turn-off list. With me so far?

Then in the actual BRIDGES data structure, instead of having to copy big long lists of TGIDs and take out the one TGID to turn that bridge on, I insert the function call instead. You see this below as:

'OFF': exclude(K0USY_LINKED, [1])

Instead of

‘OFF’: [2,3,13,91,310,311,3105,3120,3129,3131,3140,31201,31203,31207,98006]

The best part is, that this extra code only runs once when the rules file is imported, so it takes no extra processing at runtime. Well, there it is, tip of the day. I hope it helps someone out there manage their rules file more easily. It sure does help me!

0x49 DE N0MJS


–––-begin paste–––-
K0USY_LINKED = [1,2,3,13,91,310,311,3105,3120,3129,3131,3140,31201,31203,31207,98006]

def exclude(tglist, exlist):
returnlist = tglist
for tgid in exlist:
returnlist = [tg for tg in returnlist if tg != tgid]
return returnlist

BRIDGES = {
'MARC: Worldwide': [
{'SYSTEM': 'K0USY RPTRS', 'TS': 1, 'TGID': 9, 'ACTIVE': False, 'TIMEOUT': LINK_TIME_K0USY, 'TO_TYPE': 'ON', 'ON': [1], 'OFF': exclude(K0USY_LINKED, [1]), 'RESET': [9]},
–––-end paste–––-




Cort Buffington
785-865-7206


Re: Is this even possible?

Cort N0MJS <n0mjs@...>
 

To make DMRlink use OpenBridge requires all of the same internals as IPSC_Bridge.py and HB_Bridge.py. OpenBridge is based on the Home-brew Repeater Protocol. It was reasonable to incorporate it into HBlink because of that.

DMRlink is probably going to be #2 now. I just did a LOT of work with HBlink… I can trickle those changes into DMRlink over time, but like all of you, I’m also running a pretty sizable repeater network too. So just remember, I’m doing that AND trying to write the software. So go easy on me guys :)


On Nov 26, 2018, at 5:32 PM, Peter M0NWI <peter-martin@...> wrote:

Hi Cort,

Reference the below, can I ask is OpenBridge not compatible with DMRlink, or just that you've made the decision to not implement?

As you know I've always kept DMRlink as the core routing for the network, linking out using IPSCBridge / HBlink as needed to bring in the odd MMDVM box, and its served me well, as the bulk of my connections are moto IPSC.

I see OpenBridge as a super way to link networks, and would like to try this, at present I have one link per repeater upstream, and bridge the traffic, so OpenBridge would be a good win.

So I'm contemplating, do I move to HBLink as the centre, and use IPSCBridge for the motos to gain the benefits?

Regards
Peter


Re: Is this even possible?

Peter M0NWI
 

Hi Cort,

Reference the below, can I ask is OpenBridge not compatible with DMRlink, or just that you've made the decision to not implement?

As you know I've always kept DMRlink as the core routing for the network, linking out using IPSCBridge / HBlink as needed to bring in the odd MMDVM box, and its served me well, as the bulk of my connections are moto IPSC.

I see OpenBridge as a super way to link networks, and would like to try this, at present I have one link per repeater upstream, and bridge the traffic, so OpenBridge would be a good win.

So I'm contemplating, do I move to HBLink as the centre, and use IPSCBridge for the motos to gain the benefits?

Regards
Peter


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Cort N0MJS via Groups.Io <n0mjs@...>
Sent: 24 November 2018 00:53:38
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Is this even possible?
 
When I started this, there was DMRlink – MMDVM didn’t yet exist. After I wrote HBlink, I still developed on DMRlink first, and then ported changes to HBlink, but have kept pretty good parity between both of them.

As of now, I’d say the best determining factor would be what kind of repeaters do you have more of? Motorola or MMDVM? That’s the advice I typically give. If you’re predominantly a Motorola operation, then use DMRlink’s confbridge.py as the main hub; if MMDVM, then use hb_confbridge.py.

But this is about to change. Going forward, now that HBlink has OpenBridge support, HBlink will be what gets developed first – and at some point, I may even sunset further development on DMRlink applications (e.g. confbridge.py). Using multiple IPSC connections to a c-Bridge to pick up TGIDs (or multiple HBP connections to Brandmeister, etc.) is cumbersome. OpenBridge allows “server-to-server” type access to Brandmeister, DMR-MARC and DMR+, and that’s my reason for shifting primary development (and there’s about to be quite a bit of it) to HBlink first.

I’d like to see a few improvements in IPSC_Bridge, and hopefully can contribute to them. Even on K0USY Group’s systems, it looks like the future will be trading out our XPR series repeaters for MMDMV-based ones, or putting a “backpack” on each one (SBC running IPSC_Bridge/HB_Bridge) and converting them all to Homebrew at the repeater site. I’ll likely keep one XPR for DMRlink development, but that’s probably it.

0x49 DE N0MJS

P.S. - if anyone is in the market for lightly used (I run the power at 25W on them and NEVER burn up PAs that way) K0USY Group will soon have a number of XPR8300s and XPR8400s available for sale or trade for MTR2000s.

On Nov 23, 2018, at 6:14 PM, Jim Gifford - KD4PPG <jim@...> wrote:

In terms of setting up confbridge, which is preferred to work with, the one in dmrlink or the one in hblink?  Ultimately, I want one of those to be the primary decision maker in the “center” of it all.  With the link to BM being the most number of talkgroups, I’m leaning towards the hblink one as the one to use.

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






Re: Installing DVSwitch

Guillermo HK4KM <hk4km@...>
 

Thanks, Steve.  Will do.


Re: Is this even possible?

Jim Gifford - K9AGR
 

Cort,

Thanks for this answer.  I spent the weekend pondering your answer and the implications, and picturing in my head how I should proceed.  At this point, I’m going to stick with hb_confbridge, because of the reasoning you gave, and connect everything else over to that core component.

Thanks,
Jim


On Nov 23, 2018, at 7:53 PM, Cort N0MJS via Groups.Io <n0mjs@...> wrote:

When I started this, there was DMRlink – MMDVM didn’t yet exist. After I wrote HBlink, I still developed on DMRlink first, and then ported changes to HBlink, but have kept pretty good parity between both of them.

As of now, I’d say the best determining factor would be what kind of repeaters do you have more of? Motorola or MMDVM? That’s the advice I typically give. If you’re predominantly a Motorola operation, then use DMRlink’s confbridge.py as the main hub; if MMDVM, then use hb_confbridge.py.

But this is about to change. Going forward, now that HBlink has OpenBridge support, HBlink will be what gets developed first – and at some point, I may even sunset further development on DMRlink applications (e.g. confbridge.py). Using multiple IPSC connections to a c-Bridge to pick up TGIDs (or multiple HBP connections to Brandmeister, etc.) is cumbersome. OpenBridge allows “server-to-server” type access to Brandmeister, DMR-MARC and DMR+, and that’s my reason for shifting primary development (and there’s about to be quite a bit of it) to HBlink first.

I’d like to see a few improvements in IPSC_Bridge, and hopefully can contribute to them. Even on K0USY Group’s systems, it looks like the future will be trading out our XPR series repeaters for MMDMV-based ones, or putting a “backpack” on each one (SBC running IPSC_Bridge/HB_Bridge) and converting them all to Homebrew at the repeater site. I’ll likely keep one XPR for DMRlink development, but that’s probably it.

0x49 DE N0MJS

P.S. - if anyone is in the market for lightly used (I run the power at 25W on them and NEVER burn up PAs that way) K0USY Group will soon have a number of XPR8300s and XPR8400s available for sale or trade for MTR2000s.

On Nov 23, 2018, at 6:14 PM, Jim Gifford - KD4PPG <jim@...> wrote:

In terms of setting up confbridge, which is preferred to work with, the one in dmrlink or the one in hblink?  Ultimately, I want one of those to be the primary decision maker in the “center” of it all.  With the link to BM being the most number of talkgroups, I’m leaning towards the hblink one as the one to use.

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






7101 - 7120 of 9595