Topics

1 Way Audio (XLX DMR to ASL)

Dan K2DLS
 

I am trying to gateway ASL to XLX DMR.  Here is a diagram of what I have implemented.

Cloud Server 1

ASL Asterisk (Pvt Node and Public Node) <===> Analog Bridge <===> MMDVM Bridge <===> DMR Gateway (from github)
                                                                                      ||
                                                                                      ||
                                                                                md380-emu

Cloud Server 2

xlxd based reflector


I can successfully pass audio from the DMR side to the Asterisk side of the connection.  Quality is good.  However, when I try to pass audio from Asterisk to DMR, it sets up the path but there is no audio.  The DMR side times out after about 2 seconds after Analog PTT, the ID number of the gateway shows up on the screen, and that is all.

What should I look at next?

Here are some log snippets from a successful DMR <==> Analog transmission:

MMDVM Bridge:
M: 2019-03-27 19:03:19.379 DMR Slot 2, received network voice header from K2DLS to TG 6
M: 2019-03-27 19:03:23.554 DMR Slot 2, received network end of voice transmission, 4.0 seconds, 0% packet loss, BER: 0.0%

Analog Bridge:

I: 2019-03-27 19:02:34.163 Begin TX: src=3134090 rpt=0 dst=6 slot=2 cc=0
D: 2019-03-27 19:02:37.225 End TX

Here are snippers from the unsuccesful Analog <==> DMR:

MMDVM Bridge:

M: 2019-03-27 19:04:10.405 DMR, TX state = ON
I: 2019-03-27 19:04:10.405 DMR, Begin TX: src=3134090 rpt=313409003 dst=6 slot=2 cc=1 metadata=K2DLS
M: 2019-03-27 19:04:14.262 DMR, TX state = OFF

Analog Bridge:

M: 2019-03-27 19:04:10.403 PTT on
D: 2019-03-27 19:04:14.259 cpu_time_used = 3856, minTxTime = 2000, pttTime = 1553713450403, end = 1553713454259
M: 2019-03-27 19:04:14.259 PTT off (keyed for 3856 ms)

DMR Gateway:

No useful logging for XLX seen after the connect with the level set to 1.

xlxd: Lots of these going from analog to DMR...

Mar 27 14:58:22 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4

A fellow ham in the local area also had this exact problem.

Suggestions appreciated.

73,

Dan Srebnick
K2DLS

Dan K2DLS
 

Just to clarify the diagram below, the md380-emu hangs off the Analog Bridge...should have used a fixed font.

On Wed, 2019-03-27 at 12:13 -0700, Daniel L. Srebnick wrote:
I am trying to gateway ASL to XLX DMR.  Here is a diagram of what I have implemented.

Cloud Server 1

ASL Asterisk (Pvt Node and Public Node) <===> Analog Bridge <===> MMDVM Bridge <===> DMR Gateway (from github)
                                                                                      ||
                                                                                      ||
                                                                                md380-emu

Cloud Server 2

xlxd based reflector


I can successfully pass audio from the DMR side to the Asterisk side of the connection.  Quality is good.  However, when I try to pass audio from Asterisk to DMR, it sets up the path but there is no audio.  The DMR side times out after about 2 seconds after Analog PTT, the ID number of the gateway shows up on the screen, and that is all.

What should I look at next?

Here are some log snippets from a successful DMR <==> Analog transmission:

MMDVM Bridge:
M: 2019-03-27 19:03:19.379 DMR Slot 2, received network voice header from K2DLS to TG 6
M: 2019-03-27 19:03:23.554 DMR Slot 2, received network end of voice transmission, 4.0 seconds, 0% packet loss, BER: 0.0%

Analog Bridge:

I: 2019-03-27 19:02:34.163 Begin TX: src=3134090 rpt=0 dst=6 slot=2 cc=0
D: 2019-03-27 19:02:37.225 End TX

Here are snippers from the unsuccesful Analog <==> DMR:

MMDVM Bridge:

M: 2019-03-27 19:04:10.405 DMR, TX state = ON
I: 2019-03-27 19:04:10.405 DMR, Begin TX: src=3134090 rpt=313409003 dst=6 slot=2 cc=1 metadata=K2DLS
M: 2019-03-27 19:04:14.262 DMR, TX state = OFF

Analog Bridge:

M: 2019-03-27 19:04:10.403 PTT on
D: 2019-03-27 19:04:14.259 cpu_time_used = 3856, minTxTime = 2000, pttTime = 1553713450403, end = 1553713454259
M: 2019-03-27 19:04:14.259 PTT off (keyed for 3856 ms)

DMR Gateway:

No useful logging for XLX seen after the connect with the level set to 1.

xlxd: Lots of these going from analog to DMR...

Mar 27 14:58:22 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4

A fellow ham in the local area also had this exact problem.

Suggestions appreciated.

73,

Dan Srebnick
K2DLS

Steve KC1AWV
 

Daniel,

I've had the same issue myself before. I'm trying to remember exactly what I did to rectify the problem, but it's been a while since the last time I played with the configurations here. One thing that I do want to note is to make sure that you send only a max of a 7 digit DMR ID when going to XLX, your repeater ID has 9 digits. Try setting the repeater ID to something like 1234567 (if you don't have a second DMR ID) and test again. I'm not sure if using that ID is copacetic with every network, but it shouldn't be a problem with XLX since I think it only uses the repeater ID to lookup and display the callsign of the network you're coming in on. Your mileage may vary, caveat emptor, don't forget to turn the lights off before you leave, etc.

I would be very interested in how the test runs with that change.

Steve KC1AWV


On Wed, Mar 27, 2019 at 4:04 PM Daniel L. Srebnick <dan@...> wrote:
Just to clarify the diagram below, the md380-emu hangs off the Analog Bridge...should have used a fixed font.

On Wed, 2019-03-27 at 12:13 -0700, Daniel L. Srebnick wrote:
I am trying to gateway ASL to XLX DMR.  Here is a diagram of what I have implemented.

Cloud Server 1

ASL Asterisk (Pvt Node and Public Node) <===> Analog Bridge <===> MMDVM Bridge <===> DMR Gateway (from github)
                                                                                      ||
                                                                                      ||
                                                                                md380-emu

Cloud Server 2

xlxd based reflector


I can successfully pass audio from the DMR side to the Asterisk side of the connection.  Quality is good.  However, when I try to pass audio from Asterisk to DMR, it sets up the path but there is no audio.  The DMR side times out after about 2 seconds after Analog PTT, the ID number of the gateway shows up on the screen, and that is all.

What should I look at next?

Here are some log snippets from a successful DMR <==> Analog transmission:

MMDVM Bridge:
M: 2019-03-27 19:03:19.379 DMR Slot 2, received network voice header from K2DLS to TG 6
M: 2019-03-27 19:03:23.554 DMR Slot 2, received network end of voice transmission, 4.0 seconds, 0% packet loss, BER: 0.0%

Analog Bridge:

I: 2019-03-27 19:02:34.163 Begin TX: src=3134090 rpt=0 dst=6 slot=2 cc=0
D: 2019-03-27 19:02:37.225 End TX

Here are snippers from the unsuccesful Analog <==> DMR:

MMDVM Bridge:

M: 2019-03-27 19:04:10.405 DMR, TX state = ON
I: 2019-03-27 19:04:10.405 DMR, Begin TX: src=3134090 rpt=313409003 dst=6 slot=2 cc=1 metadata=K2DLS
M: 2019-03-27 19:04:14.262 DMR, TX state = OFF

Analog Bridge:

M: 2019-03-27 19:04:10.403 PTT on
D: 2019-03-27 19:04:14.259 cpu_time_used = 3856, minTxTime = 2000, pttTime = 1553713450403, end = 1553713454259
M: 2019-03-27 19:04:14.259 PTT off (keyed for 3856 ms)

DMR Gateway:

No useful logging for XLX seen after the connect with the level set to 1.

xlxd: Lots of these going from analog to DMR...

Mar 27 14:58:22 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4
Mar 27 14:58:23 somehost xlxd[8847]: WARNING: orphaned DvFramePacket SID 56803 from 1.2.3.4

A fellow ham in the local area also had this exact problem.

Suggestions appreciated.

73,

Dan Srebnick
K2DLS



--
Steve Miller
KC1AWV

Dan K2DLS
 

Steve:

I changed the repeater id in Analog_Bridge.ini to 1234567 as you suggested. After restarting all the involved processes, my test results were unchanged.

On Wed, 2019-03-27 at 20:48 -0400, Steve KC1AWV wrote:
Daniel,

I've had the same issue myself before. I'm trying to remember exactly what I did to rectify the problem, but it's been a while since the last time I played with the configurations here. One thing that I do want to note is to make sure that you send only a max of a 7 digit DMR ID when going to XLX, your repeater ID has 9 digits. Try setting the repeater ID to something like 1234567 (if you don't have a second DMR ID) and test again. I'm not sure if using that ID is copacetic with every network, but it shouldn't be a problem with XLX since I think it only uses the repeater ID to lookup and display the callsign of the network you're coming in on. Your mileage may vary, caveat emptor, don't forget to turn the lights off before you leave, etc.

I would be very interested in how the test runs with that change.

Steve KC1AWV


Steve KC1AWV
 

Ok, unless someone else can provide clues as to what might be happening I may have to lab this and go through the steps again to recreate and solve. I plan on restructuring the system I run here this weekend anyway, so it may be a good chance to write this stuff down for future reference.

On Wed, Mar 27, 2019 at 9:58 PM Daniel L. Srebnick <dan@...> wrote:
Steve:

I changed the repeater id in Analog_Bridge.ini to 1234567 as you suggested. After restarting all the involved processes, my test results were unchanged.

On Wed, 2019-03-27 at 20:48 -0400, Steve KC1AWV wrote:
Daniel,

I've had the same issue myself before. I'm trying to remember exactly what I did to rectify the problem, but it's been a while since the last time I played with the configurations here. One thing that I do want to note is to make sure that you send only a max of a 7 digit DMR ID when going to XLX, your repeater ID has 9 digits. Try setting the repeater ID to something like 1234567 (if you don't have a second DMR ID) and test again. I'm not sure if using that ID is copacetic with every network, but it shouldn't be a problem with XLX since I think it only uses the repeater ID to lookup and display the callsign of the network you're coming in on. Your mileage may vary, caveat emptor, don't forget to turn the lights off before you leave, etc.

I would be very interested in how the test runs with that change.

Steve KC1AWV




--
Steve Miller
KC1AWV

Dan K2DLS
 

Here's hoping you are able to figure it out! If you need an XLX to test with, feel free to use XLX020 E.

73,

Dan

On Thu, 2019-03-28 at 07:43 -0400, Steve KC1AWV wrote:
Ok, unless someone else can provide clues as to what might be happening I may have to lab this and go through the steps again to recreate and solve. I plan on restructuring the system I run here this weekend anyway, so it may be a good chance to write this stuff down for future reference.

On Wed, Mar 27, 2019 at 9:58 PM Daniel L. Srebnick <dan@...> wrote:
Steve:

I changed the repeater id in Analog_Bridge.ini to 1234567 as you suggested. After restarting all the involved processes, my test results were unchanged.

On Wed, 2019-03-27 at 20:48 -0400, Steve KC1AWV wrote:
Daniel,

I've had the same issue myself before. I'm trying to remember exactly what I did to rectify the problem, but it's been a while since the last time I played with the configurations here. One thing that I do want to note is to make sure that you send only a max of a 7 digit DMR ID when going to XLX, your repeater ID has 9 digits. Try setting the repeater ID to something like 1234567 (if you don't have a second DMR ID) and test again. I'm not sure if using that ID is copacetic with every network, but it shouldn't be a problem with XLX since I think it only uses the repeater ID to lookup and display the callsign of the network you're coming in on. Your mileage may vary, caveat emptor, don't forget to turn the lights off before you leave, etc.

I would be very interested in how the test runs with that change.

Steve KC1AWV




Steve KC1AWV
 

Thanks, I got one here I run. I'll test and let you know what I find!

On Thu, Mar 28, 2019 at 8:18 AM Daniel L. Srebnick <dan@...> wrote:
Here's hoping you are able to figure it out! If you need an XLX to test with, feel free to use XLX020 E.

73,

Dan

On Thu, 2019-03-28 at 07:43 -0400, Steve KC1AWV wrote:
Ok, unless someone else can provide clues as to what might be happening I may have to lab this and go through the steps again to recreate and solve. I plan on restructuring the system I run here this weekend anyway, so it may be a good chance to write this stuff down for future reference.

On Wed, Mar 27, 2019 at 9:58 PM Daniel L. Srebnick <dan@...> wrote:
Steve:

I changed the repeater id in Analog_Bridge.ini to 1234567 as you suggested. After restarting all the involved processes, my test results were unchanged.

On Wed, 2019-03-27 at 20:48 -0400, Steve KC1AWV wrote:
Daniel,

I've had the same issue myself before. I'm trying to remember exactly what I did to rectify the problem, but it's been a while since the last time I played with the configurations here. One thing that I do want to note is to make sure that you send only a max of a 7 digit DMR ID when going to XLX, your repeater ID has 9 digits. Try setting the repeater ID to something like 1234567 (if you don't have a second DMR ID) and test again. I'm not sure if using that ID is copacetic with every network, but it shouldn't be a problem with XLX since I think it only uses the repeater ID to lookup and display the callsign of the network you're coming in on. Your mileage may vary, caveat emptor, don't forget to turn the lights off before you leave, etc.

I would be very interested in how the test runs with that change.

Steve KC1AWV






--
Steve Miller
KC1AWV

Dan K2DLS
 

@Steve KC1AWV,

Wondering if you have had an opportunity to take a look at this.

73

On Thu, 2019-03-28 at 09:51 -0400, Steve KC1AWV wrote:
Thanks, I got one here I run. I'll test and let you know what I find!

On Thu, Mar 28, 2019 at 8:18 AM Daniel L. Srebnick <dan@...> wrote:
Here's hoping you are able to figure it out! If you need an XLX to test with, feel free to use XLX020 E.

73,

Dan


Steve KC1AWV
 

I have, and here's my observations so far:

  • XLX has a funny way of implementing MMDVM, or there's something going on behind the scenes that I cannot see.
  • Pi-Star MMDVM works well with XLX MMDVM, but MMDVM_Bridge does not. These are two different programs, so no correlation can be derived from this.
  • XLX drops MMDVM_Bridge connections with no logging. gdb debugging also provides no clue. As a matter of fact, there's no debugging available in XLX... and I don't want to rewrite the code.
  • XLX was first designed with D-Star in mind, then added DMR as an add on. Maybe the MMDVM implementation for XLX is buggered up?
  • XLX can also take DMO mode DMR+ on port 8880 - this is where I am currently at, seeing if there's a bridge that can provide DMO mode that works with DVSwitch.
All this research and experimentation is taking a back seat to my day job. Those that want to help that may know more about these things are more than welcome to contact me.


On Sun, Apr 14, 2019 at 8:16 PM Daniel L. Srebnick via Groups.Io <dan=islenet.com@groups.io> wrote:
@Steve KC1AWV,

Wondering if you have had an opportunity to take a look at this.

73

On Thu, 2019-03-28 at 09:51 -0400, Steve KC1AWV wrote:
Thanks, I got one here I run. I'll test and let you know what I find!

On Thu, Mar 28, 2019 at 8:18 AM Daniel L. Srebnick <dan@...> wrote:
Here's hoping you are able to figure it out! If you need an XLX to test with, feel free to use XLX020 E.

73,

Dan




--
Steve Miller
KC1AWV

Steve KC1AWV
 

This also all may be related to a long-standing issue with XLXd. You can view the issue here: https://github.com/LX3JL/xlxd/issues/67 

My thought is that XLXd doesn't send a Repeater ID because, well, XLXd is not a repeater. It's a reflector... a multi-protocol reflector that has more protocols to deal with D-Star than DMR. This is why I'm thinking DMO might be the way to go when connecting to an XLX reflector. (For the time being...)

To quote Steve N4IRS. "MMDVM host does not have a problem connecting to XLX because it ignores the response." (https://dvswitch.groups.io/g/main/message/468) meaning, that hotspots running MMDVMHost (Pi-Star, Openspot? and the like) don't seem to have any issues - because again, it knows nothing about receiving repeater IDs. The only information that MMDVMHost cares about is the Radio ID, and the DMR voice data of course.

From what I gather, changes need to be made on the XLX side of the equation for it to play nicely with MMDVM_Bridge. Why should the changes be made there? Well, since we already know that MMDVMHost is ignoring parts of the data coming to it (Repeater ID) it doesn't matter what XLX is sending to it. The changes can be made to the XLXd code, without impacting current users, and making it play nice with MMDVM_Bridge. What changes should be made? I personally don't know just yet, and if there's someone else that knows the code better than I do, I welcome them to give me a hand. Until then, let me see what I can do to get DVSwitch to connect in DMO to an XLX reflector.

Steve KC1AWV

Steve KC1AWV
 

ASL <-> AB <-> MB <-> DG <-> XLX

For those that are watching and may be smarter than I am, here's what happens when I connect MMDVM_Bridge to XLX.

There are three screenshots, one showing malformed data on the RPTACK on auth, one showing RPTPING with the Repeater ID showing, and one showing the odd MSTPONG with what looks like garbage in the Repeater ID. I didn't include the login RPTACK since it's the same as the auth. The ignored packets are just ARP.

What I find interesting is that three voice headers are sent by MMDVM_Bridge through DMRGateway to XLX, then two voice term packets are sent. Is MMDVM_Bridge not geting a reply from XLX and closing the connection?

It's certainly solidifying the idea that the problem here is with XLX. It's sending malformed data back to MMDVM_Bridge and for some reason, MMDVM_Bridge is sending voice term to XLX during a transmit.

Looking at the code for xlxd, in src/cdmrmmdvmprotocol.cpp starting at line 832, is where the ACK NACK PING PONG stuff is handled. I'd like to clean that section up, get the Repeater ID being sent (Send the one used to login back to MMDVM_Bridge?) and find out why MSTPONG is sending back weird data. Those that have the knowledge and time, Help, Please!

Steve N4IRS
 

Steve,
Mike and I are talking about this. Does MMDVMHost need DMRGateway to connect to XLX?

Steve N4IRS

Doug - W4DBG
 

I will attempt to answer this :) 

Without DMRGATEWAY I don’t think MMDVMHost would know where to connect?

It’s not like BM where you dial the TG that you are connected to. 

DMRGATEWAY connects to the TG/Module and then it “talks” on TG6

I hope that makes sense and what you wanted to know. 

Doug
W4DBG



On Mon, Apr 15, 2019 at 4:29 PM Steve N4IRS <szingman@...> wrote:
Steve,
Mike and I are talking about this. Does MMDVMHost need DMRGateway to connect to XLX?

Steve N4IRS

--
Doug Gooden
troytrojan@...

Steve N4IRS
 

Thanks Doug,
I forgot about all the XLX settings in DMRGateway.

Steve

On 4/15/19 5:53 PM, Doug - W4DBG wrote:
I will attempt to answer this :) 

Without DMRGATEWAY I don’t think MMDVMHost would know where to connect?

It’s not like BM where you dial the TG that you are connected to. 

DMRGATEWAY connects to the TG/Module and then it “talks” on TG6

I hope that makes sense and what you wanted to know. 

Doug
W4DBG



On Mon, Apr 15, 2019 at 4:29 PM Steve N4IRS <szingman@...> wrote:
Steve,
Mike and I are talking about this. Does MMDVMHost need DMRGateway to connect to XLX?

Steve N4IRS
--
Doug Gooden
troytrojan@...

Steve KC1AWV
 

Steve,

No, DMRGateway is not needed. DMRGateway is there as an 'ease of use' and for multiple connections out. I realized that with my packet captures that the packets going out from MB were being 'trashed' by DG, as you can see it's going out as a private call. When I took DG out of the loop, the packets go as a group call. However, XLX is still dropping the connection after about a second or two regardless of DG.

I've got pcaps up to my eyeballs right now.

Now I'm going like this:

ASL <-> AB <-> MB <-> XLX

To answer Doug's concern - in Analog_Bridge tell it that the TG is one of the 4000 range of TGs. So, 4001 will make MMDVM connect to module A, 4002 will make it connect to module B... etc. This is just like switching modules and disconnecting using a Pi-Star. I'm working on seeing if there's a way to have ASL handle the module changes as a separate task.

Steve N4IRS
 

AB can change TGs on the fly. Stay tuned (excuse the pun)

On 4/15/19 6:34 PM, Steve KC1AWV wrote:
Steve,

No, DMRGateway is not needed. DMRGateway is there as an 'ease of use' and for multiple connections out. I realized that with my packet captures that the packets going out from MB were being 'trashed' by DG, as you can see it's going out as a private call. When I took DG out of the loop, the packets go as a group call. However, XLX is still dropping the connection after about a second or two regardless of DG.

I've got pcaps up to my eyeballs right now.

Now I'm going like this:

ASL <-> AB <-> MB <-> XLX

To answer Doug's concern - in Analog_Bridge tell it that the TG is one of the 4000 range of TGs. So, 4001 will make MMDVM connect to module A, 4002 will make it connect to module B... etc. This is just like switching modules and disconnecting using a Pi-Star. I'm working on seeing if there's a way to have ASL handle the module changes as a separate task.

Steve KC1AWV
 

Doug,

If you want to drop DMRGateway, this is how I have AB set up for going direct from MMDVM_Bridge

; The metadata below is used when ASL is the source since it does not have any concept of digital modes
gatewayDmrId = 1234568                  ; ID to use when transmitting from Analog_Bridge
repeaterID = 1234567                    ; ID of source repeater
txTg = 4004                             ; TG to use for all frames sent from Analog_Bridge -> xx_Bridge
txTs = 2                                ; Slot to use for frames sent from Analog_Bridge -> xx_Bridge
colorCode = 1                           ; Color Code to assign DMR frames

This config makes MB talk on module D. Change the TG to 4001-4026 depending on the module you want to talk on.

Doug - W4DBG
 

Nice!

I will try. 

Thanks!



On Mon, Apr 15, 2019 at 5:38 PM Steve KC1AWV <smiller@...> wrote:
Doug,

If you want to drop DMRGateway, this is how I have AB set up for going direct from MMDVM_Bridge

; The metadata below is used when ASL is the source since it does not have any concept of digital modes
gatewayDmrId = 1234568                  ; ID to use when transmitting from Analog_Bridge
repeaterID = 1234567                    ; ID of source repeater
txTg = 4004                             ; TG to use for all frames sent from Analog_Bridge -> xx_Bridge
txTs = 2                                ; Slot to use for frames sent from Analog_Bridge -> xx_Bridge
colorCode = 1                           ; Color Code to assign DMR frames

This config makes MB talk on module D. Change the TG to 4001-4026 depending on the module you want to talk on.

--
Doug Gooden
troytrojan@...

Steve N4IRS
 

Steve KC1AWV
 

Oh wow I really want to play with that! Give me a couple hours to get home I'm stuck in Boston Marathon traffic.