Date   

Re: Connecting more that 2 Analog_Bridges #analog_bridge

JJ Cummings
 

Maybe it's just a matter of what you and I are calling thing?

I read "address" as an IP Address which does not need to be unique at all.  All that needs to happen is each mode has an ASL node which listens for and sends USRP on a given set of ports.  Those ports need to be unique per node, but note the IP Address.

On Tue, Mar 24, 2020 at 11:03 AM Mike KB8JNM <groupio@...> wrote:

I was referring to the USRP address. One address set for each node.

On 3/24/2020 12:57 PM, JJ Cummings wrote:
You are correct with your design.  Not sure what "address" needs to be different.. but each would require it's own node entry in your ASL config and then you would need to link those ASL nodes together.  We accomplish this by having each mode have it's own node (as noted already) and then link each of those into a central ASL hub node where we can connect/disconnect at will.

On Tue, Mar 24, 2020 at 10:54 AM Mike KB8JNM <groupio@...> wrote:

The only thing I can see to note is that you will need 3 nodes. One for EACH AB you are showing.

Each will need a unique address on the same server. Perhaps there is more I am over looking.

On 3/24/2020 12:45 PM, davek wrote:
Would this seem like a appropriate all mode solution? Or am i over complicating this? I am not sure on the DStar


Re: Connecting more that 2 Analog_Bridges #analog_bridge

Mike KB8JNM
 

I was referring to the USRP address. One address set for each node.

On 3/24/2020 12:57 PM, JJ Cummings wrote:
You are correct with your design.  Not sure what "address" needs to be different.. but each would require it's own node entry in your ASL config and then you would need to link those ASL nodes together.  We accomplish this by having each mode have it's own node (as noted already) and then link each of those into a central ASL hub node where we can connect/disconnect at will.

On Tue, Mar 24, 2020 at 10:54 AM Mike KB8JNM <groupio@...> wrote:

The only thing I can see to note is that you will need 3 nodes. One for EACH AB you are showing.

Each will need a unique address on the same server. Perhaps there is more I am over looking.

On 3/24/2020 12:45 PM, davek wrote:
Would this seem like a appropriate all mode solution? Or am i over complicating this? I am not sure on the DStar


Re: Connecting more that 2 Analog_Bridges #analog_bridge

JJ Cummings
 

You are correct with your design.  Not sure what "address" needs to be different.. but each would require it's own node entry in your ASL config and then you would need to link those ASL nodes together.  We accomplish this by having each mode have it's own node (as noted already) and then link each of those into a central ASL hub node where we can connect/disconnect at will.


On Tue, Mar 24, 2020 at 10:54 AM Mike KB8JNM <groupio@...> wrote:

The only thing I can see to note is that you will need 3 nodes. One for EACH AB you are showing.

Each will need a unique address on the same server. Perhaps there is more I am over looking.

On 3/24/2020 12:45 PM, davek wrote:
Would this seem like a appropriate all mode solution? Or am i over complicating this? I am not sure on the DStar


Re: Connecting more that 2 Analog_Bridges #analog_bridge

Mike KB8JNM
 

The only thing I can see to note is that you will need 3 nodes. One for EACH AB you are showing.

Each will need a unique address on the same server. Perhaps there is more I am over looking.

On 3/24/2020 12:45 PM, davek wrote:
Would this seem like a appropriate all mode solution? Or am i over complicating this? I am not sure on the DStar


Re: Connecting more that 2 Analog_Bridges #analog_bridge

davek
 

Would this seem like a appropriate all mode solution? Or am i over complicating this? I am not sure on the DStar


Re: Connecting more that 2 Analog_Bridges #analog_bridge

davek
 

Exactly what i needed to know, thanks Steve


Re: Connecting more that 2 Analog_Bridges #analog_bridge

Steve N4IRS
 

The only way to bridge USRP across more then 2 connections is with ASL.
The other issue to consider is that you don't ALWAYS want to go analog for conversion. Consider this:
DMR, NXDN, YSFn.  No conversion required. All 3 are AMBE so it's a simple cross connected MMDVM single instance for 2 modes.
YSFw and P25. No conversion required. All 3 ar IMBE so it's a simple cross connected MMDVM single instance for 2 modes.
D-Star is stand alone.

So, for example if you used 2 instances of AB to bridge DMR to NXDN you would loose quality by going to analog when it's not needed.

 Steve N4IRS

On 3/24/2020 11:40 AM, davek wrote:
Bridge more than one (all?) digital modes together


Re: Connecting more that 2 Analog_Bridges #analog_bridge

davek
 

Bridge more than one (all?) digital modes together


Re: Connecting more that 2 Analog_Bridges #analog_bridge

JJ Cummings
 

What exactly is your ultimate goal?


On Tue, Mar 24, 2020 at 8:39 AM davek <davidkierz@...> wrote:
So i have a simple DMR to P25 Gateway working by piggybacking 2 instances of Analog_Bridge. I would like to add more modes, what process or component ties more than 2 Analog Bridges together?


Connecting more that 2 Analog_Bridges #analog_bridge

davek
 

So i have a simple DMR to P25 Gateway working by piggybacking 2 instances of Analog_Bridge. I would like to add more modes, what process or component ties more than 2 Analog Bridges together?


Re: Working with MMDVM_Bridge and XLX

JJ Cummings
 

Oh, and when I start ircddbgateway up and it links to the XLX - I do get audio from ircddbgateway itself back to analog announcing the connection.. I know it has to be some trivial setting in ircddbgateway but I'm at a loss for what that setting is.



On Tue, Mar 24, 2020 at 8:24 AM JJ Cummings via Groups.Io <cummingsj=gmail.com@groups.io> wrote:
So I managed to solve my first issue where ircddbgateway etc would not connect to XLX.  Turns out that XLX is very picky about padding and I needed to add some additional padding in the ircddbgateway configuration.  The issue that I have remaining is that I get one way audio (Analog to XLX) but not XLX to Analog.  I have traced the issue down to ircddbgateway - where I see the voice packets come in from XLX but then ircddbgateway never passes them to MMDVM_Bridge, any thoughts from anyone?


On Fri, Mar 20, 2020 at 9:28 AM JJ Cummings via Groups.Io <cummingsj=gmail.com@groups.io> wrote:
The problem that I am seeing does not exist between MMDVM_Bridge and XLX but between ircddbgateway and xlx.  The design is simple:

Analog_Bridge <-> MMDVM_Bridge <-> ircddbgateway <-> XLX (DStar)

The connection between ircddbgateway and XLX consistently times out (this occurs from pistar as well).  This appears to be an issue where ircddbgateway is not handling the keepalive packets correctly from the XLX server, as evidenced by the ircddb logs below.  I have tried DCS and DExtra and both exhibit the exact same behavior.  Any input is greatly appreciated!

ircddb logs:
M: 2020-03-19 23:18:49: DCS link to DCS815 established
M: 2020-03-19 23:18:50: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:51: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:52: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:53: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:54: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:55: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:56: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:57: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:58: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:59: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:01: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:02: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:03: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:04: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:05: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:06: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:07: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:08: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:09: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:10: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:11: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:12: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:13: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:14: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:15: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:16: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:17: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:18: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:19: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:20: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:51: DCS link to DCS815 has failed (poll inactivity)
M: 2020-03-19 23:19:51: DCS link to DCS815 has failed, relinking


Re: Working with MMDVM_Bridge and XLX

JJ Cummings
 

So I managed to solve my first issue where ircddbgateway etc would not connect to XLX.  Turns out that XLX is very picky about padding and I needed to add some additional padding in the ircddbgateway configuration.  The issue that I have remaining is that I get one way audio (Analog to XLX) but not XLX to Analog.  I have traced the issue down to ircddbgateway - where I see the voice packets come in from XLX but then ircddbgateway never passes them to MMDVM_Bridge, any thoughts from anyone?


On Fri, Mar 20, 2020 at 9:28 AM JJ Cummings via Groups.Io <cummingsj=gmail.com@groups.io> wrote:
The problem that I am seeing does not exist between MMDVM_Bridge and XLX but between ircddbgateway and xlx.  The design is simple:

Analog_Bridge <-> MMDVM_Bridge <-> ircddbgateway <-> XLX (DStar)

The connection between ircddbgateway and XLX consistently times out (this occurs from pistar as well).  This appears to be an issue where ircddbgateway is not handling the keepalive packets correctly from the XLX server, as evidenced by the ircddb logs below.  I have tried DCS and DExtra and both exhibit the exact same behavior.  Any input is greatly appreciated!

ircddb logs:
M: 2020-03-19 23:18:49: DCS link to DCS815 established
M: 2020-03-19 23:18:50: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:51: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:52: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:53: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:54: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:55: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:56: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:57: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:58: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:18:59: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:01: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:02: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:03: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:04: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:05: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:06: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:07: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:08: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:09: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:10: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:11: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:12: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:13: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:14: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:15: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:16: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:17: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:18: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:19: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:20: Unknown incoming DCS poll from DCS815 I
M: 2020-03-19 23:19:51: DCS link to DCS815 has failed (poll inactivity)
M: 2020-03-19 23:19:51: DCS link to DCS815 has failed, relinking


Re: NXDN not passing thru to Dstar

Steve N4IRS
 

Show a snip of your life when transmitting from NXDN ALL the way through to ircddbgateway.

Sent via smoke signal (AT&T)


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Kevin Halton <Khalton@...>
Sent: Monday, March 23, 2020 7:47:03 PM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] NXDN not passing thru to Dstar
 
MMDVM and DVswitch logs both show the proper headers being passed. When I keyup with NXDN radio I see my ID# and when I keyup with Dstar I see my callsign going to the correct TG.


Re: NXDN not passing thru to Dstar

Steve N4IRS
 

Your caall sign should be passed to D-Star

On 3/23/20 7:47 PM, Kevin Halton wrote:
MMDVM and DVswitch logs both show the proper headers being passed. When I keyup with NXDN radio I see my ID# and when I keyup with Dstar I see my callsign going to the correct TG.


Re: NXDN not passing thru to Dstar

Kevin Halton
 

MMDVM and DVswitch logs both show the proper headers being passed. When I keyup with NXDN radio I see my ID# and when I keyup with Dstar I see my callsign going to the correct TG.


Re: NXDN not passing thru to Dstar

Steve N4IRS
 

Sorry,
Wrong pointer.
In MMDVM_Bridge.ini:

[NXDN Id Lookup]
File=/var/lib/mmdvm/NXDN.csv
Time=24

Verify the userfile is current and has actual content. This is where MB looks up a user.
I would also look at the ircddbgateway log when a signal is coming in from NXDN and see what the log says. I would also look at the MMDVM_Bridge log and the Analog_Bridge log.

My guess is NXDN is not resolving a NXDN ID to a callsign which D-Star needs.

Steve N4IRS 

On 3/23/20 5:57 PM, Kevin Halton wrote:
This is what my NXDNGateway.ini looks like

NXDNgateway.ini

[Network]
Port=14050
HostsFile1=./NXDNHosts.txt
HostsFile2=./private/NXDNHosts.txt
ReloadTime=60
ParrotAddress=127.0.0.1
ParrotPort=42021
NXDN2DMRAddress=127.0.0.1
NXDN2DMRPort=42022

When I go to /var/lib/mmdvm I  do not have NXDNHosts.txt or private_NXDNHosts.txt listed. There is a NXDN.csv only. In /opt/XDNGatewayhere is a NXDNHosts.txt and the talkgroup I am trying to access is listed.









Re: NXDN not passing thru to Dstar

Kevin Halton
 

I have one instance of Analog_Bridge.ini running. I have 3 instances of MMDVM_Bridge.ini running and 3 DVSwitch.ini running
DVSwitch.ini
DVSwitch.ini.DMR
DVSwitch.ini.NXDN
MMDVM_Bridge.ini
MMDVM_Bridge.ini.DMR
MMDVM_Bridge.ini.NXDN


Re: NXDN not passing thru to Dstar

Kevin Halton
 

This is what my NXDNGateway.ini looks like

NXDNgateway.ini

[Network]
Port=14050
HostsFile1=./NXDNHosts.txt
HostsFile2=./private/NXDNHosts.txt
ReloadTime=60
ParrotAddress=127.0.0.1
ParrotPort=42021
NXDN2DMRAddress=127.0.0.1
NXDN2DMRPort=42022

When I go to /var/lib/mmdvm I  do not have NXDNHosts.txt or private_NXDNHosts.txt listed. There is a NXDN.csv only. In /opt/XDNGatewayhere is a NXDNHosts.txt and the talkgroup I am trying to access is listed.








Re: NXDN not passing thru to Dstar

Steve N4IRS
 

In NXDNGateway.ini:
[Network]
HostsFile1=/var/lib/mmdvm/NXDNHosts.txt
HostsFile2=/var/lib/mmdvm/private_NXDNHosts.txt

Verify the hostfiles are current and have actual content.
I would also look at the ircddbgateway log when a signal is coming in from NXDN and see what the log says. I would also look at the MMDVM_Bridge log and the Analog_Bridge log.

My guess is NXDN is not resolving a NXDN ID to a callsign which D-Star needs.

Steve N4IRS 


On 3/23/2020 1:31 PM, Kevin Halton wrote:
Yes, Everything passes fine 


On Mar 23, 2020, at 1:05 PM, Steve N4IRS <szingman@...> wrote:


Does DMR bridge properly in both directions?

Sent by smoke signal (AT&T)


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Kevin Halton <Khalton@...>
Sent: Monday, March 23, 2020 8:45:19 AM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] NXDN not passing thru to Dstar
 
DMR


Re: NXDN not passing thru to Dstar

Kevin Halton
 

Yes, Everything passes fine 


On Mar 23, 2020, at 1:05 PM, Steve N4IRS <szingman@...> wrote:


Does DMR bridge properly in both directions?

Sent by smoke signal (AT&T)


From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Kevin Halton <Khalton@...>
Sent: Monday, March 23, 2020 8:45:19 AM
To: main@DVSwitch.groups.io <main@DVSwitch.groups.io>
Subject: Re: [DVSwitch] NXDN not passing thru to Dstar
 
DMR

3101 - 3120 of 9087