Topics

ASL <-> D-STAR -- Only working one way, but all logs show traffic

Brad McConahay - N8QQ
 

I'm doing this:
 
XLX <-> ircDDBGateway <-> MMDVM_Bridge <-> Analog_Bridge <-> ASL
 
When transmitting with a rig/hotspot through the XLX reflector, audio comes through the Allstar node as expected.
 
But when transmitting through the Allstar side, nothing happens through the XLX reflector. No key up.
 
All logs show traffic in both directions. Analog_Bridge.ini, MMDVM_Bridge.ini, ircDDBGateway, xlxd, and the asterisk console with debug level 6.
 
However, the ircDDBGateway and xlxd logs have differences between the two directions:
 
When tx'ing from the rig/hotspot -> XLX (which works as expected):
 
ircDDBGateway log:
M: 2019-06-23 04:33:20: USER: N8QQ     N8QQ   C N8QQ   G 149.28.127.98
M: 2019-06-23 04:33:20: USER: N8QQ     N8QQ   C N8QQ   G 149.28.127.98
 
xlxd log:
Jun 23 00:16:52 radio xlxd: Opening stream on module C for client N8QQ    C with sid 26523
Jun 23 00:16:53 radio xlxd: Closing stream of module C
When tx'ing through the ASL node side:
 
ircDDBGateway log:
M: 2019-06-23 04:34:41: USER: 3139557  N8QQ   B N8QQ   G 149.28.127.98
M: 2019-06-23 04:34:41: USER: 3139557  N8QQ   B N8QQ   G 149.28.127.98
 
xlxd log:
Jun 23 00:16:59 radio xlxd: DExtra packet (56)
Jun 23 00:16:59 radio xlxd: message repeated 4 times: [ DExtra packet (56)]
It's the same whether using a remote ambeserver with dv3000 device, or the OP25 vocoder. Also tried it on REF006 B with the same result to make sure it wasn't something specific with DExtra or my reflector.
 
I don't know if the CCS7 ID being in the ircDDBGateway line affects anything or not. My best speculation is that since xlxd is seeing packets but not opening the stream, maybe there's no header being sent or something similar. I just don't know the protocols well enough to know.
 
Can anybody help?
 
Thanks,
 
Brad N8QQ
 

Brad McConahay - N8QQ
 

Well, I hate to talk to myself :-) but the new binary for MMDVM_Bridge didn't help this one-way situation.

xlxd receives the "DExtra packet (56)" packet via ircddbgateway but won't open the stream. Works fine in all directions otherwise.

Stumped.

Brad McConahay - N8QQ
 

Just one more follow up. I'm wondering if the DExtra header going from MMDVM_Bridge to xlxd is possibly malformed.
 
This is MMDVM_Bridge running in the foreground with D-Star Network debug=1 
 
In the non-working direction: ASL --> AB --> MB --> ircddbgateway --> xlxd
 
M: 2019-06-26 00:58:47.244 D-Star, TX state = ON
I: 2019-06-26 00:58:47.244 D-Star, Begin TX: src=3139557 rpt=0 dst=98004 slot=2 cc=1 metadata=3139557
D: 2019-06-26 00:58:47.244 D-Star Network Header Sent
D: 2019-06-26 00:58:47.244 0000:  44 53 52 50 20 80 E5 00 D9 43 CE 4E 38 51 51 20    *DSRP ....C.N8QQ *
D: 2019-06-26 00:58:47.244 0010:  20 20 47 4E 38 51 51 20 20 20 43 43 51 43 51 43    *  GN8QQ   CCQCQC*
D: 2019-06-26 00:58:47.244 0020:  51 20 20 33 31 33 39 35 35 37 20 44 56 53 57 EC    *Q  3139557 DVSW.*
D: 2019-06-26 00:58:47.244 0030:  9D                                                 *.*
 
And in the working direction: xlxd --> ircddbgateway --> MB --> AB --> ASL
 
D: 2019-06-26 00:59:32.818 D-Star Network Header Received
D: 2019-06-26 00:59:32.818 0000:  44 53 52 50 20 9F 7F 00 00 00 00 4E 38 51 51 20    *DSRP ......N8QQ *
D: 2019-06-26 00:59:32.818 0010:  20 20 43 4E 38 51 51 20 20 20 47 43 51 43 51 43    *  CN8QQ   GCQCQC*
D: 2019-06-26 00:59:32.818 0020:  51 20 20 4E 38 51 51 20 20 20 20 42 52 41 44 E5    *Q  N8QQ    BRAD.*
D: 2019-06-26 00:59:32.818 0030:  A5                                                 *.*
 
Is that how that first header should look? I've never looked at any of the D-STAR protocols before now, but the headers at least look to be formatted differently, and it uses the CCS7 id instead of callsign.
 
I'm using the new MB binary for amd64 that was committed yesterday on Debian Stretch.
 
Sorry to harp on this, but I'm wracking my brain trying to figure it out.  ASL/DMR/YSF was smooth from the start.

Brad N8QQ
 

Mike Zingman - N4IRR
 

Please make sure your call can be found by AB. It looks like it is resolving to only your ID, which is not a valid thing for D-Star 

On Tue, Jun 25, 2019 at 10:10 PM Brad McConahay <brad@...> wrote:
Just one more follow up. I'm wondering if the DExtra header going from MMDVM_Bridge to xlxd is possibly malformed.
 
This is MMDVM_Bridge running in the foreground with D-Star Network debug=1 
 
In the non-working direction: ASL --> AB --> MB --> ircddbgateway --> xlxd
 
M: 2019-06-26 00:58:47.244 D-Star, TX state = ON
I: 2019-06-26 00:58:47.244 D-Star, Begin TX: src=3139557 rpt=0 dst=98004 slot=2 cc=1 metadata=3139557
D: 2019-06-26 00:58:47.244 D-Star Network Header Sent
D: 2019-06-26 00:58:47.244 0000:  44 53 52 50 20 80 E5 00 D9 43 CE 4E 38 51 51 20    *DSRP ....C.N8QQ *
D: 2019-06-26 00:58:47.244 0010:  20 20 47 4E 38 51 51 20 20 20 43 43 51 43 51 43    *  GN8QQ   CCQCQC*
D: 2019-06-26 00:58:47.244 0020:  51 20 20 33 31 33 39 35 35 37 20 44 56 53 57 EC    *Q  3139557 DVSW.*
D: 2019-06-26 00:58:47.244 0030:  9D                                                 *.*
 
And in the working direction: xlxd --> ircddbgateway --> MB --> AB --> ASL
 
D: 2019-06-26 00:59:32.818 D-Star Network Header Received
D: 2019-06-26 00:59:32.818 0000:  44 53 52 50 20 9F 7F 00 00 00 00 4E 38 51 51 20    *DSRP ......N8QQ *
D: 2019-06-26 00:59:32.818 0010:  20 20 43 4E 38 51 51 20 20 20 47 43 51 43 51 43    *  CN8QQ   GCQCQC*
D: 2019-06-26 00:59:32.818 0020:  51 20 20 4E 38 51 51 20 20 20 20 42 52 41 44 E5    *Q  N8QQ    BRAD.*
D: 2019-06-26 00:59:32.818 0030:  A5                                                 *.*
 
Is that how that first header should look? I've never looked at any of the D-STAR protocols before now, but the headers at least look to be formatted differently, and it uses the CCS7 id instead of callsign.
 
I'm using the new MB binary for amd64 that was committed yesterday on Debian Stretch.
 
Sorry to harp on this, but I'm wracking my brain trying to figure it out.  ASL/DMR/YSF was smooth from the start.

Brad N8QQ
 

Brad McConahay - N8QQ
 

Thanks for the suggestion, Mike. Populating subscriber_ids.csv did put the call sign in the header instead of the CCS7 ID. Didn't realize that AB would affect that part of it.

It's still not opening the stream on xlxd though.

Thanks,

Brad 


On Wed, Jun 26, 2019 at 6:49 AM Mike Zingman - N4IRR <mike.zingman@...> wrote:
Please make sure your call can be found by AB. It looks like it is resolving to only your ID, which is not a valid thing for D-Star 

On Tue, Jun 25, 2019 at 10:10 PM Brad McConahay <brad@...> wrote:
Just one more follow up. I'm wondering if the DExtra header going from MMDVM_Bridge to xlxd is possibly malformed.
 
This is MMDVM_Bridge running in the foreground with D-Star Network debug=1 
 
In the non-working direction: ASL --> AB --> MB --> ircddbgateway --> xlxd
 
M: 2019-06-26 00:58:47.244 D-Star, TX state = ON
I: 2019-06-26 00:58:47.244 D-Star, Begin TX: src=3139557 rpt=0 dst=98004 slot=2 cc=1 metadata=3139557
D: 2019-06-26 00:58:47.244 D-Star Network Header Sent
D: 2019-06-26 00:58:47.244 0000:  44 53 52 50 20 80 E5 00 D9 43 CE 4E 38 51 51 20    *DSRP ....C.N8QQ *
D: 2019-06-26 00:58:47.244 0010:  20 20 47 4E 38 51 51 20 20 20 43 43 51 43 51 43    *  GN8QQ   CCQCQC*
D: 2019-06-26 00:58:47.244 0020:  51 20 20 33 31 33 39 35 35 37 20 44 56 53 57 EC    *Q  3139557 DVSW.*
D: 2019-06-26 00:58:47.244 0030:  9D                                                 *.*
 
And in the working direction: xlxd --> ircddbgateway --> MB --> AB --> ASL
 
D: 2019-06-26 00:59:32.818 D-Star Network Header Received
D: 2019-06-26 00:59:32.818 0000:  44 53 52 50 20 9F 7F 00 00 00 00 4E 38 51 51 20    *DSRP ......N8QQ *
D: 2019-06-26 00:59:32.818 0010:  20 20 43 4E 38 51 51 20 20 20 47 43 51 43 51 43    *  CN8QQ   GCQCQC*
D: 2019-06-26 00:59:32.818 0020:  51 20 20 4E 38 51 51 20 20 20 20 42 52 41 44 E5    *Q  N8QQ    BRAD.*
D: 2019-06-26 00:59:32.818 0030:  A5                                                 *.*
 
Is that how that first header should look? I've never looked at any of the D-STAR protocols before now, but the headers at least look to be formatted differently, and it uses the CCS7 id instead of callsign.
 
I'm using the new MB binary for amd64 that was committed yesterday on Debian Stretch.
 
Sorry to harp on this, but I'm wracking my brain trying to figure it out.  ASL/DMR/YSF was smooth from the start.

Brad N8QQ
 

Brad McConahay - N8QQ
 

Finally figured this out.
 
There might be a bug in the way AB or MB forms the d-star header, or I might've missed a directive somewhere saying that the call sign in subscriber_ids.csv needs to be padded to eight spaces.
 
If the call sign is not space-padded in subscriber_ids.csv, it puts a . immediately after the last occurence of the call sign in the header packet, which stops xlxd from seeing it as anything other than a regular non-header packet. In other words...
 
When doing: ASL -> AB -> MB -> ircddbgateway -> xlxd
 
If subscriber_ids.csv looks like this:
 
3139557,N8QQ
Then the DExtra header sent while watching MB in the foreground looks like:
(unwrapped from the hex editor style display)
 
DSRP ......N8QQ   GN8QQ   BCQCQCQ  N8QQ.   DVSWE\
                                       ^ no good
But if I pad the callsign out to eight characters, like:
 
3139557,N8QQ    
            ^^^^ four spaces
Then it shifts the dot out of the header, and xlxd opens the stream for transmit like it should.
 
I think I've seen other people here make this work, so maybe I was overlooking the mention of padding somewhere. (?)  I also didn't realize that subscriber_ids.csv came into play here until Mike gave me the hint that the dmr id needed to be somehow resolved into the call sign in AB.
 
Thanks,
 
Brad N8QQ

 

Steve N4IRS
 

Brad,
There is no need to edit the subscriber_ids.csv file. It should work as is. The code should be doing the padding. Though this message is informative, I would like you to duplicate the test you did in the message 6/25/2019 at 10:10 PM

This is MMDVM_Bridge running in the foreground with D-Star Network debug=1
 
In the non-working direction: ASL --> AB --> MB --> ircddbgateway --> xlxd
 
M: 2019-06-26 00:58:47.244 D-Star, TX state = ON
I: 2019-06-26 00:58:47.244 D-Star, Begin TX: src=3139557 rpt=0 dst=98004 slot=2 cc=1 metadata=3139557
D: 2019-06-26 00:58:47.244 D-Star Network Header Sent
D: 2019-06-26 00:58:47.244 0000:  44 53 52 50 20 80 E5 00 D9 43 CE 4E 38 51 51 20    *DSRP ....C.N8QQ *
D: 2019-06-26 00:58:47.244 0010:  20 20 47 4E 38 51 51 20 20 20 43 43 51 43 51 43    *  GN8QQ   CCQCQC*
D: 2019-06-26 00:58:47.244 0020:  51 20 20 33 31 33 39 35 35 37 20 44 56 53 57 EC    *Q  3139557 DVSW.*
D: 2019-06-26 00:58:47.244 0030:  9D                                                 *.*
 
And in the working direction: xlxd --> ircddbgateway --> MB --> AB --> ASL
 
D: 2019-06-26 00:59:32.818 D-Star Network Header Received
D: 2019-06-26 00:59:32.818 0000:  44 53 52 50 20 9F 7F 00 00 00 00 4E 38 51 51 20    *DSRP ......N8QQ *
D: 2019-06-26 00:59:32.818 0010:  20 20 43 4E 38 51 51 20 20 20 47 43 51 43 51 43    *  CN8QQ   GCQCQC*
D: 2019-06-26 00:59:32.818 0020:  51 20 20 4E 38 51 51 20 20 20 20 42 52 41 44 E5    *Q  N8QQ    BRAD.*
D: 2019-06-26 00:59:32.818 0030:  A5                                                 *.*

The test you did above is without AB being able to resolve DMR ID to a call sign. I need to see the same test where the metadata=N8QQ.

I do also want to thank you for posting a very complete request for help.

73, Steve N4IRS

On 7/1/2019 12:17 AM, Brad McConahay - N8QQ wrote:
Finally figured this out.
 
There might be a bug in the way AB or MB forms the d-star header, or I might've missed a directive somewhere saying that the call sign in subscriber_ids.csv needs to be padded to eight spaces.
 
If the call sign is not space-padded in subscriber_ids.csv, it puts a . immediately after the last occurence of the call sign in the header packet, which stops xlxd from seeing it as anything other than a regular non-header packet. In other words...
 
When doing: ASL -> AB -> MB -> ircddbgateway -> xlxd
 
If subscriber_ids.csv looks like this:
 
3139557,N8QQ
Then the DExtra header sent while watching MB in the foreground looks like:
(unwrapped from the hex editor style display)
 
DSRP ......N8QQ   GN8QQ   BCQCQCQ  N8QQ.   DVSWE\
                                       ^ no good
But if I pad the callsign out to eight characters, like:
 
3139557,N8QQ    
            ^^^^ four spaces
Then it shifts the dot out of the header, and xlxd opens the stream for transmit like it should.
 
I think I've seen other people here make this work, so maybe I was overlooking the mention of padding somewhere. (?)  I also didn't realize that subscriber_ids.csv came into play here until Mike gave me the hint that the dmr id needed to be somehow resolved into the call sign in AB.
 
Thanks,
 
Brad N8QQ

 

Brad McConahay - N8QQ
 

Hey Steve,
 
I've attached all my configs in a .tgz file that will expand hierarchically. It includes everything... ircddbgateway, asterisk, etc.  asl/dmr/ysf are all working in this system.

I originally tried setting up a new node with dvswitch with just d-star to test, but it was doing this same thing. I can do that again if need be. Anyway...
 
If I don't use a subscriber_ids.csv file in /opt/Analog_Bridge_dstar/Analog_Bridge.ini, I get this:
 
M: 2019-07-01 16:15:33.382 D-Star, TX state = ON
I: 2019-07-01 16:15:33.382 D-Star, Begin TX: src=3139557 rpt=313955705 dst=98004 slot=2 cc=1 metadata=3139557
D: 2019-07-01 16:15:33.382 D-Star Network Header Sent
D: 2019-07-01 16:15:33.382 0000:  44 53 52 50 20 C3 D9 00 EA 56 CD 4E 38 51 51 20    *DSRP ....V.N8QQ *
D: 2019-07-01 16:15:33.382 0010:  20 20 47 4E 38 51 51 20 20 20 42 43 51 43 51 43    *  GN8QQ   BCQCQC*
D: 2019-07-01 16:15:33.382 0020:  51 20 20 33 31 33 39 35 35 37 20 44 56 53 57 5F    *Q  3139557 DVSW_*
D: 2019-07-01 16:15:33.382 0030:  C5                                                 *.*
 
And MMDVM_Bridge startup includes these lines:
 
I: 2019-07-01 16:30:19.266 Subscriber IDs file not found.
I: 2019-07-01 16:30:19.266 Default extended metadata <3139557>
So... I don't know how to make it populate the metadata with the call sign rather than the dmr id without using subscriber_ids.csv

You didn't ask for these tests, but I'll include them anyway...

If I use a subscriber_ids.csv file populated with "3139557,N8QQ", then I get this:
 
M: 2019-07-01 16:19:46.526 D-Star, TX state = ON
I: 2019-07-01 16:19:46.526 D-Star, Begin TX: src=3139557 rpt=313955705 dst=98004 slot=2 cc=1 metadata=N8QQ
 
D: 2019-07-01 16:19:46.526 D-Star Network Header Sent
D: 2019-07-01 16:19:46.526 0000:  44 53 52 50 20 B9 9A 00 F8 14 D8 4E 38 51 51 20    *DSRP ......N8QQ *
D: 2019-07-01 16:19:46.526 0010:  20 20 47 4E 38 51 51 20 20 20 42 43 51 43 51 43    *  GN8QQ   BCQCQC*
D: 2019-07-01 16:19:46.526 0020:  51 20 20 4E 38 51 51 0A 20 20 20 44 56 53 57 AA    *Q  N8QQ.   DVSW.*
D: 2019-07-01 16:19:46.526 0030:  53                                                 *S*
 
(I'm just now noticing that there's a line break after the metadata line, after the call sign)
 
And MMDVM_Bridge startup info includes these lines:
 
1 16:21:47.393 Subscriber IDs loaded: 1
I: 2019-07-01 16:21:47.393 Default extended metadata <N8QQ    
>
 
(also with a line break after the call)
If I use subscriber_ids.csv file populated with "3139557,N8QQ    " (<--padded), then I get this:
 
M: 2019-07-01 16:22:03.727 D-Star, TX state = ON
I: 2019-07-01 16:22:03.727 D-Star, Begin TX: src=3139557 rpt=313955705 dst=98004 slot=2 cc=1 metadata=N8QQ    
 
D: 2019-07-01 16:22:03.727 D-Star Network Header Sent
D: 2019-07-01 16:22:03.728 0000:  44 53 52 50 20 C6 D9 00 6C 95 EC 4E 38 51 51 20    *DSRP ...l..N8QQ *
D: 2019-07-01 16:22:03.728 0010:  20 20 47 4E 38 51 51 20 20 20 42 43 51 43 51 43    *  GN8QQ   BCQCQC*
D: 2019-07-01 16:22:03.728 0020:  51 20 20 4E 38 51 51 20 20 20 20 44 56 53 57 9D    *Q  N8QQ    DVSW.*
D: 2019-07-01 16:22:03.728 0030:  BE                                                 *.*
And that one works with xlxd.

Anyway, not sure you wanted the subscriber_ids.csv parts of this, but it does look like there's something going on there with the line break regardless of what my initial problem is. Maybe it's not stripping the line break from the config file or some such. (I also noticed that if I try use a subscriber_ids.csv file for ASL <-> AB <-> MB <-> YSF, the YSF server logs have a line break after the callsign and it breaks the web dashboard until I remove those lines)

Thanks,

Brad N8QQ
 

Steve N4IRS
 

Brad,
That is what I wanted. Please post the script YOU are using to DL the subscriber_ids.csv file.

Thanks for the info.
Steve

On 7/1/2019 12:58 PM, Brad McConahay - N8QQ wrote:
Hey Steve,
 
I've attached all my configs in a .tgz file that will expand hierarchically. It includes everything... ircddbgateway, asterisk, etc.  asl/dmr/ysf are all working in this system.

I originally tried setting up a new node with dvswitch with just d-star to test, but it was doing this same thing. I can do that again if need be. Anyway...
 
If I don't use a subscriber_ids.csv file in /opt/Analog_Bridge_dstar/Analog_Bridge.ini, I get this:
 
M: 2019-07-01 16:15:33.382 D-Star, TX state = ON
I: 2019-07-01 16:15:33.382 D-Star, Begin TX: src=3139557 rpt=313955705 dst=98004 slot=2 cc=1 metadata=3139557
D: 2019-07-01 16:15:33.382 D-Star Network Header Sent
D: 2019-07-01 16:15:33.382 0000:  44 53 52 50 20 C3 D9 00 EA 56 CD 4E 38 51 51 20    *DSRP ....V.N8QQ *
D: 2019-07-01 16:15:33.382 0010:  20 20 47 4E 38 51 51 20 20 20 42 43 51 43 51 43    *  GN8QQ   BCQCQC*
D: 2019-07-01 16:15:33.382 0020:  51 20 20 33 31 33 39 35 35 37 20 44 56 53 57 5F    *Q  3139557 DVSW_*
D: 2019-07-01 16:15:33.382 0030:  C5                                                 *.*
 
And MMDVM_Bridge startup includes these lines:
 
I: 2019-07-01 16:30:19.266 Subscriber IDs file not found.
I: 2019-07-01 16:30:19.266 Default extended metadata <3139557>
So... I don't know how to make it populate the metadata with the call sign rather than the dmr id without using subscriber_ids.csv

You didn't ask for these tests, but I'll include them anyway...

If I use a subscriber_ids.csv file populated with "3139557,N8QQ", then I get this:
 
M: 2019-07-01 16:19:46.526 D-Star, TX state = ON
I: 2019-07-01 16:19:46.526 D-Star, Begin TX: src=3139557 rpt=313955705 dst=98004 slot=2 cc=1 metadata=N8QQ
 
D: 2019-07-01 16:19:46.526 D-Star Network Header Sent
D: 2019-07-01 16:19:46.526 0000:  44 53 52 50 20 B9 9A 00 F8 14 D8 4E 38 51 51 20    *DSRP ......N8QQ *
D: 2019-07-01 16:19:46.526 0010:  20 20 47 4E 38 51 51 20 20 20 42 43 51 43 51 43    *  GN8QQ   BCQCQC*
D: 2019-07-01 16:19:46.526 0020:  51 20 20 4E 38 51 51 0A 20 20 20 44 56 53 57 AA    *Q  N8QQ.   DVSW.*
D: 2019-07-01 16:19:46.526 0030:  53                                                 *S*
 
(I'm just now noticing that there's a line break after the metadata line, after the call sign)
 
And MMDVM_Bridge startup info includes these lines:
 
1 16:21:47.393 Subscriber IDs loaded: 1
I: 2019-07-01 16:21:47.393 Default extended metadata <N8QQ    
>
 
(also with a line break after the call)
If I use subscriber_ids.csv file populated with "3139557,N8QQ    " (<--padded), then I get this:
 
M: 2019-07-01 16:22:03.727 D-Star, TX state = ON
I: 2019-07-01 16:22:03.727 D-Star, Begin TX: src=3139557 rpt=313955705 dst=98004 slot=2 cc=1 metadata=N8QQ    
 
D: 2019-07-01 16:22:03.727 D-Star Network Header Sent
D: 2019-07-01 16:22:03.728 0000:  44 53 52 50 20 C6 D9 00 6C 95 EC 4E 38 51 51 20    *DSRP ...l..N8QQ *
D: 2019-07-01 16:22:03.728 0010:  20 20 47 4E 38 51 51 20 20 20 42 43 51 43 51 43    *  GN8QQ   BCQCQC*
D: 2019-07-01 16:22:03.728 0020:  51 20 20 4E 38 51 51 20 20 20 20 44 56 53 57 9D    *Q  N8QQ    DVSW.*
D: 2019-07-01 16:22:03.728 0030:  BE                                                 *.*
And that one works with xlxd.

Anyway, not sure you wanted the subscriber_ids.csv parts of this, but it does look like there's something going on there with the line break regardless of what my initial problem is. Maybe it's not stripping the line break from the config file or some such. (I also noticed that if I try use a subscriber_ids.csv file for ASL <-> AB <-> MB <-> YSF, the YSF server logs have a line break after the callsign and it breaks the web dashboard until I remove those lines)

Thanks,

Brad N8QQ
 

Brad McConahay - N8QQ
 

Steve,

Aha! Well, your question just solved it for me. There was no DL'ing of anything. I was populating subscriber_ids.csv by hand with, literally, what you see above. No other fields. I guess because there were other lookup files already being used elsewhere, I just assumed this was some quick two-field populated-by-hand thing.

I just now grabbed a copy of the dmr database and used it instead, and now everything works exactly like it should, including the YSF carriage return problem.

Doesn't seem like anybody else has stumbled on this, so I'm wondering if I missed some setup info somewhere.  I just worked off of your original ASL <-> DMR doc and what I could find here in the group that was specific to xlxd w/ dstar.

And thanks! (Thanks in general... I consider dvswitch to be pretty revolutionary in the ROIP world.)

Brad N8QQ

Steve N4IRS
 

Brad,
That is great to hear. The ASL <-> DMR document uses apt-get install to install the scripts used to DL the datafiles needed. The scripts are in /usr/local/sbin and should have softlinks to /etc/cron.daily. Since RadioID has made some changes, I will be updating the scripts.
For now you can find them on github in <https://github.com/DVSwitch/DVSwitch-System-Builder/tree/master/Directories/usr/local/sbin>

The purpose of System-Builder is to install all of the directories, programs and scripts someone would need to build a bridge. It is a "work in progress"

73, Steve N4IRS

On 7/1/2019 2:08 PM, Brad McConahay - N8QQ wrote:
Steve,

Aha! Well, your question just solved it for me. There was no DL'ing of anything. I was populating subscriber_ids.csv by hand with, literally, what you see above. No other fields. I guess because there were other lookup files already being used elsewhere, I just assumed this was some quick two-field populated-by-hand thing.

I just now grabbed a copy of the dmr database and used it instead, and now everything works exactly like it should, including the YSF carriage return problem.

Doesn't seem like anybody else has stumbled on this, so I'm wondering if I missed some setup info somewhere.  I just worked off of your original ASL <-> DMR doc and what I could find here in the group that was specific to xlxd w/ dstar.

And thanks! (Thanks in general... I consider dvswitch to be pretty revolutionary in the ROIP world.)

Brad N8QQ

Mike Zingman - N4IRR
 

just an FYI when you manually edited the file you added a carriage return line feed and that is the problem if you look at the output you'll see the line feed is embedded in the data


On Mon, Jul 1, 2019, 2:15 PM Steve N4IRS <szingman@...> wrote:
Brad,
That is great to hear. The ASL <-> DMR document uses apt-get install to install the scripts used to DL the datafiles needed. The scripts are in /usr/local/sbin and should have softlinks to /etc/cron.daily. Since RadioID has made some changes, I will be updating the scripts.
For now you can find them on github in <https://github.com/DVSwitch/DVSwitch-System-Builder/tree/master/Directories/usr/local/sbin>

The purpose of System-Builder is to install all of the directories, programs and scripts someone would need to build a bridge. It is a "work in progress"

73, Steve N4IRS

On 7/1/2019 2:08 PM, Brad McConahay - N8QQ wrote:
Steve,

Aha! Well, your question just solved it for me. There was no DL'ing of anything. I was populating subscriber_ids.csv by hand with, literally, what you see above. No other fields. I guess because there were other lookup files already being used elsewhere, I just assumed this was some quick two-field populated-by-hand thing.

I just now grabbed a copy of the dmr database and used it instead, and now everything works exactly like it should, including the YSF carriage return problem.

Doesn't seem like anybody else has stumbled on this, so I'm wondering if I missed some setup info somewhere.  I just worked off of your original ASL <-> DMR doc and what I could find here in the group that was specific to xlxd w/ dstar.

And thanks! (Thanks in general... I consider dvswitch to be pretty revolutionary in the ROIP world.)

Brad N8QQ

Brad McConahay - N8QQ
 

Steve - I see the scripts symlinked into /etc/cron.daily. I'll trace it around soon and see why it doesn't seem to be updating. It's a standard Debian Stretch instance on Vultr. It's also having trouble connecting to any xlx reflector without manually putting it in one of the host files, so it doesn't seem to be updating that data either.

Mike - Thanks. Yeah, I was basically feeding it a corrupt data file, I'm surprised that's all it did. Still can't believe I didn't think to maybe just try a few more commas, or simply realize that it at least needed the dmr database. :-)

Thanks again, both of you.

Brad N8QQ

Steve N4IRS
 

Brad,
Here is the script you want to run. Check the destination for the file is correct. <https://github.com/DVSwitch/DVSwitch-System-Builder/blob/master/Directories/usr/local/sbin/HBIDUpdate.sh>

Steve

On 7/1/2019 3:55 PM, Brad McConahay - N8QQ wrote:
Steve - I see the scripts symlinked into /etc/cron.daily. I'll trace it around soon and see why it doesn't seem to be updating. It's a standard Debian Stretch instance on Vultr. It's also having trouble connecting to any xlx reflector without manually putting it in one of the host files, so it doesn't seem to be updating that data either.

Mike - Thanks. Yeah, I was basically feeding it a corrupt data file, I'm surprised that's all it did. Still can't believe I didn't think to maybe just try a few more commas, or simply realize that it at least needed the dmr database. :-)

Thanks again, both of you.

Brad N8QQ

Brad McConahay - N8QQ
 

Steve,

Sure enough, the HBIDUpdate.sh i have is old...

wget -O /var/lib/dvswitch/subscriber_ids.csv -q --no-check-certificate "https://www.radioid.net/static/users.csv
Okay, I've cloned System-Builder and will keep it up to date. I assumed it was just a one time installer kind of thing that could be discarded and hadn't really given it a second thought. I hadn't seen the readme.txt in there -- it's pretty valuable.

Thanks!

Brad