Anything you read here is free for you to dowload, mash, destroy etc, use as you see fit. Read carefully and then read again. (then run away!) If any of the links don't work, they're broken! (sorry!) I will attach scripts as I go along. As this page is new, expect a few 'broken bits'.. Any script I used or modified will still contain the original 'whos who' at the start. I DO NOT remove other peoples header info, names, or otherwise. Credit where credit's due! For those of you who are interested enough, the buttons above will link you to a copy of the 'custom' folders in both scripts and audio, so you can see 'what gives' without wading through this stuff.
Before I get too carried away, the 'IRLP Script Files' button will display a list of files as found in the '/home/irlp/custom' folder.. I will give a quick blurb about some of the files here, but most of them should be pretty straight forward. If you have any questions or need any help, feel free to email me and I will be happy to try to help you out where I can. I have documented a few scripts below, but not by any means ALL of them. Most (!) scripts have a header explaining what, why and how etc.. Please browse and play...
A quick note about TTS engines. I use Cepstral's "Allison" voice (swift) that I purchased back in 2009 and it ran well on CentOS-4, and CentOS-5. To my surprise it runs well on Debian-10 too, so she is still employed. If you modify the scripts a little, they can use the free 'Festival' TTS engine to get you by.
One of the things I needed while I was at work was the ability to ping test an internet connection from a remote address. The IRLP node was the ideal choice to help with this. I had to have a way of controlling a script with DTMF and stopping the normal decode process at the same time. I added some code to the top of the custom_decode script to recognise a flag indicating that an interactive session was active, and to dump the received DTMF digits into a file and exit. The running script can then pick up these digits and use them.. Simples? The ping test script uses this sequence to get the required address and number of pings to send. Test result is then returned to the user.
Now a quote from another programmer, (from one of the scripts I adapted, thanks Tony ,VK3JED)
"If you try something and it works, excellent! if it breaks, you get to keep both pieces, and if you manage to fix it after it breaks, please document your experience so others can benefit. it will be appreciated by someone."
Interactive Sessions..
Custom_Decode..
Back in the early days, (!) the PC I was running for the node was a slow old klunker, and I looked at the decode process with all the multiple 'if/then/else/fi' statements and looked for something faster and easier to follow. Enter the 'case' statement. There are still a few 'if's required, but most of the work is done with a couple of 'case' statements that I think are easier to work with, and you can use operators in the tests too. It all starts out with 'case $1 in' , then all the tests with their actions and anything that doesn't match can be caught with a ' * ' as a last choice.
One of the good ones is " 809|8[1-3][0-9]|84[0-5] " ... This option will activate if the user dialled 809 to 845 inclusive (to select a play-on-demand audio programme). The resulting instruction is " $CUSTOM/play_q5 ${1:1:2} & " which is the audio programme 'Q5' and the episode number is ' ${1:1:2} '. That equates to the incoming digits ($1), start at character 1 (zero numbered!) and take 2 characters, so, if the user dialled 824 the command becomes " play_q5 24 " and the trailing " & " indicated play as separate process (backgound), so that the decode process will finish as it should and not hang waiting for the programme to finish. Note that some of the codes have been XXX'd out as they are known only to the node operator, and some appear before the readback (dtmf_ack) so that the codes are not rebroadcast. (like activating the pin control etc)
This is a simple script that repeats the received digits back to the user as voice. It is basically to make sure that the command DTMF that the node heard was what the user sent. When signal strength is getting down into the noisy conditions, the DTMF decoder can get it wrong and this will let the user know they either didn't get all the digits in, or got wiped out by something else. The same thing can happen if the DTMF level is too high and distorted, will be decoded incorrectly. Make sure you add this into custom_decode BELOW any codes you don't want repeated back.. A tad embarrassing to have the control PIN number broadcast back to you for all to hear..
Dtmf_ack..
Some of the functions that can be controlled on the node like shutdown and reboot PC are not meant for everyday users to activate, so I have a 'pin code' system to open these commands only if the pin has been activated firstly. This little script is run in the background AFTER the pin number has been received and is active. It will sit in sleep mode for 2 minutes, and then remove the active pin flag if it has not been used. This flag is stored in $LOCAL (RAM-Disk) so that it will not survive a reboot or power off. An audio file goes to air to indicate the pin has been set, and another if the pin times out.
Kill_pin..
Unlog..
This script removes the last line from the log file. When a sysop enters the PIN code to activate controlled functions, if the lastline script is run, it will cause the line from decoding the PIN to be read back on-air... Not good!! Currently this will only delete 1 line from the log and replace it with its own entry to indicate 'line removed'...
Confirm..
Another simple little script used to play the confirmation tones to signal back to the user that a command has been received. Sort of like a "please wait.." notice. If a service that needs to go and get data from the internet (like play_remote_data) there will be a delay in getting the answer. In the normal operation of the node, there is no indications that a DTMF code received was invalid, just deadly silence, so this is confirmation that something is going to happen. It plays the audio file ~/audio/custom/sound-confirm.wav
As the transmitter is not designed for 100% duty cycle, it needs a cooling fan, and it is controlled by this script. The fan is a 120mm 12v server fan and is connected to the AUX-3 output of the IRLP_V3 card. Fan positive to the 12v PC rail, negative to the AUX output. The script can be configured for either AUX line and the header of the script gives quick instructions on its use. The fan_ctrl script runs in the background and watches the PTT line. When the line has been active for a set time, the fan turns on. It has a cooldown timer to stop the fan again after PTT drops for the set time. This timer is restarted if the PTT goes active again before it expires. The fan_ctrl2 script is basically the same but watches PTT and COS.. (COS 'ya never know when a stuck transmitter will fry the radio..)
Fan_ctrl // Fan_ctrl2..
