Topics

ASL to DMR change TG with DTMF?


w2jon@...
 

Hey gang. I've been running the Crompton Allstar image for about a year and just added the dmr integration to my node.
While it is running well I would like to ask if there is a way to change TG on the fly similarly to the way you can add or remove A* nodes with dtmf.

I ask because I built my node as a portable unit with an integrated baofeng 888 and syba dongle.
This allows me to use my HT or mobile rig to access the networks. The addition of DMR really rounds out the project.

So I may need some more schooling but as I understand it BM forwards the static TG to your hotspot and the bridge forwards out to the defined TG in the .ini . this makes up both ends of the tunnel so to speak.
I'm curious if there is an API to set the BM side and if so then Id imagine a change to the ini and BM config could be made?

I will elaborate more if this isnt clear. Sorry I'm typing from my phone in the mall parking lot..
Lol
-jon (W2JON)


w2jon@...
 
Edited

Actually, thinking about it.. DTMF is surpressed outside of the A* node so maybe my question should be more generalized as can the TG be changed via commands on the node itself or by .agi? Again, I may be misunderstanding the BM side of the game. But if the .ini and BM need to jive for inbound and outbound to work an API would need to be tapped into or an elaborate curl script written to change the static TG.. 
Thanks again .


Steve N4IRS
 

DMR TG can be switched on the fly from a AllStar node. If you need to be able to dial a arbitrary TG, it works like a autopatch call or if you just want to select a small list of TGs, you can do it as scripts.
The autopatch method passes a arbitary string to dvswitch.sh for tuning to a TG.

Steve 

On 12/23/2019 10:48 AM, w2jon@... wrote:
Actually, thinking about it.. DTMF is surpressed outside of the A* node so maybe my question should be more generalized as can the TG be changed via commands on the node itself or by .agi scripts.
Thanks again .


w2jon@...
 

Oh hey, thats great!
Sorry I'm so green. 
But hey at least Im not asking basic setup questions.
Do you have any links to docs on this config process? 
i'd hate to ask for step by step directions but honestly getting it running without prior exposure to the payload was enough of a challenge lol.

Thanks again Steve and thanks for all of your and othet team members efforts


Steve N4IRS
 

Jon,
Here is the discussion about sending a string to a external program <https://dvswitch.groups.io/g/allstarlink/topic/28137868#373>
You can replace your existing Analog_Bridge executable with the most current from github <https://github.com/DVSwitch/Analog_Bridge>
Along with AB, grab dvswitch.sh which will make your life SO much easier for the tuning (changing TG) process.

On 12/23/2019 11:01 AM, w2jon@... wrote:
Oh hey, thats great!
Sorry I'm so green. 
But hey at least Im not asking basic setup questions.
Do you have any links to docs on this config process? 
i'd hate to ask for step by step directions but honestly getting it running without prior exposure to the payload was enough of a challenge lol.

Thanks again Steve and thanks for all of your and othet team members efforts


w2jon@...
 
Edited

That's great!
I'll check it out today.
Thanks again and I hope to reply with good results.

My only other question right now is..
Do I need to define a static TG in BM?
Or does the node side ini defined TG handle in and outbound communications?


Steve N4IRS
 

No, you don't need (or want) a static TG defined. The TG choice will be made when you connect to BM from the .ini (or tune)

On 12/23/2019 11:43 AM, w2jon@... wrote:

[Edited Message Follows]

That's great!
I'll check it out today.
Thanks again and I hope to reply with good results.

My only other question right now is..
Do I need to define a static TG in BM?
Or does the node side ini defined TG handle in and outbound communications?


w2jon@...
 

Super! 
Thanks for clearing that up for me.

I really do appreciate that info.


Steve N4IRS
 

Think of it this way, An ASL to digital bridge is no different then a simplex digital hotspot. You don't want BM sending you more then one TG at a time. When I move around on DMR, I send a TG4000 (disconnect) before tuning to a new TG.

Steve

On 12/23/2019 12:04 PM, w2jon@... wrote:
Super! 
Thanks for clearing that up for me.

I really do appreciate that info.


w2jon@...
 

I will definitely be back with more questions but I will keep that in mind for sure.
From an AllStar user stand-point, I can certainly understand closing down nodes or talkgroups when done with them.
I have in the past had several nodes linked in on A* that people connect and forget.

But really, thanks Steve this is great.

-jon


w2jon@...
 
Edited

Am I correct in selecting the Analog_Bridge.arm64 as my replacement executable for ArchLinux?
Pi 3B+


Steve N4IRS
 

I doubt it. What is the result of uname -a?

On 12/23/2019 12:31 PM, w2jon@... wrote:
Am I correct in selecting the Analog_Bridge.arm64 as my replacement executable for ArchLinux?


w2jon@...
 
Edited

Oh hah. armv7l


Steve N4IRS
 

As far as I know few distributions are ARM64 yet. Just trying to me "proactive"

On 12/23/2019 12:43 PM, w2jon@... wrote:
Oh hah. armv71 


w2jon@...
 

I can appreciate that. I don't know why I assumed this would have been arm64

Anyway I backed up the original file, plopped a copy of the arm6l into the opt/Analog_Bridge directory and stripped its extension
I think this is the proper procedure. LOL


w2jon@...
 

Ok, I was able to update the Audio_Bridge executable and I started bringing in some of the config file differences.

in my rtp.conf my primary allstar node has  a functions= functions{nodenumber} directive which corresponds with the defined functions context.

if I insert the provided functions section from your github i am assuming that I would need to add a functions = functions1999 to my 1999 node and rename the new functions section [functions1999] 

If I do this then I can use the Supermon DTMF command to send over the change.. this works so far.. but I cannot tell if it;s changing TG's I tried to change to the parrot 9990 TG and I didnt hear anyone although BM shows other peoples activity on the last heard page.. I also do not get into the parro TG when keyed up.

Also do I need to remove the txTg= 9 from my Analog_Bridge.ini?
and also where should I place the various support files ? I see the scripts go in analog_bridge but I'm not sure of the location for the macro file or it's contents?. 
Sorry Steve.. I know I'm close but there is much to learn. I think the bigest issue is that I'm using cromptons image and there seems to be a bunch of decrepancies agains the available documentation on the various processes.

Thanks


Steve N4IRS
 

Inline:

On 12/23/2019 2:42 PM, w2jon@... wrote:
Ok, I was able to update the Audio_Bridge executable and I started bringing in some of the config file differences.

in my rtp.conf my primary allstar node has  a functions= functions{nodenumber} directive which corresponds with the defined functions context.

if I insert the provided functions section from your github i am assuming that I would need to add a functions = functions1999 to my 1999 node and rename the new functions section [functions1999] 

If you are inserting functions, I would insert them in the working function stanza.

If I do this then I can use the Supermon DTMF command to send over the change.. this works so far.. but I cannot tell if it;s changing TG's I tried to change to the parrot 9990 TG and I didnt hear anyone although BM shows other peoples activity on the last heard page.. I also do not get into the parro TG when keyed up.

Also do I need to remove the txTg= 9 from my Analog_Bridge.ini?
and also where should I place the various support files ? I see the scripts go in analog_bridge but I'm not sure of the location for the macro file or it's contents?. 
Sorry Steve.. I know I'm close but there is much to learn. I think the bigest issue is that I'm using cromptons image and there seems to be a bunch of decrepancies agains the available documentation on the various processes.

txTG=9 tells AB to startup on TG9. I would suggest you get used to dvswitch.sh as your command interface to AB. just run dvswitch.sh for a list of available commands.

Steve

Thanks


w2jon@...
 

The reason I asked about the functions is that they appear that there would be conflicting with the Allstar node functions.
i may be 100% off on this but this is my understanding.

i.e Allstar node function 73=ilink,13 ; connect link permanent transceive = *73<node> vs  DVSwitch  73 = cmd, /opt/Analog_Bridge/dvswitch.sh tune 4000    ; Tune the TG 4000 (Unlink from last TG)


 

 


Steve N4IRS
 

The functions would be "local" to the node, so,
If you are sending a command from your normal node, *73 would execute *73<node> and if you execute the command from the private node, *73 would tune you to 4000.
Clear as mud?

On 12/23/2019 3:01 PM, w2jon@... wrote:

The reason I asked about the functions is that they appear that there would be conflicting with the Allstar node functions.
i may be 100% off on this but this is my understanding.

i.e Allstar node function 73=ilink,13 ; connect link permanent transceive = *73<node> vs  DVSwitch  73 = cmd, /opt/Analog_Bridge/dvswitch.sh tune 4000    ; Tune the TG 4000 (Unlink from last TG)


 

 


w2jon@...
 

haha yeah pretty much..
From what I can say is that since my primary node Allstar 48353 uses my USB audio to link to my interface radio I only have one method to inject the DTMF tones into the node. 
I connect to the private node running the AB with *731999 that links me from analog to the DMR side 
Since DTMF is not allowed to leave the 48353 node it doesn't pass over to 1999 for commanding.  

So If I understand you the unmodified [functions] section would live happily as the "default" command set and because my A* node is using a directive to tell it which functions set to use [functions48353] it will not try to use the ones we are inserting into the file. If I key a command that isn't in the custom functions section it may / or may not find it in the standard functions section?

It seems that the only method to control that private node would be via the Supermon page after selecting the 1999 node from the top. then I could enter *79{TG#} and the 1999 node would react to this.
If I was to allow dtmf to pass the primary a* node would intercept the commands and act on them as it is the node receiving the audio first from the radio/dongle.
I think in order to use dtmf I would then A: enable DTMF passthrough, and B: create new command codes that don't conflict with the A* commands. 
crazy huh? lol