Still working on my new repeater build here and trying to figure out how to use the the GPIO pins as an input to trigger an alarm. I’ve found a lot of documentation floating around here and in other places on using the GPIO pins as outputs and have already done that in a remote base setup I have with a Motorola CDM750. But, I have not been able to find much in the way of documentation on their use as inputs to trigger an alarm.
My repeater is a Motorola MTR2000 which has digital outputs to indicate things like AC power failure and PA failure, which I’d like to tie to my GPIO pins as inputs to trigger a script file which would email me and alert me of the problem.
Can any one share some directions, or even better some examples, of how to do this in my rpt.conf file?
I think it all depends on how you attack this. This link ( https://hamvoip.org/howto/GPIO_how-to.pdf ) has some information for you. It will also depend on whether your working with active highs / lows, or if you want to drive relays for the input to the pi. Also, whether you use bash scripting or maybe python to do programming. A good goggle search and YouTube videos should be instructive.
Can this be used as PTT for the radio cuz im having issue in my FOB always on high and ptt the radio right away this my last effort before buying dmk uri.
I’ve seen the document you shared. Unfortunately, this does not really apply to my situation as I am using the GPIO inputs/outputs directly off of the CM chip via the RepeaterBuilder USB-RIM interface. What I have done is taken all of the signals to/from the MTR2000 via it’s “System Connector” on the backplane and are carrying them to the USB-RIM interface via a single 25-Pin connector. I know how to identify the GPIO pins as inputs vs outputs in the usbradio.conf file. It’s the programing of the alarm actions in rpt.conf that I am confused by.
Hi Tom,
I think I now know what you are trying to do. I have seen something like this when I first started with using the AllStarLink version of the software, but have since gone over to the HamVIOP version due to some audio hiccups in my node. I thought at the time that it was interesting that the CM119 chip could do this.
I tend to wire my IO directly to the PI and then write scripts to act upon the IO. I’ve written code to activate a relay to turn a fan on to cool the heat sink on the Alinco DR-135 and script code to monitor the heatsink temp using 1-wire temp sensor which then sends text to my phone to alert when over temp every 5 minutes and then notifies me if the temp returns to normal. Haven’t done anything yet using High/low inputs.
I did find this link ( https://github.com/AllStarLink/Asterisk/blob/master/allstar/configs/usbradio/rpt.conf ) which has some cryptic description of how to set up an alarm stanza. Down towards the bottom around line 549. I’ve always found that the documentation for any of the operations is lacking or at best confusing. But I think that you need to set up an Alarm Stanza and then maybe point the func-lo or func-hi to a script to do what you want like say something over the air or send you a text.
I’ve seen the document you shared. Unfortunately, this does not really apply to my situation as I am using the GPIO inputs/outputs directly off of the CM chip via the RepeaterBuilder USB-RIM interface. What I have done is taken all of the signals to/from the MTR2000 via it’s “System Connector” on the backplane and are carrying them to the USB-RIM interface via a single 25-Pin connector. I know how to identify the GPIO pins as inputs vs outputs in the usbradio.conf file. It’s the programing of the alarm actions in rpt.conf that I am confused by.
I think it all depends on how you attack this. This link ( https://hamvoip.org/howto/GPIO_how-to.pdf ) has some information for you. It will also depend on whether your working with active highs / lows, or if you want to drive relays for the input to the pi. Also, whether you use bash scripting or …
Yep Steve, this is exactly the segment of the rpt.conf file I was referring to and am trying to figure out from it’s cryptic nature. Thanks for the input.
| 
|