1. main@DVSwitch.groups.io
  2. Messages
   Date   
Re: Link DMR <==> FCSXXX

Bruno
 

Hi,

Here are the files used to set up this configuration.
YSFGateway Local that connects FCS001 33
MMDVM_Bridge making DMR connection BM <=> YSF
Port 35100 and 35103
The MMDVM logs are good with the good indicative
This is found at the PI-Star interface which is connected to the FCS001 33 on the receiving OM that arrives from the DMR BM.
 
73's
F1PTL Bruno

?
MMDVM_FCS00133.tar
?
YSFGateway.ini

Re: Is this even possible?

Corey Dean N3FE <n3fe@...>
 

Now that openbridge is released I may be able to help out some here.  I have about 15-20 talkgroups from bm 3102 feeding hblink using openbridge.  I then have a link into my cbridge carrying Delmarva 8802, then I also have a backup system of hblink with all of those coming across it.  My home brew repeaters connect directly to hblink and the 8300 repeaters use IPSec bridge / hb bridge to connect to hblink.  I have been running it this way for a few months with no trouble at all!

If I need another talkgroup from the cbridge or bm it is very easy to add.  On openbridge all I need to know is the talkgroup I’d, enter it in and you have it right away.  Think of it as a cbridge cclink with out the need for a lid.

Corey n3fe

On Tue, Dec 4, 2018 at 8:28 PM JJ Cummings <cummingsj@...> wrote:
Jim, you can do what you want to do now with the use of HBLink, DMRLink, HB_Bridge and IPSC_Bridge as follows:

hb_confbridge <-> Brandmeister (for BM TGs)
hb_confbridge <-> hb_bridge <-> ipsc_bridge <-> confbridge (for CBridge interfacing and interfacing to motorola repeaters)

hb_confbridge is a single instance of hb_confbridge.py from HBLink
confbridge is a single instance of confbridge.py from DMRLink
ipsc_bridge and hb_bridge are the respective single instances of the .py files from IPSC_Bridge and HB_Bridge.

All that you have to do is configure the respective _rules.py files to determine what TGs are allowed to go to what system, simply excluding TG8802 from your Brandmeister stanza in said file will do it.

JJC
N0PKT

On Tue, Dec 4, 2018 at 1:56 PM Jim Gifford - KD4PPG <jim@...> wrote:
A lot has happened in the last few weeks.  Most critically, the OpenBridge branch merged back into the master branch, bringing with it new goodies to play with, namely ACLs!

Additionally, I've stopped trying to conflate my needs with the needs of the other repeater operator, instead treating each as a unique problem to be solved.  Since his is closer to being on the air, I'm focusing on that.  I'm hoping for OpenBridge to be the answer to my own setup in the near future.

Basic premise: new (used) repeater, VHF, XPR8400, 147.210 +, CC1,  antenna at 300' on a county tower, owner: N4TIK (Ken), trustee: W0ADD (Al).

Ken and Al would prefer their repeater have the sysop level of control provided by Brandmeister rather than being on a cBridge and having to pester the bridge operator for changes.  However, they also want to carry the DelMarVa (8802) talkgroup, primarily for coordination across the region during EmComm scenarios, which is only carried on cBridges currently.

For policy reasons, 8802 will not be carried by BM.

The repeater is operational, barring some issues with the duplexer.  It's connected to BM currently, and operating as the owner and trustee wish it to, although lacking the 8802 talkgroup.

Existing configuration:

I think that with the advent of ACLs, I can insert a DVSwitch suite in between the XPR8400 and the BM3102 server.  I can use the ACLs to deny 8802 from going to BM3102, and also to permit only 8802 on TS1 going to/from K4USD.

Proposed configuration:


In this proposal, the IPSC_Bridge <-> BM3102 link would be using the N4TIK DMR ID # 310328, so would look the same as the existing repeater.

Does anyone see anything wrong with this approach?

Yes, I know BM supports HB directly, but I don't know what's involved with changing from the current IPSC connection to an HB connection, ie will BM even care? Is it a different port?  For that matter, I don't *know* that the IPSC_Bridge <->BM3102 link will function correctly.   Any advice on this point is very welcome.

Thanks in advance,
Jim

PS, hooray for ACLs!

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

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG
Re: Is this even possible?

JJ Cummings
 

Jim, you can do what you want to do now with the use of HBLink, DMRLink, HB_Bridge and IPSC_Bridge as follows:

hb_confbridge <-> Brandmeister (for BM TGs)
hb_confbridge <-> hb_bridge <-> ipsc_bridge <-> confbridge (for CBridge interfacing and interfacing to motorola repeaters)

hb_confbridge is a single instance of hb_confbridge.py from HBLink
confbridge is a single instance of confbridge.py from DMRLink
ipsc_bridge and hb_bridge are the respective single instances of the .py files from IPSC_Bridge and HB_Bridge.

All that you have to do is configure the respective _rules.py files to determine what TGs are allowed to go to what system, simply excluding TG8802 from your Brandmeister stanza in said file will do it.

JJC
N0PKT

On Tue, Dec 4, 2018 at 1:56 PM Jim Gifford - KD4PPG <jim@...> wrote:
A lot has happened in the last few weeks.  Most critically, the OpenBridge branch merged back into the master branch, bringing with it new goodies to play with, namely ACLs!

Additionally, I've stopped trying to conflate my needs with the needs of the other repeater operator, instead treating each as a unique problem to be solved.  Since his is closer to being on the air, I'm focusing on that.  I'm hoping for OpenBridge to be the answer to my own setup in the near future.

Basic premise: new (used) repeater, VHF, XPR8400, 147.210 +, CC1,  antenna at 300' on a county tower, owner: N4TIK (Ken), trustee: W0ADD (Al).

Ken and Al would prefer their repeater have the sysop level of control provided by Brandmeister rather than being on a cBridge and having to pester the bridge operator for changes.  However, they also want to carry the DelMarVa (8802) talkgroup, primarily for coordination across the region during EmComm scenarios, which is only carried on cBridges currently.

For policy reasons, 8802 will not be carried by BM.

The repeater is operational, barring some issues with the duplexer.  It's connected to BM currently, and operating as the owner and trustee wish it to, although lacking the 8802 talkgroup.

Existing configuration:

I think that with the advent of ACLs, I can insert a DVSwitch suite in between the XPR8400 and the BM3102 server.  I can use the ACLs to deny 8802 from going to BM3102, and also to permit only 8802 on TS1 going to/from K4USD.

Proposed configuration:


In this proposal, the IPSC_Bridge <-> BM3102 link would be using the N4TIK DMR ID # 310328, so would look the same as the existing repeater.

Does anyone see anything wrong with this approach?

Yes, I know BM supports HB directly, but I don't know what's involved with changing from the current IPSC connection to an HB connection, ie will BM even care? Is it a different port?  For that matter, I don't *know* that the IPSC_Bridge <->BM3102 link will function correctly.   Any advice on this point is very welcome.

Thanks in advance,
Jim

PS, hooray for ACLs!

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

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG
Re: Link DMR <==> FCSXXX

Steve N4IRS
 

Bruno,
We need to see your MMDVM_Bridge.ini and DVSwitch.ini It would also help to see the log when MMDVM_Bridge is running and the transmission occurs.

Steve N4IRS

On 12/4/18 4:37 PM, Bruno wrote:
Hi,
it works between the FCS001 33 and the DMR BM. On the other hand at the level of the PI-Star or OpenSpot2 the callback that goes back to the level of traffic and still N4IRR ???
I do not know why ??
 
73's
F1PTL Bruno
Re: Link DMR <==> FCSXXX

Bruno
 

Starting logging, please wait...
M: 2018-12-04 21:39:55.381 YSF, network watchdog has expired, 152.4 seconds, 0% packet loss, BER: 0.0%
M: 2018-12-04 21:39:58.946 YSF, received network data from N4IRR to ALL at FCS001-33 
Re: Link DMR <==> FCSXXX

Bruno
 

Hi,
it works between the FCS001 33 and the DMR BM. On the other hand at the level of the PI-Star or OpenSpot2 the callback that goes back to the level of traffic and still N4IRR ???
I do not know why ??
 
73's
F1PTL Bruno
Re: Is this even possible?

Jim Gifford - K9AGR
 

A lot has happened in the last few weeks.  Most critically, the OpenBridge branch merged back into the master branch, bringing with it new goodies to play with, namely ACLs!

Additionally, I've stopped trying to conflate my needs with the needs of the other repeater operator, instead treating each as a unique problem to be solved.  Since his is closer to being on the air, I'm focusing on that.  I'm hoping for OpenBridge to be the answer to my own setup in the near future.

Basic premise: new (used) repeater, VHF, XPR8400, 147.210 +, CC1,  antenna at 300' on a county tower, owner: N4TIK (Ken), trustee: W0ADD (Al).

Ken and Al would prefer their repeater have the sysop level of control provided by Brandmeister rather than being on a cBridge and having to pester the bridge operator for changes.  However, they also want to carry the DelMarVa (8802) talkgroup, primarily for coordination across the region during EmComm scenarios, which is only carried on cBridges currently.

For policy reasons, 8802 will not be carried by BM.

The repeater is operational, barring some issues with the duplexer.  It's connected to BM currently, and operating as the owner and trustee wish it to, although lacking the 8802 talkgroup.

Existing configuration:

I think that with the advent of ACLs, I can insert a DVSwitch suite in between the XPR8400 and the BM3102 server.  I can use the ACLs to deny 8802 from going to BM3102, and also to permit only 8802 on TS1 going to/from K4USD.

Proposed configuration:


In this proposal, the IPSC_Bridge <-> BM3102 link would be using the N4TIK DMR ID # 310328, so would look the same as the existing repeater.

Does anyone see anything wrong with this approach?

Yes, I know BM supports HB directly, but I don't know what's involved with changing from the current IPSC connection to an HB connection, ie will BM even care? Is it a different port?  For that matter, I don't *know* that the IPSC_Bridge <->BM3102 link will function correctly.   Any advice on this point is very welcome.

Thanks in advance,
Jim

PS, hooray for ACLs!

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

I've reached the point where I need someone with experience with these tools to point me in the right direction.  I think I am getting overwhelmed with too much "there's more than one way to do it" combined with not knowing the limitations of the various branches of dmrlink and hblink (IPSC_Bridge and HB_Bridge specifically).

I have the need to connect 2 repeaters up to 2 different networks simultaneously.  One repeater is Mototrbo/IPSC and the other is MMDVM/Pi-Star.  One of the networks is a cBridge, and the other is Brandmeister.

On the IPSC repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default, with TG8802 sourced from the cBridge, and TG3151 sourced from either the cBridge or Brandmeister.  I can get it from either source, but TG8802 is only from the cBridge due to policy.  The part that makes it difficult for me to know how to implement it is that the repeater owner wants TS1 to share with "any possible" BM TG, with a PTT setup with 15 minute timeout to revert to TG8802.

On the MMDVM repeater, the requirement is to have TS1 TG8802 and TS2 TG3151 by default.  Again, TG8802 sourced from the cBridge, and TG3151 from either.  The repeater owner on this one is me, and I'd rather have my PTT groups on TS2, and I don't necessarily care if it is "any possible" BM TG or simply a predefined subset.

Eventually, we might add additional DMR repeaters into the mix, and have different requirements for them.

I've started with a pristine install of Ubuntu 18.04 LTS, updated it, added Steve's DVSwitch-System-Builder script, and followed its directions.

Any suggestions for the best way to implement the system as described, or as closely as possible?

Thanks in advance,
Jim KD4PPG
Re: Link DMR <==> FCSXXX

Steve N4IRS
 

According to this http://www.xreflector.net/ it will continue. I have no real idea.

Steve N4IRS

On 12/4/2018 1:34 PM, David wrote:
I thought the fcs network was shutting down soon.

On Tue, Dec 4, 2018 at 12:32 PM Steve N4IRS <szingman@...> wrote:
Looking at YSFGateway, it seems to support FCS (Someone correct me if I'm wrong) So, I don't see why not.

Steve N4IRS

On 12/4/2018 12:45 PM, Bruno wrote:
Hi,
Can we make a link between the DMR and an FCSXXX. As can be done between the DMR and the YSFReflector.

73's
F1PTL Bruno
Re: Link DMR <==> FCSXXX

David
 

I thought the fcs network was shutting down soon.


On Tue, Dec 4, 2018 at 12:32 PM Steve N4IRS <szingman@...> wrote:
Looking at YSFGateway, it seems to support FCS (Someone correct me if I'm wrong) So, I don't see why not.

Steve N4IRS

On 12/4/2018 12:45 PM, Bruno wrote:
Hi,
Can we make a link between the DMR and an FCSXXX. As can be done between the DMR and the YSFReflector.

73's
F1PTL Bruno
Re: Link DMR <==> FCSXXX

Steve N4IRS
 

Looking at YSFGateway, it seems to support FCS (Someone correct me if I'm wrong) So, I don't see why not.

Steve N4IRS

On 12/4/2018 12:45 PM, Bruno wrote:
Hi,
Can we make a link between the DMR and an FCSXXX. As can be done between the DMR and the YSFReflector.

73's
F1PTL Bruno
Link DMR <==> FCSXXX

Bruno
 

Hi,
Can we make a link between the DMR and an FCSXXX. As can be done between the DMR and the YSFReflector.

73's
F1PTL Bruno
Re: ASL playback and morse distorted when bridge is running

Corey Dean N3FE <n3fe@...>
 

Va3drv,

I have sent you a direct email without a response 2 days ago and also called you on the air.  You node is sending telemetry to 91 where it should not be used!

Please remove it from talkgroup 91. 

Corey N3FE

On Tue, Dec 4, 2018 at 5:34 AM va3dxv <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: 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
8041 - 8060 of 10555