Rotary encoder project

j-maathuis · November 22, 2015, 2:19am

After a long conversation in the topic “ How to read ans set GPIO values in GL-AR150?” user “frietpan” came up with the idea to use a rotary encoder on the GL-AR150 mini router.

Frietpan has the eletrical knowledge and I (Jeroen) have a little scripting knowledge.
We want to explore the possibility’s of the rotary encoder, but first we have to make the rotary encoder to work.

Frietpan is using the GLi OpenWRT version 2.13 and I am using 2.12.

We do use use GPIO 14 for button press (SW on rotary encoder), GPIO16 for pulse data (CLK) and GPIO 17 also for pulse data (DT).

So far, I do know how to create a GPIO entrance to read values with help of this article: GPIO [Old OpenWrt Wiki] (see below “Software”).
GPIO14 (button) stays 0 and both GPIO16 en GPIO17 stays 1. So far, nothing to build a script around.

Also no new buttons available at the /etc/rc.buttons directory

Also the “Preliminary steps” at Attach functions to a push button [Old OpenWrt Wiki] does not provide any information from the rotary encoder.

At this moment we do have the focus on the package “kmod-input-gpio-encoder” (mentioned at a table at GPIO [Old OpenWrt Wiki]). We will investigate what possiblity’s this package will provide.

To be continued…
Any ideas, suggestions, etc. are welcome!

frietpan · November 22, 2015, 6:05am

Hey Jeroen,

I also noticed another package in the repo named kmod-rotary-gpio-custom and added it to the OpenWrt GPIO wiki page, however im unable to install it due to dependency errors:
<pre class=“error”>Collected errors:

satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-rotary-gpio-custom:
kernel (= 3.10.49-1-230c2cfcebfbfe3eba558e2db2ace614) * kernel (= 3.10.49-1-230c2cfcebfbfe3eba558e2db2ace614) *
opkg_install_cmd: Cannot install package kmod-rotary-gpio-custom.

and:

opkg_install_cmd: Cannot install package kmod-input-gpio-encoder.

I’m now trying to figure out what dependency it needs to be happy…

I can’t find how to ask opkg what depends on, is it safe to do:

opkg install kmod-input-gpio-encoder --force-depends

or would that cause more trouble then we are asking for?

EDIT:

i found this in the wiki: FAQ after Installation of OpenWrt [Old OpenWrt Wiki]
but don’t understand what to do about it. Does this mean that the package in the repo comes from trunk? and is not yet an official package of BB?

I’m also using version 2.12 (Barrier Breaker) so that i’m having the same stuff as Jeroen.

j-maathuis · November 22, 2015, 7:29am

Tried to install kmod-input-gpio-encoder without luck:

root@GL-iNet:~# opkg install kmod-input-gpio-encoder
Installing kmod-input-gpio-encoder (3.10.49-1) to root...
Downloading http://www.gl-inet.com/openwrt/ar150/2.12/packages/base/kmod-input-gpio-encoder_3.10.49-1_ar71xx.ipk.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-input-gpio-encoder:
*      kernel (= 3.10.49-1-230c2cfcebfbfe3eba558e2db2ace614) *
* opkg_install_cmd: Cannot install package kmod-input-gpio-encoder.
root@GL-iNet:~# opkg install kmod-input-gpio-encoder --force-depends
Installing kmod-input-gpio-encoder (3.10.49-1) to root...
Downloading http://www.gl-inet.com/openwrt/ar150/2.12/packages/base/kmod-input-gpio-encoder_3.10.49-1_ar71xx.ipk.
Configuring kmod-input-gpio-encoder.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-input-gpio-encoder:
*      kernel (= 3.10.49-1-230c2cfcebfbfe3eba558e2db2ace614) *
root@GL-iNet:~#

So the --force-depends parameter neither makes the situation worse nor its solves the issue.

EDIT:
Eventually it the info parameter tells me it was user installed right now:

root@GL-iNet:~# opkg info kmod-input-gpio-encoder
Package: kmod-input-gpio-encoder
Version: 3.10.49-1
Depends: kernel (= 3.10.49-1-230c2cfcebfbfe3eba558e2db2ace614), kmod-input-core
Status: install hold,user installed
Section: kernel
Architecture: ar71xx
MD5Sum: f953f3961c32a0054a4d711da35ba36a
Size: 2863
Filename: kmod-input-gpio-encoder_3.10.49-1_ar71xx.ipk
Source: package/kernel/linux
Description: GPIO rotay encoder
Installed-Time: 1448148380

frietpan · November 22, 2015, 3:11pm

It’s not complete clear to me what is causing this. It looks like the kernel and the packages are not from the same version, yet it all comes from the the 2.12 repository.

I hope that someone from GLiNet can shine a light on this. I’m very reluctant when it comes to force a package, i don’t know enough about software and stuff like this usually bites me when i don’t expect it.

I’m currently running 2.12 So that i’m in sync with Jeroen, though i wonder if this error also happens in 2.13 (CC based) But i first wait on some advice, maybe there is a simple solution.

guest · November 23, 2015, 6:31am

So what will this Rotary Encoder project do?

alzhao · November 23, 2015, 5:01pm

@frietpan, pls update the firmware. V2.12 seems to have a problem with kernel modules. This is modifed in V2.13 and later versions.

frietpan · November 24, 2015, 5:30am

@ guest:

The Rotary encoder can be used for many things. In domotica you could use it to dim the lights, control the temperature, etc.

But since it is NOT a potentiometer it can do much more. For instance tit can be used as a switch with many positions

It’s exacltly the same as the rotary dial on a 3D printer (Like Ultimaker, or RAMPS controller)

For RGB lights someone may want to use it to set the colour values. and brightness
I would like to send volume level to my media player.
It can also be used as a jog-dial for video.
OR to pan tilt zoom a camera
Aim a satellite dish or yagi antenna? Or a telescope. (servo’s)

Even if it is half way around the world.

And i’m sure that there are many more things possible, say you have a tor hidden-service on one router and that presents the value of the rotary. Then another router can connect to that service over the tor network. to read the value and control a device that is connected to that router.

So at this pointy it’s about having an option to control ‘something’, and from there we can explore what we are going to control with it.

I think a good start is to start with RGB LEDS, set the value for RED, then push the button, then set the value for Green and push the button again and set the Blue value. Then we are already controlling 3 values with one rotary in a intuitive way.

@alzhao:

Hmm, ok i’ll move to 2.13 then, in a way i would have liked to use the same environment as Jeroen, since my software skills are very limited. What caused the error? I did not expect dependency issues when installing a single package. I have done a few Google searches and it looked like the BB Kernel that GLi uses is different (newer) then the OpenWrt BB Kernel. So then it is no longer an actual Barrier Breaker? Is there a reason for this? Isn’t it safer to just stick with a known-to-be-stable repository?

I’m still learning and maybe a bit cautious around error messages?

guest · November 24, 2015, 6:09am

@ frietpan,

Thanks for the info. I’ve my house completely covered with X-10 and Z-wave, and all accessible by internet

So for my domotica system I’ve no real need for it, but it does sound like a nice project you and Jeroen are working on!
Keep up the good work!

frietpan · November 24, 2015, 6:43am

Will do, the borders between Domotica and IoT are fading. And it’s a good way to learn how to blur the lines even more.

frietpan · November 25, 2015, 6:57am

Ok, so i have upgraded to 2.13

Installed kmod-input-gpio-encoder and kmod-rotary-gpio-custom, both installed without issues.
Then i had a look at GPIO [Old OpenWrt Wiki]

I first wanted to test the push button functionality the sw output of the encoder is connected to GPIO 14 so:

echo “14” > /sys/class/gpio/export

that created /sys/class/gpio/gpio14

echo “in” > /sys/class/gpio/gpio14/direction

that set gpio14 as input, now i should be able to read the value status with

cat /sys/class/gpio/gpio14/value

And that gives me a 0 as answer. However when i push the button and try again the value still is 0. So i will need to do some measurements when i get home.

I assume that 0 means LOW and that the SW then needs to give a HIGH signal to the GPIO. So we may need to add a 10k pull-up resistor to SW. In Arduino it’s possible to set pull-ups in software, is that also an option in the AR9331 SoC?

For the installed encoder software i’m missing a few instructions how that software actually works.

j-maathuis · November 25, 2015, 7:54am

Did you try reading the GPIO14 value while keep pushing the button? When releasing the button the value will indeed get back to 0 (zero).

frietpan · November 25, 2015, 8:16am

Yes i did try, but the value stayed 0 in my case. Is there perhaps a way to see the value as a stream? So that you can monitor the value until you press ctrl-C.

alzhao · November 25, 2015, 9:19am

@frietpan, our firmware is using CC1505 now. So it is newer than BB1407.

To see the value as a stream, just write a script and read in a loop. Does this work?

rich · November 26, 2015, 6:44am

``` satisfy_dependencies_for: Cannot satisfy the following dependencies ```

I had a similar problem to this with the original 2.12 firmware, re-flashing it with 2.12 available from the gl-inet website solved my issues. I guess the early units had a slightly different version of openwrt and the package repo is based on a later version of 2.12

frietpan · November 26, 2015, 3:51pm

Tonight I added a 10K pull-up, turns out that the encoders have a mount spot for the pull-up resistor but are not mounted by default… (most likely because most people use them with Arduino’s and there it’s possible to set pull-ups internally)

SO, we need to mount on ourselves.

Brown Black Orange Gold is 10K

This now works, but it seems to have an issue, now if i boot the device it seems not to come up at all now that GPIO is high at boot time. So I guess this could be something in U-Boot OR that the SoC itself has other plans with GPIO 14 at boot time?

Or maybe even another reason? I hope the GLiNet Devs can shine their light on this.

I had not taken this in consideration when I started this, So now I wonder if the other GPIO’s may experience similar issues.?
Now this issue is easy to work around by keeping the button pressed at boot time. It’s a bit annoying but it works. So. we have to figure this out and see if this is easy to overcome, or if we better use pin 1 instead. (that’s the fastest option, but I’ll test pin1 tomorrow to see if this doesn’t have the same issue)

Holiday season is full of surprises…

So now I can again try:
echo “14” > /sys/class/gpio/export
ash: write error: Invalid argument
ehm… write error? Does this no longer work in 2.13?? I’m doing the same as before or not?

EDIT
echo 14 > /sys/class/gpio/export
(without the quotes it works)

echo in > /sys/class/gpio/gpio14/direction

and testing…

cat /sys/class/gpio/gpio14/value
1
cat /sys/class/gpio/gpio14/value
0
and it works…

alzhao · November 26, 2015, 4:00pm

I am not sure if I understand clearly.

GPIO14 is at low level every time openwrt boot. So you want it at high level, right?

To the the GPIO14 at high, we can do it in uboot, linux kernel or linux boot script.

frietpan · November 26, 2015, 4:38pm

ok, if that solves it thats great, and then the resistor is obsolete or not??? (Then Jeroen does not have to solder anything)

My main concern is why the high state of pin14 doesn’t allow the device to fully boot.

What of the 3 options is the preferred one?

j-maathuis · November 26, 2015, 10:22pm

I’m preparing to upgrade to 2.13 at my side right now, so we again have the same environment frietpan.

I currently only have 15K and 22K resistors. I do not have enough knowledge which side has to be soldered on which spot on the print. Also the resistors are not the correct ones since we need a 10K restistor as I understand from frietpan.

Are the GPIO solder points somehow connected to the 3 LED-s on the board? On the backside there are some text with “LED 1” till “LED 5”. Since there are only 3 LED’s maybe SW could be connected to GPIO1? Will the missing LED be the one for power? OpenWRT does recognize more LED’s and buttons then physical available on the board.

Do I understand correctly that a GPIO at high / low does not affect the GPIO value? Does it only affect the behaviour in which case a GPIO value should be set to 1?

frietpan · November 27, 2015, 5:39am

15 k should be ok, a resistor has no polarity so it does not matter in what direction you mount it, just connect one lead to the SW pin and the other to the same pin as did in the picture, thats a +. The picture shows the easiest way to place the resistor so that it can be mounted flat and without consuming much space.

Still i think the option that Alzhao described is a nicer solution and it would solve the bootup issue. But it’s not yet clear to me how to do that.

For the encoder itself i found the source code of the rotary-gpio. Though i wonder if that’s the most recent version…

http://projects.qi-hardware.com/index.php/p/openwrt-xburst/source/tree/b016e98/package/rotary-gpio-custom/src/rotary-gpio-custom.c

looks like there are 4 buses and we need too assign GPIO16 and GPIO17 to one of those busses. Though must we edit a config file for this? Or create something new?

Hmm good point about the LED’s What GPIO’s are configured for the missing LED’s? Where did you see this?

GPIO can be configured as ‘in’ or as ‘out’ for a switch the GPIO has to be set as input. Then when it detects that the GPIO is connected to GND then the value is 0 and when it detects the 3Volt then value is set to 1

And with the GPIO set as input it then should not be possible to change the value as a LED output (unless you first change the port function into ‘out’)

j-maathuis · November 27, 2015, 8:01am

On the backside of the board you can see the texts “LED6”, “LED5”, “LED3”, “LED1” and “GND” right above the GPIO solder points.
I’m not sure whether it has something to do with the solder points or not.

Also it is suprisingly how little information looks like to be available about the modules. They only are mentioned a few times but never how you can make use of them…