|
Stay at Home SALE on the ThumbDV™
The “Stay at Home” order by Governor Inslee of Washington State, has impacted some of our vendors, delaying the DRAWS™ run. We will keep you apprised. So it’s time for a sale on the ThumbDV™ ! Might as well contact Hams on the reflectors using DSTAR, DMR or Fusion from your PC at home. Normally $119.95, on Sale NOW for $99.95 at least until the order is lifted, or we run out of inventory. Price Protection Policy: If you ordered a ThumbDV™ in the last 30 days, email sales@... for a $20 refund.
http://nwdigitalradio.com/product/thumbdv/
|
|
|
Re: NXDN not passing thru to Dstar
It appears to have corrected itself. Tried this morning and audio passing thru all modes! THANKS FOR ALL THE HELP!!
|
|
|
Port address, not IP.
As same with each P25 NXDN DMR etc service instance that is on the same server.
A separate PORT ADDRESS will be needed for each instance of a service running on the same server. You're typing "port address" when you mean port number. I think that's why you are confusing JJ et al. Assuming they're all running on the same host, they will all use the localhost IP ADDRESS (127.0.0.1), but different PORT NUMBERS. --- Jeff WN3A -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
|
|
|
Steve N4IRS
If only it were so. In the diagram below (if I understand it) you
have NXDN, DMR and YSFn all enabled. That's fine but NXDN is going
to need to point it's TX and RX UDP ports at another mode (or
Analog_Bridge) But only one partner. MMDVM_Bridge does not
mix all the modes and then output to AB. It's a one to one
relationship. Look at DVSwitch.ini:
; Configure the DMR Partner
; Audio format is AMBE 72 bit
[DMR]
Address = 127.0.0.1 ; Address to send AMBE TLV frames
to (export)
TXPort = 31100 ; Port to send AMBE TLV frames to
(export)
RXPort = 31103 ; Port to listen on (import)
; Configure the D-Star Partner
; Audio format is AMBE 48 bit (DSAMBE)
[DSTAR]
Address = 127.0.0.1 ; Address to send AMBE TLV frames
to (export)
TXPort = 32100 ; Port to send AMBE TLV frames to
(export)
RXPort = 32103 ; Port to listen on (import)
; Configure the NXDN Partner
; Audio format is AMBE 72 bit
[NXDN]
Address = 127.0.0.1 ; Address to send AMBE TLV frames
to (export)
TXPort = 33100 ; Port to send AMBE TLV frames to
(export)
RXPort = 33103 ; Port to listen on (import)
; Configure the P25 Partner
; Audio format is IMBE 88 bit
[P25]
Address = 127.0.0.1 ; Address to send AMBE TLV frames
to (export)
TXPort = 34100 ; Port to send AMBE TLV frames to
(export)
RXPort = 34103 ; Port to listen on (import)
; Configure the Yaesu Fusion Partner
; Audio format is AMBE 72 bit
; Audio format is IMBE 88 bit
[YSF]
Address = 127.0.0.1 ; Address to send AMBE TLV frames
to (export)
TXPort = 35100 ; Port to send AMBE TLV frames to
(export)
RXPort = 35103 ; Port to listen on (import)
For a DMR to NXDN bridge it require to "cross connect the DMR
and NXDN ports like this:
[DMR]
Address = 127.0.0.1 ; Address to send AMBE TLV frames
to (export)
TXPort = 31100 ; Port to send AMBE TLV frames to
(export)
RXPort = 31103 ; Port to listen on (import)
[NXDN]
Address = 127.0.0.1 ; Address to send AMBE TLV
frames to (export)
TXPort = 31103 ; Port to send AMBE TLV frames
to (export)
RXPort = 31100 ; Port to listen on (import)
To mix everything in analog, you will need an ASL node for each
mode. That's 5 copies of AB and 5 ASL nodes on the server. But
I'll say again, you do not want to convert each mode to analog due
to the loss of quality as compared to like vocoders.
Steve N4IRS
toggle quoted messageShow quoted text
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
|
|
|
Mike KB8JNM
Port address, not IP.
As same with each P25 NXDN DMR etc service instance that is on
the same server.
A separate PORT ADDRESS will be needed for each instance of a
service running on the same server.
They can not be shared unless something has changed that I was
not aware of.
toggle quoted messageShow quoted text
On 3/24/2020 1:11 PM, JJ Cummings
wrote:
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
|
|
|
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
|
|
|
Mike KB8JNM
I was referring to the USRP address. One address set for each
node.
toggle quoted messageShow quoted text
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
|
|
|
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
|
|
|
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.
toggle quoted messageShow quoted text
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
|
|
|
Would this seem like a appropriate all mode solution? Or am i over complicating this? I am not sure on the DStar 
|
|
|
Exactly what i needed to know, thanks Steve
|
|
|
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
toggle quoted messageShow quoted text
On 3/24/2020 11:40 AM, davek wrote:
Bridge more than one (all?) digital modes together
|
|
|
Bridge more than one (all?) digital modes together
|
|
|
What exactly is your ultimate goal?
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?
|
|
|
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
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
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)
toggle quoted messageShow quoted text
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
toggle quoted messageShow quoted text
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
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.
|
|
|
