Date   

Re: ASL playback and morse distorted when bridge is running

Steve N4IRS
 

Let me see if I understand this.
You have a public node connected to a radio / repeater.
You have a private node setup for DMR.
Public node is NOT connected private node.
Morse, telemetry tones and audio files distorted audio as heard out the radio transmitter.
Kill any of the bridge program, audio on radio clears up.

Hardware or software Vocoder?
Do you kill a DVSwith program or restart the program?
CPU usage as reported high?

Steve N4IRS 

On 12/4/18 2:55 AM, va3dxv wrote:
Hi folks,

I have ASL running on a Raspberry Pi 3B+ and 3B at two sites. Both running DVSwitch for DMR on a private node.

I've started noticing choppy/distorted sounding morse ID's and audio file playback. To the point where an 800hz morse tone sounds like a buzz, not a tone.

This happens whether the private node is connected to the main node or not. ASL audio over the network seems to still be OK.

I've found that when I kill any one of the bridge or md380emu processes, the audio immediately clears up.

Has anyone else experienced this?

Thank you


Re: P25 -> MMDVM_Bridge question

Rob WX1N
 

Okay, that helps - thank you!!!

-----Original Message-----
From: main@DVSwitch.groups.io [mailto:main@DVSwitch.groups.io] On Behalf Of Steve N4IRS
Sent: Sunday, December 02, 2018 7:24 PM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] P25 -> MMDVM_Bridge question

OK,
So it can look like this:
MMDVM_Host <-> P25Gateway(1) <-> P25Reflector <-> P25Gateway(2) <->
MMDVM_Bridge(a) <-> Analog_Bridge(1) <-> Analog_Bridge(2) <->
MMDVM_Bridge(b) <-> BrandMeister

You will need 2 copies of P25Gateway. Since you can not reuse the same
ports, you will need to change the ports used for P25Gateway(2) <->
MMDVM_Bridge
You can use a singe copy of MMDVM_Bridge. MMDVM_Bridge(a) would be the
P25 connection and MMDVM_Bridge(b) would be the DMR connection.
You will need 2 copies of Analog_Bridge. Analog_Bridge(1) would be
configured for P25 and Analog_Bridge(2) would be configured for DMR. The
connection between the 2 copies of Analog_Bridge would be cross
connected via the [USRP] stanza.

It might be easier to build from BrandMeister towards the P25Reflector.
Run each program in the foreground and watch the data flow. When a
section works, move on to the next section.

Steve N4IRS

On 12/2/18 7:05 PM, Rob WX1N wrote:
Hi Steve,

My end goal is to bridge an MMDVM P25 repeater to a BrandMeister DMR talkgroup.

I was trying to set up the P25->MMDVM_Bridge side of the equation with P25Reflector as the info I came across while searching showed this connection path.

Rob



Re: P25 -> MMDVM_Bridge question

Steve N4IRS
 

OK,
So it can look like this:
MMDVM_Host <-> P25Gateway(1) <-> P25Reflector <-> P25Gateway(2) <-> MMDVM_Bridge(a) <-> Analog_Bridge(1) <-> Analog_Bridge(2) <-> MMDVM_Bridge(b) <-> BrandMeister

You will need 2 copies of P25Gateway. Since you can not reuse the same ports, you will need to change the ports used for P25Gateway(2) <-> MMDVM_Bridge
You can use a singe copy of MMDVM_Bridge. MMDVM_Bridge(a) would be the P25 connection and MMDVM_Bridge(b) would be the DMR connection.
You will need 2 copies of Analog_Bridge. Analog_Bridge(1) would be configured for P25 and Analog_Bridge(2) would be configured for DMR. The connection between the 2 copies of Analog_Bridge would be cross connected via the [USRP] stanza.

It might be easier to build from BrandMeister towards the P25Reflector. Run each program in the foreground and watch the data flow. When a section works, move on to the next section.

Steve N4IRS

On 12/2/18 7:05 PM, Rob WX1N wrote:
Hi Steve,

My end goal is to bridge an MMDVM P25 repeater to a BrandMeister DMR talkgroup.

I was trying to set up the P25->MMDVM_Bridge side of the equation with P25Reflector as the info I came across while searching showed this connection path.

Rob


Re: P25 -> MMDVM_Bridge question

Rob WX1N
 

Hi Steve,

My end goal is to bridge an MMDVM P25 repeater to a BrandMeister DMR talkgroup.

I was trying to set up the P25->MMDVM_Bridge side of the equation with P25Reflector as the info I came across while searching showed this connection path.

Rob


Re: P25 -> MMDVM_Bridge question

Steve N4IRS
 

Rob,
In the simplest terms, what are you trying to do? What is the end result you are trying to accomplish? You may not need the reflector.

Steve n4IRS

On 12/2/18 6:21 PM, Rob WX1N wrote:
Good evening all,

I'm starting to slowly peck away at a P25 to DMR bridge, and learning as I go. I'm starting from the P25 end and working in towards MMDVM_Bridge. Can anyone confirm that the order is as follows?
MMDVM running P25 -> P25 Gateway -> P25 Reflector -> MMDVM_Bridge

The default ports do not seem to be set up for this, and I am having trouble getting P25 reflector to pass traffic to MMDVM_Bridge, so I wanted to confirm.

The ports I'm using are as follows:
MMDVM P25 network ports:
Gateway 42020
Local 32010

P25Gateway:
Local 42020 (matches MMDVM Gateway)
Rptr 32010 (matches MMDVM Local)
Hosts file 127.0.0.1 Port 41000 (port for Reflector)

P25Reflector:
Port 41000 (matches host file in Gateway)

MMDVM_Bridge:
P25 Network - defaults to 42020 and 32010, which would connect it to the Gateway not the reflector (and would conflict with the MMDVM I think?)
So I'm trying Gateway=41000 (Reflector), and Local=32011 (shouldn't need to match anything, just be a discrete port, correct?)

A P25 transmission shows in P25Reflector, which I believe indicates that the first 3 steps are set up correctly, but nothing shows in MMDVM_Bridge.

Any thoughts or help would be appreciated!

73,

Rob, WX1N


P25 -> MMDVM_Bridge question

Rob WX1N
 

Good evening all,

I'm starting to slowly peck away at a P25 to DMR bridge, and learning as I go. I'm starting from the P25 end and working in towards MMDVM_Bridge. Can anyone confirm that the order is as follows?
MMDVM running P25 -> P25 Gateway -> P25 Reflector -> MMDVM_Bridge

The default ports do not seem to be set up for this, and I am having trouble getting P25 reflector to pass traffic to MMDVM_Bridge, so I wanted to confirm.

The ports I'm using are as follows:
MMDVM P25 network ports:
Gateway 42020
Local 32010

P25Gateway:
Local 42020 (matches MMDVM Gateway)
Rptr 32010 (matches MMDVM Local)
Hosts file 127.0.0.1 Port 41000 (port for Reflector)

P25Reflector:
Port 41000 (matches host file in Gateway)

MMDVM_Bridge:
P25 Network - defaults to 42020 and 32010, which would connect it to the Gateway not the reflector (and would conflict with the MMDVM I think?)
So I'm trying Gateway=41000 (Reflector), and Local=32011 (shouldn't need to match anything, just be a discrete port, correct?)

A P25 transmission shows in P25Reflector, which I believe indicates that the first 3 steps are set up correctly, but nothing shows in MMDVM_Bridge.

Any thoughts or help would be appreciated!

73,

Rob, WX1N


ASL <-> XLX No analog audio?

Steve KC1AWV
 

Hi everyone,

I apologize if someone else has already brought up / solved this situation, however I am experiencing some issues with analog audio from Allstar making it all the way through to XLX.

Digital audio from a hotspot or repeater into XLX makes it's way over to the ASL hub with no issues, and the audio quality is great. The conversations can be heard using Android IAXRPT, Echolink, and autopatch.

Analog audio on the ASL hub can be heard on the hub on Android IAXRPT, Echolink, and autopatch.

When analog audio is sent to ASL, it is picked up locally on a private node that pushes it up to USRP, is then sent to Analog_Bridge, then MMDVM_Bridge, and finally to DMRGateway to XLX. The logic seems sound, and I can see the traffic from ASL to XLX passing as intended. However, devices attached to XLX only receive for a second or two, and then stop, regardless of what is happening on ASL. The radios on the digital side will receive data, but very quickly stop. Pi-Star also shows that it's receiving data from XLX, but only very shortly.

I've tried a milliwatt test and a parrot on the node that connects through to XLX. The milliwatt test cannot be heard, and the parrot has the same result as a user transmitting analog audio to ASL.

Equipment under test is as follows:

Analog:
Android phone running Android IAXRPT
SIP phone to private PBX dialing autopach to ASL
Android phone running Echolink

Digital:
Zumspot Pi-Star #1 running DMRGateway
Zumspot Pi-Star #2 running ircDDBGateway
Icom ID-51a HT
Hytera AR482G HT

I've included a diagram of a high level overview of the way I have the system set up. If a copy paste of the config files are needed, I can send that up as well.

I appreciate any help! Thank you!

- Steve KC1AWV


Re: A couple of items over the past week

Mike AE4ML
 

GIve me about a week and I'll share them,

Thanks Steve,

That parrot issue is very strange. The one site has no internet but I have a VHF & UHF quantar up there. I have the setup to allow me to talk from one to another and also Parrot .

Without a time sync from an internet connection I was wondering if that could be playing a part in this.   Yes I know we are only fishing right now. Logs will tell.

Mike


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
 

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

6701 - 6720 of 9203