Date   

Re: Amazon Web Services (AWS) usage for reflectors

Mike, KI0IK
 

John,

Have you considered hosting your reflector(s) in the Azure cloud?  I'm running a small Ubuntu VM in Azure (1 CPU, 1 GB RAM).  It's hosting a P25Reflector and a YSFReflector (they're bridged together with an instance of MMDVM_Bridge).  It's working well.  

Mike


Re: 1 Way Audio (XLX DMR to ASL)

Steve N4IRS
 

This is VERY good info. I wqant to be clear, The work Steve is doing is VERY helpful! While Steve is troubleshooting at his end, Mike and I are working our end to find and fix the issue. All of the work going on together will resolve the issue.

Steve N4IRS

On 4/16/19 8:29 PM, Steve KC1AWV wrote:
DMRGateway is not a requirement to make a path from DVSwitch to XLX.

Let me explain that the reason that I have DMRGateway in a couple revisions of documents and why I mentioned it in the past. It was just for ease of (my) use. At first, I was confused as to how the voice data gets from DVSwitch to an XLX module, since MB logs in correctly, but XLX doesn't assign it to a module initially. In order to make things easier, DMRGateway can take a Module=X (where X is a module letter from A-Z) and once you're all logged in, viola, you're assigned a module. Simple as that, no muss no fuss. DMRGateway is just that, a gateway to a network. Think of the way it works with XLX as it is just choosing the door that you specified for you, once you get to the destination.

Once I took a look at the packet captures and saw that DMRGateway was trashing the call type (private instead of group) I decided that I wanted to get rid of it. I also saw that when making a call through DMRGateway, it wasn't actually selecting a module, but rather making a call to a specific TG - in my case, 4004 to assign module D. That's when the light bulb switched on in my head. If I can just get the call to go through to TG 4004, I won't need to use DMRGateway. Also, there's an opportunity to select whatever TG (read: module) I want by changing the TG on the fly. Well, guess what? AB takes that as an argument in the ini file.

Once I dropped DMRGateway and told AB to use TG 4004, MB connected and then just sat there like it used to. No module, no other indication of it being "ready." Then I decided, what the hell, I'll just make a call anyway - and it clicked. XLX put me into module D. No more DMRGateway needed.

Be aware though, this does not solve the one way audio issue. XLX will send voice data to MB just fine and you'll hear it coming out at you wherever the other end is. But, taking voice data from that end and pushing it back to XLX still doesn't work - XLX drops the stream almost as soon as it starts. No data comes back to MB from XLX to indicate an issue, but that's just the nature of UDP streams. In this case, the Internet is just a big truck, and you're dumping data somewhere and letting the server handle it however it wants.


Re: 1 Way Audio (XLX DMR to ASL)

Steve KC1AWV
 

DMRGateway is not a requirement to make a path from DVSwitch to XLX.

Let me explain that the reason that I have DMRGateway in a couple revisions of documents and why I mentioned it in the past. It was just for ease of (my) use. At first, I was confused as to how the voice data gets from DVSwitch to an XLX module, since MB logs in correctly, but XLX doesn't assign it to a module initially. In order to make things easier, DMRGateway can take a Module=X (where X is a module letter from A-Z) and once you're all logged in, viola, you're assigned a module. Simple as that, no muss no fuss. DMRGateway is just that, a gateway to a network. Think of the way it works with XLX as it is just choosing the door that you specified for you, once you get to the destination.

Once I took a look at the packet captures and saw that DMRGateway was trashing the call type (private instead of group) I decided that I wanted to get rid of it. I also saw that when making a call through DMRGateway, it wasn't actually selecting a module, but rather making a call to a specific TG - in my case, 4004 to assign module D. That's when the light bulb switched on in my head. If I can just get the call to go through to TG 4004, I won't need to use DMRGateway. Also, there's an opportunity to select whatever TG (read: module) I want by changing the TG on the fly. Well, guess what? AB takes that as an argument in the ini file.

Once I dropped DMRGateway and told AB to use TG 4004, MB connected and then just sat there like it used to. No module, no other indication of it being "ready." Then I decided, what the hell, I'll just make a call anyway - and it clicked. XLX put me into module D. No more DMRGateway needed.

Be aware though, this does not solve the one way audio issue. XLX will send voice data to MB just fine and you'll hear it coming out at you wherever the other end is. But, taking voice data from that end and pushing it back to XLX still doesn't work - XLX drops the stream almost as soon as it starts. No data comes back to MB from XLX to indicate an issue, but that's just the nature of UDP streams. In this case, the Internet is just a big truck, and you're dumping data somewhere and letting the server handle it however it wants.


Re: 1 Way Audio (XLX DMR to ASL)

Steve KC1AWV
 

I like to think that I'm doing my part for the greater good. Though I may not understand all the code and programming, I can at least get to a point where I know where the issue lies. From what I can tell, MMDVM_Bridge is doing exactly what it's supposed to do, and it works perfectly on all the systems and networks that I've tried up to this point.

The issue I believe is with xlxd. The path that the whole works takes is like this:

-Repeater Login-
MB sends login init to XLX (RPTL [Repeater ID])
XLX sends an auth challenge back to MB (RPTACK [salt])
MB sends back the auth to XLX (RPTK [Repeater ID] [hash])
XLX sends back auth successful to MB (RPTACK) - MALFORMED because the packet does not contain the Repeater ID
MB sends the repeater configuration to XLX (RPTC [Repeater ID] [MMDVM Conf])
XLX confirms with login successful to MB (RPTACK) - MALFORMED because the packet does not contain the Repeater ID
[TIME PASSES]
MB sends a keep-alive ping to XLX (RPTPING [Repeater ID])
XLX sends back a pong to MB (RPTPONG [Repeater ID]) - This repeater ID is what can only be described as bogus, it's supposed to send back the ID used in MB, but sends back a random number
[TIME PASSES, MORE PING-PONG]

-Voice Data-
MB sends 6 packets with voice header info (DMRD, Sequence, Source ID, Destination ID, Repeater ID, Slot, Call Type, Frame Type, Data Type, Stream ID, DMR Data, BER)
MB sends a voice sync packet (DMRD, Sequence, Source ID, Destination ID, Repeater ID, Slot, Call Type, Frame Type, Voice Sequence, Stream ID, DMR Data, BER)
MB sends 5 packets with voice frame data (DMRD, Sequence, Source ID, Destination ID, Repeater ID, Slot, Call Type, Frame Type, Voice Sequence, Stream ID, DMR Data, BER)
[SYNC AND FRAME REPEATS THROUGH TRANSMISSION]
MB sends voice term packet (DMRD, Sequence, Source ID, Destination ID, Repeater ID, Slot, Call Type, Frame Type, Data Type, Stream ID, DMR Data, BER)
[BACK TO KEEP-ALIVE PING-PONG]

Since this is UDP, there's nothing coming back from XLX during a voice transmission. MB is just shoving the data through the wire to XLX, and it's up to XLX to do with it as it deems fit. Want to hear a UDP joke? I'll tell you, but you might not get it.

Within a second or two (either during the voice header or voice sync, I assume) XLX just closes the connection. The logs from XLX look something like this:

Apr 16 18:06:41 xlx740 xlxd: Opening stream on module D for client KC1AWV  B with sid 11439
Apr 16 18:06:43 xlx740 xlxd: Closing stream of module D

So, really I feel something's wrong on XLX when processing the packets from MB. There's no issue on other DMR networks or with HBlink using MB. My next steps are to grab a pcap of an MMDVMHost connection to XLX and compare notes.

That's probably more than anyone wanted to know about how MB talks to a network, but I do feel that it's important information for people to know, in order to get a broader understanding of how this all works and the steps that I used to come to my conclusions. I don't find it too difficult to grasp these concepts, and I hope other people can learn from what we're all going through here.

Steve KC1AWV

Pardon my verbosity, I tend to ramble.

On Tue, Apr 16, 2019 at 4:39 PM Daniel L. Srebnick via Groups.Io <dan=islenet.com@groups.io> wrote:
Steve KC1AWV, thanks for your flurry of effort here in helping to understand what is going on.

73
_._,_._,


Re: 1 Way Audio (XLX DMR to ASL)

Dan K2IE
 

Steve KC1AWV, thanks for your flurry of effort here in helping to understand what is going on.

73


Re: 1 Way Audio (XLX DMR to ASL)

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.


Re: 1 Way Audio (XLX DMR to ASL)

Steve N4IRS
 


Re: 1 Way Audio (XLX DMR to ASL)

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@...


Re: 1 Way Audio (XLX DMR to ASL)

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.


Re: 1 Way Audio (XLX DMR to ASL)

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.


Re: 1 Way Audio (XLX DMR to ASL)

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.


Re: 1 Way Audio (XLX DMR to ASL)

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@...


Re: 1 Way Audio (XLX DMR to ASL)

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@...


Re: 1 Way Audio (XLX DMR to ASL)

Steve N4IRS
 

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

Steve N4IRS


Re: 1 Way Audio (XLX DMR to ASL)

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!


Re: 1 Way Audio (XLX DMR to ASL)

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


Re: 1 Way Audio (XLX DMR to ASL)

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


Re: 1 Way Audio (XLX DMR to ASL)

Dan K2IE
 

@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



Re: Let us say I am a NOOB (newbie)...

Steve KC1AWV
 

Those that wish to listen but don't want to transmit can do so here:

https://www.broadcastify.com/listen/feed/29582


Re: Let us say I am a NOOB (newbie)...

Steve KC1AWV
 

I don't have a video, but one of the nets I run is starting at 8pm Eastern (0000h UTC) tonight if you are interested in listening in.

BM TG 3122790
ASL 46550
Echolink KC1AWV-L

Steve KC1AWV

On Sat, Apr 13, 2019, 7:50 PM <Mw1coe@...> wrote:
Are there any Video's Showing a system in Full Flow ?..

I would like to also build a system..

Got a Pi.. AMBE USB.. MMDVM.. getting some Baofeng 888 Radio's modded for AllStar..

Interesting project if I can see it in action and get some ideas..

Thanks

Rob,,

On Sat, Apr 13, 2019 at 8:56 AM Steve N4IRS <szingman@...> wrote:
Check the Wikis and the file areas. I would like to see more of the external how to documents inclued in the wiki.

Steve

On 4/13/19 9:30 AM, John Kruk - N9UPC via Groups.Io wrote:
Can someone who is starting with this and is being self taught go anywhere to get a learns guide/manual. I know I and others while have a long road ahead and want to learn. Not asking to have the work done but maybe have help along the way and ask (maybe stupid) questions.



--
No trees were killed in the sending of this message. However, a large number of electrons were terribly inconvenienced !

6881 - 6900 of 10637