There isn’t a whole lot of discussion here on these. First I find few VHF/UHF radios support CIV. Then you’re relying on hamlib support. In the case of the TM-V71A, the support is only partially there. The network dameon part rigctrld is not functional.
It would be idea to announce the currently tuned frequency to a remote user upon connection.
Has anyone done this?
It would also be slick if there was supermon support.
I set up a script in Asterisk that reads DTMF codes (*99, #) that trigger short shell scripts that will send CAT PTT commands to my IC-9100 over the USB interface.
The features.conf file will set up capture of the DTMF and pass along to a shell script. You also have to set up the extensions.conf file for your radio-extension. More CAT commands is something I’ve wanted to do but haven’t had time. Now that the holidays are over I might revisit. You will probably have to record a few words like “Megahertz” so that it can speak properly.
One thing I want to do is use the SendText() command instead of announcing the frequency. That way it shows on the handset display.
Could you post an example of what you put in functions.conf? The documentation in that file and in that link is not very clear. For example if I wanted to call a script eg. AGI(script.sh) or directly call a script, from a DTMF command eg. *699 is that easy to do?
BTW would also be nice if the PTT command from SIP phones could be shortened from *99 to just one digit… maybe like just a 5 to key PTT and # to unkey…?
This is primarily Icom protocol.
The only model asl supports directly is ic706mkii. Not the standard 706.
You will find much more flexibility with Kenwood and Yaesu in using the built-in interface.
Otherwise, you have to create your own external controls.
If you must use CIV, contact me off-list.
I just added the following lines to functions.conf
; Added for keying up ICOM IC-9100 over USB using Hamlib
ptt-on-9100 => *99,caller,System,/usr/local/bin/ptt_on_9100.sh
ptt-off-9100 => #,caller,System,/usr/local/bin/ptt_off_9100.sh
The ptt-on-9100 is just the name for the command. I used *99 and # to maintain default commands for keying/unkeying the node, you can make it whatever you wish.
ptt_on_9100.sh:
#!/usr/bin/env bash
set -euo pipefail
PORT=/dev/ttyUSB0
BAUD=19200
MODEL=3068
rigctl -m $MODEL -r $PORT -s $BAUD T 1
ptt_off_9100.sh:
#!/usr/bin/env bash
set -euo pipefail
PORT=/dev/ttyUSB0
BAUD=19200
MODEL=3068
rigctl -m $MODEL -r $PORT -s $BAUD T 0
Pretty simple script. I should probably add some feedback and a timeout timer if I’m going to beyond proof of concept.
Finally had a chance to try this attempt at making a DTMF command in features.conf, but it does nothing. K0JEG you mentioned functions.conf but there is no such file so I think you mean features.conf? So in that file I added:
Under [applicationmap] -
test-play => *91,caller,Playback,/usr/share/asterisk/agi-bin/test
Then in the comments the file says:
; Dynamic Feature Groups:
; Dynamic feature groups are groupings of features defined in [applicationmap]
; that can have their own custom key mappings. To give a channel access to a dynamic
; feature group, add the group name to the value of the DYNAMIC_FEATURES variable.
;
; example:
; [myGroupName] ; defines the group named myGroupName
; testfeature => #9 ; associates testfeature with the group and the keycode '#9'.
; retrieveinfo => ; associates retrieveinfo with the group and uses the keycode specified
; ; in the [applicationmap].
So I added the below under that:
[dtmfGroup]
test-play =>
And it also says:
; Note that the DYNAMIC_FEATURES channel variable must be set to use the features
; defined here. The value of DYNAMIC_FEATURES should be the names of the features
; to allow the channel to use separated by '#'. For example:
;
; Set(__DYNAMIC_FEATURES=myfeature1#myfeature2#myfeature3)
;
; (Note: The two leading underscores allow these feature settings to be set
; on the outbound channels, as well. Otherwise, only the original channel
; will have access to these features.)
;
; The syntax for declaring a dynamic feature is any of the following:
;
; => <DTMF_sequence>,[/],[,[,MOH_Class]]
;
But it’s not at all clear where that Set is supposed to go, and some web searches seem to indicate that these “features” only apply when a call is active? So does that mean only if another node is connected, or is app-rpt itself and a channel driver considered an ‘active’ call?
The more I use ASL the more I am convinced that Asterisk is a ridiculously overcomplicated platform for a ham ROIP app, and basic things like defining a DTMF command cannot just be directly done in any simple way. The way I do them now with an ‘autopatch’ line in rpt.conf that calls a context in extensions.conf works well enough, but it has some limitations and would be nice if there was a simpler way like alluded to above with just a simple one line definition of the command and a shell script or Asterisk function to be called. Thanks, NR9V
Apologies, the file is /etc/asterisk/features.conf
In my case I created a Dynamic Feature Group called “System” that is used to call the shell scripts. I’m also working on some Python code that will evoke an MQTT topic/message to send many different commands.
; Dynamic Feature Groups:
; Dynamic feature groups are groupings of features defined in [applicationmap]
; that can have their own custom key mappings. To give a channel access to a to a dynamic
; feature group, add the group name to the value of the DYNAMIC_FEATURES variable
;
; example:
; [myGroupName] ; defines the group named myGroupName
; testfeature => #9 ; associates testfeature with the group and the keycode '#9'.
; retrieveinfo => ; associates retrieveinfo with the group and uses the keycode specified
; ; in the [applicationmap].
; Added for keying up ICOM IC-9100 over USB using Hamlib
ptt-on-9100 => *99,caller,System,/usr/local/bin/ptt_on_9100.sh
ptt-off-9100 => #,caller,System,/usr/local/bin/ptt_off_9100.sh
You mentioned that you "created a Dynamic Feature Group called “System”...", can you go into more detail on how and where you did that? As I mentioned I think I already did that, with under [applicationmap] -
test-play => *91,caller,Playback,/usr/share/asterisk/agi-bin/test
And then further down,
[dtmfGroup]
test-play =>
But nothing happens.
As I also mentioned, some web searches seem to indicate that these “features” only apply when a call is active - which seems to mean only if another node is connected. Or is app-rpt itself and a channel driver considered an ‘active’ call?? This seems like a fundamental distinction that really ought to be clarified somewhere. (But as it is it just seems to get clearer over time that Asterisk is an overly-complex, bloated and unnecessary platform for an AllStar app to be built on for the vast majority most use cases. There seem to be only about 5 people in the entire ham radio hobby that actually have enough expertise in Asterisk to be able to fully understand the gobbledygook in extensions.conf and various other .conf files, much less actually explain it to anyone else. This would all be so much easier with a simple script file that allowed system events to be processed in python or any other desired standard scripting language.)
Perhaps this works for you in a remote base use case because you made an inbound connection to the node and thus have an 'active' call and Asterisk will then actually look for DTMF events. But from what I can tell features.conf seems useless for generally supporting a DTMF command when a "call is not active".
Yes, I'm using an unconventional setup for my node. Instead of devices connected directly through Allstar I treat them like SIP extensions. In addition to actual hardware phones I also use a program called BareSIP ( GitHub - baresip/baresip: Baresip is a modular SIP User-Agent with audio and video support · GitHub ). This then connects to sound cards, radios, etc. It can generate RFC 2833 DTMF tones over to Allstar/asterisk. Note that for some initial setup I ran BareSIP on the same Pi that is running my Allstar node, there's plenty of machine cycles for both
I'm using Asterisk/Allstar in a somewhat nontraditional way to route audio in the shack, not necessarily for node to node communication (although any of my connected radios or devices can use the node to connect to the outside world). BareSIP can be set up to dial to the node on launch, auto-answer on zero rings, etc. The nice thing about it is I can use any SIP devices (such as softphone apps on PCs and mobile phones) as speaker/mics and vice versa.
I'm not all that well versed in the inner workings of rpt_apt, so there's probably some other way of doing this. I just want to keep things as modular as I can.
have you considered creating block diagram(s) and descriptions in modest detail of your creation?
(for the benefit of those who wish to explore your clever possibilities)
These two slides are from a teaser presentation I did for the local radio club last month. I've been dancing around many of these ideas for several years now, starting back in 2016 trying to operate an HT that was mounted on a drone, later rack mounting my IC-9100 (making it nearly impossible to use interactively), and the untimely failure of our club repeater's PA leading me to revisit Allstar to use the repeater from my house. A lot of what I'm trying comes from my old job working for telecom companies where it was pretty rare to have any controls on equipment front panels, usually just power and "trouble" lights. Everything else was done through PC interfaces. The other motivation is from running audio workstations with MIDI control surfaces and Streamdeck buttons. There's really no need for complicated front panels on radios anymore (even Icom has remote software and controllers), but there needs to be an easy to roll out standard. The next step in the project is to get an ESP32 radio interface that can handle SIP and CAT/MQTT translation. The idea is to get all my radios on the switchboard and able to cross-band each other, reach any radio from a SIP handset and be able to "conference" phones and radios at the same time. The audio part is pretty easy thanks to Allstar/asterisk. Control is getting there with MQTT and eventually NodeRed.
There's a whole lot more work I have to do on this project but the basic framework seems to work pretty well and doesn't require any exotic hardware or software. I don't want to hijack the thread so I'll shut up now.
