Date   
Re: Recording your QSO's as an MP3 file

Joshua Nulton
 

My mistake Steve, feel free to remove the post. 


On Mon, Jul 8, 2019 at 5:07 AM Steve N4IRS <szingman@...> wrote:
Jae,
To be clear, this subgroup is intended for discussion of interfacing with AllStarlink, not general ASL support. Since you are already posting in the general ASL user list, that should be sufficient.

73, Steve N4IRS 

On 7/8/19 3:56 AM, Joshua Nulton wrote:
I have put together a <15 minute tutorial on everything needed to record the QSO's on your Allstar node, move them to an internet accessible web folder and convert them from large .WAV files (the compression used is not all that bad really) into manageable .MP3 files that will play back simply through your browser.
 
YouTube link: https://youtu.be/SnOBoF85k0k
 
The process requires the installation of 4 packages.
  1. Apache2 (most likely have this installed already)
  2. rsync (very small, lightweight and reliable)
  3. ffmpeg to convert the audio
  4. lame encoder to convert to mp3 codec
Installation and configuration of everything is demonstrated in the YouTube tutorial video. If you don't want to type out the bash script it can be downloaded here:
 
The software mentioned above will still need installed as per video instructions. Quick overview is here:
 
sudo -s
apt update
apt-get install apache2
apt-get install rsync
apt-get install ffmpeg
apt-get install lame
mkdir /var/www/html/library
 
Enjoy and if you have any questions, please post them on the official Allstar Community forum here: https://community.allstarlink.org/
73's
Jae   KG5EBI

Re: Recording your QSO's as an MP3 file

Steve N4IRS
 

Jae,
To be clear, this subgroup is intended for discussion of interfacing with AllStarlink, not general ASL support. Since you are already posting in the general ASL user list, that should be sufficient.

73, Steve N4IRS 

On 7/8/19 3:56 AM, Joshua Nulton wrote:
I have put together a <15 minute tutorial on everything needed to record the QSO's on your Allstar node, move them to an internet accessible web folder and convert them from large .WAV files (the compression used is not all that bad really) into manageable .MP3 files that will play back simply through your browser.
 
YouTube link: https://youtu.be/SnOBoF85k0k
 
The process requires the installation of 4 packages.
  1. Apache2 (most likely have this installed already)
  2. rsync (very small, lightweight and reliable)
  3. ffmpeg to convert the audio
  4. lame encoder to convert to mp3 codec
Installation and configuration of everything is demonstrated in the YouTube tutorial video. If you don't want to type out the bash script it can be downloaded here:
 
The software mentioned above will still need installed as per video instructions. Quick overview is here:
 
sudo -s
apt update
apt-get install apache2
apt-get install rsync
apt-get install ffmpeg
apt-get install lame
mkdir /var/www/html/library
 
Enjoy and if you have any questions, please post them on the official Allstar Community forum here: https://community.allstarlink.org/
73's
Jae   KG5EBI

Recording your QSO's as an MP3 file

Joshua Nulton
 

I have put together a <15 minute tutorial on everything needed to record the QSO's on your Allstar node, move them to an internet accessible web folder and convert them from large .WAV files (the compression used is not all that bad really) into manageable .MP3 files that will play back simply through your browser.
 
YouTube link: https://youtu.be/SnOBoF85k0k
 
The process requires the installation of 4 packages.
  1. Apache2 (most likely have this installed already)
  2. rsync (very small, lightweight and reliable)
  3. ffmpeg to convert the audio
  4. lame encoder to convert to mp3 codec
Installation and configuration of everything is demonstrated in the YouTube tutorial video. If you don't want to type out the bash script it can be downloaded here:
https://drive.google.com/open?id=1-z9UgW_L81MKl9eBKqMmDeT0xO9jl7qE
 
The software mentioned above will still need installed as per video instructions. Quick overview is here:
 
sudo -s
apt update
apt-get install apache2
apt-get install rsync
apt-get install ffmpeg
apt-get install lame
mkdir /var/www/html/library
 
Enjoy and if you have any questions, please post them on the official Allstar Community forum here: https://community.allstarlink.org/
73's
Jae   KG5EBI

Re: Echolink not linking in monitor mode (ASL Asterisk)

Brad McConahay - N8QQ
 

Thanks Mike, that does help. The private asl node workaround works great.

Brad N8QQ

Re: Echolink not linking in monitor mode (ASL Asterisk)

Mike KB8JNM
 

To my current knowledge, (and things may have changed)

Under EchoLink RULES, 'ALL' EchoLink connections 'must be full-duplex'.

Monitor, under this rule,  is not permitted. I certainly had never made that work anyway.

*23xxxxxx is always *33xxxxxx

One method around this is to make a private ASL node to attach the echolink connection to and connect to that private node to your public node in monitor mode.

perhaps something has changed ? someone else may chime in with better answer? perhaps that helps.

...mike/kb8jnm

Echolink not linking in monitor mode (ASL Asterisk)

Brad McConahay - N8QQ
 

Not sure this is the right place since it's not directly related to bridging, but I am using ASL Asterisk with the repo hosted on dvswitch.org/ASL_Repoistory. Just let me know if this would be better somewhere else.

This is on an install based on the directions here, on Debian 9, both at Digital Ocean and Vultr:

https://wiki.allstarlink.org/wiki/ASL_FAQ#Can_ASL_be_installed_on_an_existing_Linux_install.2C_for_example_on_a_VM_running_Debian.3F

When trying to connect to an Echolink node in monitor mode, it just connects in regular transceive mode.

For instance, the following things are true...

# this links to an allstar node in monitor mode (rx_only), like normal
*CLI> rpt cmd 50004 ilink 2 45863 

# this links to an echolink node in tranceive mode rather than in monitor mode 
*CLI> rpt cmd 50004 ilink 2 3040065
I've tried it with echolink.conf settings from a working hamvoip-on-rpi node, but that doesn't change anything. It happens with any Echolink station or conference I've tried connecting to.

The only other thing I've found odd about it is that, everytime an Echolink connection is made, asterisk logs:

[Jul  7 21:37:35] ERROR[20026]: chan_echolink.c:2586 do_new_call: Cannot find DB entry for IP addr 
But it doesn't stop the connection.

Thought maybe it would be a known issue that hasn't been resolved yet, but I'm not finding anything via google. I know another station using DVSwitch with this same version of ASL who says the same thing is true for him.

Anybody have any info or ideas?

Thanks,

Brad N8QQ

Re: Adding second DMR bridge

Joshua Nulton
 

Yes, two talkgroups on the same node. But not crosslinked to any other node, no RF, no analog - just digital only, and not re-broadcasting.

I appreciate the tips Steve, I will start looking in that direction.

I could offer several variants of how this could be appealing. I could say I want to archive the audio from 2 interesting tech nets that are on the same schedule for use in a podcast or to simply listen to the net that I didn't have time to make it to. I could say that it is being used on a private hub for a taxi company that dispatchers need to hit the rewind button on. Or I could say that I am hard of hearing and prefer to run the audio through a transcription service to still enjoy radio. Not at all being a smart&*^... just offering a few scenarios that the concept could be useful in. BM gave us hoseline when they first started, then cut it down to almost nothing active on very few talkgroups and never offered us any alternatives. If it could be done, why was it taken away? Why was it never explained? 

I am not here to bash them nor anyone else. I just wanna try to replicate what they had done for my private talkgroups. Foremost, I just want to experiment and try doing it to see how it is done, this is the entire reason I got into radio, for the playing. Thanks again for the reply Steve. :)

Re: Adding second DMR bridge

Steve KC1AWV
 

Are you trying to link two talkgroups on the same ASL node at the same time?

You'll need to create separate .ini files for each link. You will also have to pay attention to port usage, since you're going to be routing calls on the same mode through one system.

Yes, it can be done. The docs that are available are usually for going from one mode to another. If you're trying to link two talkgroups, that's kinda defeating the purpose of having them?


On Wed, Jul 3, 2019 at 5:12 PM Joshua Nulton <kg5ebi@...> wrote:
Does anyone know if there is an existing article, post, tutorial or video explaining how to add a second DMR bridge/node on the same host? Would I need to create another stanza for say a USRP2? What files might need modified or duplicated?



--
Steve Miller
KC1AWV

Adding second DMR bridge

Joshua Nulton
 

Does anyone know if there is an existing article, post, tutorial or video explaining how to add a second DMR bridge/node on the same host? Would I need to create another stanza for say a USRP2? What files might need modified or duplicated?

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

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

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

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

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

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

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

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

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

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

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

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

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

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
 

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

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
 

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

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

 

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

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

 

Re: DMR (and possibly others) local analog bridge

Steve N4IRS
 

AB = Analog_Bridge
MB = MMDVM_Bridge
You will need a radio, MMDVM board and host computer to build the MMDVM HotSpot.

On 6/28/2019 12:25 PM, Ryan Reid wrote:
Not sure what AB & MB stands for what I am trying for is:
Repeater <-> ASL <-> 5Ghz <-> ASL & Repeater1 <-> ??? <-> MMDVM board <-> Repeater2
(Repeater1 & 2 are same site, different frequencies)

For connecting different areas, without relying on Commercial Internet.  Is this "HBlink" the software I need?

Thank you.

On Fri, Jun 28, 2019, 07:45 Steve N4IRS <szingman@...> wrote:
If I understand what you are trying to do you want something like this:

ASL <-> 5 GHz <-> ASL <-> DMR User Radio

ASL <-> 5 GHz <-> ASL <-> AB <-> MB <-> HBlink <-> MMDVM HotSpot <-> DMR User Radio

The MMDVM HotSpot would probably need to be a high power system built out of a radio, MMDVM board, RPi. The HotSpot could also be a MMDVM based repeater.

Steve N4IRS

On 6/28/2019 3:31 AM, Ryan Reid wrote:
I have set up the All-Star bridge with brandmeister and a DMR talk group. I want to build a portable node for emergency use that has allstar access through 5 GHz link to another allstar node but can receive analog, DMR, (TG2) other modes locally into that allstar node without going to brandmeister and then sent through the 5 GHz to another site what can be simulcast through analog, DMR, d-star etc.
  Is it possible to bridge ASL and DMR without going through brandmeister or any outside node?

Thanks in advance.