Yet another GPIO thread

App_rpt-users
1

I’ve looked at the various threads regarding using GPIO but none really seem to address my situation.
Conditions:
ASL Beta 2.0 running on a Pi3+
Repeater Builder RIM-Lite interface using usbradio.so driver

The RIM-Lite uses the CM119A and it uses GPIO3 as PTT controI and I thought it would be nice to be able to control the PTT line (for external applications) via GPIO manipulation.

So I tested things…

In usbradio.conf, I placed:

gpio3 = out0

and in rpt.conf, I placed:

962 = cop,62,GPIO3=501 (supposed to set GPIO3 to a logic 1 for 500 ms)

Restarted asterisk and from the bash CL:

root@AH6LE-HUB:~# asterisk -rx ‘rpt fun 1100 *962’

Nothing - PTT didn’t go active. So I went to the Asterisk CLI, hoping to see some debug info:

AH6LE-HUB*CLI> rpt fun 1100 *962
AH6LE-HUB*CLI>

Thoughts (other than I’m always pushing the envelope!)

2

Did you set the verbose level with
asterisk -rvvv sets verbose level 3
or at the *CLI
core set verbose # where # sets verbose level, try 4,5 or more.

3

No difference

Connected to Asterisk GIT d1e9a8b currently running on AH6LE-HUB (pid = 11329)
Verbosity is at least 3

AH6LE-HUB*CLI> core set verbose 9
Verbosity was 3 and is now 9
AH6LE-HUB*CLI> rpt fun 1100 *962
AH6LE-HUB*CLI>
4

I was hoping there might be some thoughts about this. Surely I’m not the only one trying this?

5

Did you try lowercase as the docs show? Where did you read that a pin could be pulsed? Also, maybe try asking the repeater-builder folks.

6

Fair point about the case (I will try lower) but the sample in the rpt.conf file itself references uppercase:

961 = cop,61,GPIO4=501 ; Send Message to USB to control GPIO pins (cop,61,GPIO1=0[,GPIO4=1]…)
962 = cop,62,GPIO3=501 ; Send Message to USB to control GPIO pins, quietly (cop,62,GPIO1=0[,GPIO4=1]…)

As for the pulse, that’s straight from the Wiki:

https://wiki.allstarlink.org/wiki/Manipulating_GPIO

Use 0 or 1 to set the specified output to 0 or 1, or a number greater then 1 to specify how
many milliseconds minus 1 to invert its current state. For example, to pulse the bit for 500ms you
would use the value ‘501’(currently, specified time only significant in increments of 50ms). The
use of specifying a value of N+1 to indicate N milliseconds was done so that if, in the future,
the granulatity increases down to the millisecond level, a value of 1 ms could be specified.

7

Update - lower case doesn’t work either

8

Ken,
I thought about this a little more. I THINK there is a bug in the GPIO commands. There is a pull request to fix how the command is processed. See https://github.com/AllStarLink/ASL-Asterisk/pull/22/commits/c0e5274914af6796914fae80e8828801b224e529 See also https://groups.io/g/Allstar/message/305

Steve N4IRS

9

Thanks Steve. As that is a recent change, has the compilation been made available yet?

10

It’s still a pull request, so the change has not been approved, applied or deployed. All that is up to the development team.

11

Ok thanks. As I’m a member of the Allstar list on groups.io, I read that thread you referenced and the last post in that thread indicates that the GPIO does work from the CLI

https://groups.io/g/Allstar/message/302

Still, I am unable to make it work using that scheme as well. I have only tried GPIO3 (the one used in the RB Rim Lite to control PTT) so perhaps there’s some sort of lockout in the code. I need to poke around some more I suppose

12

Ken,
The way I read the thread, the GPIO processing wont work without the change to the code. Maybe ask there?

13

Will do but the way I read it, GPIO processing doesn’t work with the Event Manager event RPT_RXKEYED but does work via the CLI

14

Have you tried to just switch the state without time delay (ie 0 or 1)
BTW…
501ms is a 1/2 sec pulse. Have you metered it ?

15

PTT of the RIM Lite is connected to Port on a controller, monitored by LEDs. I’d have seen it if it worked

16

And still no go if I take out the delay and just GPIO3=1

17

I would have to guess that since you say you can run this from a command line and not from a dtmf commanded function, that you have a conflict in your command set…

Do you have anything also starting with dtmf 9 or 96

18

You misread my post(s). I can NOT make it work from the command line either

19

I do not use GPIO on USB so I can only speak from theory, not experience.
Since you seem to behaving such a issue for so long, and you are using a Pi,
why not just toggle a Pi GPIO pin. There are 8 of them for output.

20

@AH6LE The PR I submitted gets the parameters into the event processing where previously they were not parsed. Given the pulse feature is not working from the cli, then it’s not related to my PR. However I’d suspect that you’d need my update if you want the pulse settings to be event driven and the argument passed ultimately into usbradio.c. I’ve been looking at usbradio.c this morning. I suspect it’s a feature that hasn’t been used much and got broken along the way. Can you test with simpleusb and see if there is a difference? Maybe that’ll give a clue where we can address the issue.