Category: Electronics Workbench

Electrical & Electronic gadgets

Raspberry Pi Rotary Encoder: evdev Proof of Concept

After Bill Wittig pointed me in the right direction, writing a Python program to correctly read a rotary encoder knob on a Raspberry Pi is straightforward. At least given some hints revealed by knowing the proper keywords.

First, enhance the knob’s survivability & usability by sticking it on a perfboard scrap:

RPi rotary encoder - improved test fixture — RPi rotary encoder – improved test fixture

Then find the doc in /boot/overlays/README:

Name: rotary-encoder
Info: Overlay for GPIO connected rotary encoder.
Load: dtoverlay=rotary-encoder,
=
Params: pin_a GPIO connected to rotary encoder channel A
(default 4).
pin_b GPIO connected to rotary encoder channel B
(default 17).
relative_axis register a relative axis rather than an
absolute one. Relative axis will only
generate +1/-1 events on the input device,
hence no steps need to be passed.
linux_axis the input subsystem axis to map to this
rotary encoder. Defaults to 0 (ABS_X / REL_X)
rollover Automatic rollover when the rotary value
becomes greater than the specified steps or
smaller than 0. For absolute axis only.
steps-per-period Number of steps (stable states) per period.
The values have the following meaning:
1: Full-period mode (default)
2: Half-period mode
4: Quarter-period mode
steps Number of steps in a full turnaround of the
encoder. Only relevant for absolute axis.
Defaults to 24 which is a typical value for
such devices.
wakeup Boolean, rotary encoder can wake up the
system.
encoding String, the method used to encode steps.
Supported are "gray" (the default and more
common) and "binary".

Add a line to /boot/config.txt to configure the hardware:

dtoverlay=rotary-encoder,pin_a=20,pin_b=21,relative_axis=1,steps-per-period=2

The overlay enables the pullup resistors by default, so the encoder just pulls the pins to common. Swapping the pins reverses the sign of the increments, which may be easier than swapping the connector after you have it all wired up.

The steps-per-period matches the encoder in hand, which has 30 detents per full turn; the default value of 1 step/period resulted in every other detent doing nothing. A relative axis produces increments of +1 and -1, rather than the accumulated value useful for an absolute encoder with hard physical stops.

Reboot that sucker and an event device pops up:

ll /dev/input
total 0
drwxr-xr-x 2 root root 80 Oct 18 07:46 by-path
crw-rw---- 1 root input 13, 64 Oct 18 07:46 event0
crw-rw---- 1 root input 13, 65 Oct 18 07:46 event1
crw-rw---- 1 root input 13, 63 Oct 18 07:46 mice

I’m unable to find the udev rule (or whatever) creating those aliases and, as with all udev trickery, the device’s numeric suffix is not deterministic. The only way you (well, I) can tell which device is the encoder and which is the power-off button is through their aliases:

ll /dev/input/by-path/
total 0
lrwxrwxrwx 1 root root 9 Oct 18 07:46 platform-rotary@14-event -> ../event0
lrwxrwxrwx 1 root root 9 Oct 18 07:46 platform-soc:shutdown_button-event -> ../event1

The X axis of the mice device might report the same values, but calling a rotary encoder a mouse seems fraught with technical debt.

The name uses the hex equivalent of the A channel pin number (20 = 0x14), so swapping the pins in the configuration will change the device name; rewiring the connector may be easier.

Using the alias means you always get the correct device:

# Rotary encoder using evdev
# Add to /boot/config.txt
#  dtoverlay=rotary-encoder,pin_a=20,pin_b=21,relative_axis=1,steps-per-period=2
# Tweak pins and steps to match the encoder

import evdev

d = evdev.InputDevice('/dev/input/by-path/platform-rotary@14-event')
print('Rotary encoder device: {}'.format(d.name))

position = 0

for e in d.read_loop():
    print('Event: {}'.format(e))
    if e.type == evdev.ecodes.EV_REL:
        position += e.value
        print('Position: {}'.format(position))

Which should produce output along these lines:

Rotary encoder device: rotary@14
Event: event at 1603019654.750255, code 00, type 02, val 01
Position: 1
Event: event at 1603019654.750255, code 00, type 00, val 00
Event: event at 1603019654.806492, code 00, type 02, val 01
Position: 2
Event: event at 1603019654.806492, code 00, type 00, val 00
Event: event at 1603019654.949199, code 00, type 02, val 01
Position: 3
Event: event at 1603019654.949199, code 00, type 00, val 00
Event: event at 1603019655.423506, code 00, type 02, val -1
Position: 2
Event: event at 1603019655.423506, code 00, type 00, val 00
Event: event at 1603019655.493140, code 00, type 02, val -1
Position: 1
Event: event at 1603019655.493140, code 00, type 00, val 00
Event: event at 1603019655.624685, code 00, type 02, val -1
Position: 0
Event: event at 1603019655.624685, code 00, type 00, val 00
Event: event at 1603019657.652883, code 00, type 02, val -1
Position: -1
Event: event at 1603019657.652883, code 00, type 00, val 00
Event: event at 1603019657.718956, code 00, type 02, val -1
Position: -2
Event: event at 1603019657.718956, code 00, type 00, val 00
Event: event at 1603019657.880569, code 00, type 02, val -1
Position: -3
Event: event at 1603019657.880569, code 00, type 00, val 00

The type 00 events are synchronization points, which might be more useful with more complex devices.

Because the events happen outside the kernel scheduler’s notice, you (well, I) can now spin the knob as fast as possible and the machinery will generate one increment per transition, so the accumulated position changes smoothly.

Much better!

2020-10-19

Arducam Motorized Focus Camera: Focusing Equation
The values written to the I²C register controlling the Arducam Motorized Focus Camera lens position are strongly nonlinear with distance, so a simple linear increment / decrement isn’t particularly useful. If one had an equation for the focus value given the distance, one could step linearly by distance.

So, we begin.

Set up a lens focus test range amid the benchtop clutter with found objects marking distances:

Arducam Motorized Focus camera – test setup

Fire up the video loopback arrangement to see through the camera:

Arducam Motorized Focus test – focus infinity

The camera defaults to a focus at infinity (or, perhaps, a bit beyond), corresponding to 0 in its I²C DAC (or whatever). The blue-green scenery visible through the window over on the right is as crisp as it’ll get through a 5 MP camera, the HP spectrum analyzer is slightly defocused at 80 cm, and everything closer is fuzzy.

Experimentally, the low byte of the I²C word written to the DAC doesn’t change the focus much at all, so what you see below comes from writing a focus value to the high byte and zero to the low byte.

For example, to write 18 (decimal) to the camera:
```
i2cset -y 0 0x0c 18 0
```
That’s I²C bus 0 (through the RPi camera ribbon cable), camera lens controller address 0x0c (you could use 12 decimal), focus value 18 * 256 + 0 = 0x12 + 0x00 = 4608 decimal.

Which yanks the focus inward to 30 cm, near the end of the ruler:

Arducam Motorized Focus test – focus 30 cm

The window is now blurry, the analyzer becomes better focused, and the screws at the far end of the yellow ruler look good. Obviously, the depth of field spans quite a range at that distance, but iterating a few values at each distance gives a good idea of the center point.

A Bash one-liner steps the focus inward from infinity while you arrange those doodads on the ruler:
```
for i in {0..31} ; do let h=i*2 ; echo "high: " $h ; let rc=1 ; until (( rc < 1 )) ; do i2cset -y 0 0x0c $h 0 ; let rc=$? ; echo "rc: " $rc ; done ; sleep 1 ; done
```
Write 33 to set the focus at 10 cm:

Arducam Motorized Focus test – focus 10 cm

Then write 55 for 5 cm:

Arducam Motorized Focus test – focus 5 cm

The tick marks show the depth of field might be 10 mm.

Although the camera doesn’t have a “thin lens” in the optical sense, for my simple purposes the ideal thin lens equation gives some idea of what’s happening. I think the DAC value moves the lens more-or-less linearly with respect to the sensor, so it should be more-or-less inversely related to the focus distance.

Take a few data points, reciprocate & scale, plot on a doodle pad:

Arducam Motorized Focus RPi Camera – focus equation doodles

Dang, I loves me some good straight-as-a-ruler plotting action!

The hook at the upper right covers the last few millimeters of lens travel where the object distance is comparable to the sensor distance, so I’ll give the curve a pass.

Feed the points into a calculator and curve-fit to get an equation you could publish:
```
DAC MSB = 10.8 + 218 / (distance in cm)
        = 10.8 + 2180 / distance in mm)
```
Given the rather casual test setup, the straight-line section definitely doesn’t support three significant figures for the slope and we could quibble about exactly where the focus origin sits with respect to the camera.

So this seems close enough:
```
DAC MSB = 11 + 2200 / (distance in mm)
```
Anyhow, I can now tweak a “distance” value in a linear-ish manner (perhaps with a knob, but through evdev), run the equation, send the corresponding DAC value to the camera lens controller, and have the focus come out pretty close to where it should be.

Now, to renew my acquaintance with evdev …
2020-10-16

Raspberry Pi Interrupts vs. Rotary Encoder

Thinking about using a rotary encoder to focus a Raspberry Pi lens led to a testbed:

There’s not much to it, because the RPi can enable pullup resistors on its digital inputs, whereupon the encoder switches its code bits to common. The third oscilloscope probe to the rear syncs on a trigger output from my knob driver.

I started with the Encoder library from PyPi, but the setup code doesn’t enable the pullup resistors and the interrupt (well, it’s a callback) handler discards the previous encoder state before using it, so the thing can’t work. I kept the overall structure, gutted the code, and rebuilt it around a state table. The code appears at the bottom, but you won’t need it.

Here’s the problem, all in one image:

Knob Encoder - ABT - fast - overview — Knob Encoder – ABT – fast – overview

The top two traces are the A and B encoder bits. The bottom trace is the trigger output from the interrupt handler, which goes high at the start of the handler and low at the end, with a negative blip in the middle when it detects a “no motion” situation: the encoder output hasn’t changed from the last time it was invoked.

Over on the left, where the knob is turning relatively slowly, the first two edges have an interrupt apiece. A detailed view shows them in action (the bottom half enlarge the non-shaded part of the top half):

Knob Encoder - ABT - fast - first IRQs — Knob Encoder – ABT – fast – first IRQs

Notice that each interrupt occurs about 5 ms after the edge causing it!

When the edges occur less than 5 ms apart, the driver can’t keep up. The next four edges produce only three interrupts:

Knob Encoder - ABT - fast - 4 edges 3 IRQ — Knob Encoder – ABT – fast – 4 edges 3 IRQ

A closer look at the three interrupts shows all of them produced the “no motion” pulse, because they all sampled the same (incorrect) input bits:

Knob Encoder - ABT - fast - 4 edges 3 IRQ - detail — Knob Encoder – ABT – fast – 4 edges 3 IRQ – detail

In fact, no matter how many edges occur, you only get three interrupts:

Knob Encoder - ABT - fast - 9 edges 3 IRQ — Knob Encoder – ABT – fast – 9 edges 3 IRQ

The groups of interrupts never occur less than 5 ms apart, no matter how many edges they’ve missed. Casual searching suggests the Linux Completely Fair Scheduler has a minimum timeslice / thread runtime around 5 ms, so the encoder may be running at the fastest possible response for a non-real-time Raspberry Pi kernel, at least with a Python handler.

If. I. Turn. The. Knob. Slowly. Then. It. Works. Fine. But. That. Is. Not. Practical. For. My. Purposes.

Nor anybody else’s purposes, really, which leads me to think very few people have ever tried lashing a rotary encoder to a Raspberry Pi.

So, OK, I’ll go with Nearer and Farther focusing buttons.

The same casual searching suggested tweaking the Python thread’s priority / niceness could lock it to a different CPU core and, obviously, writing the knob handler in C / C++ / any other language would improve the situation, but IMO the result doesn’t justify the effort.

It’s worth noting that writing “portable code” involves more than just getting it to run on a different system with different hardware. Rotary encoder handlers are trivial on an Arduino or, as in this case, even an ARM-based Teensy, but “the same logic” doesn’t deliver the same results on an RPi.

My attempt at a Python encoder driver + simple test program as a GitHub Gist:

	# Rotary encoder test driver
	# Ed Nisley – KE4ZNU
	# Adapted from https://github.com/mivallion/Encoder
	# State table from https://github.com/PaulStoffregen/Encoder

	import RPi.GPIO as GPIO

	class Encoder(object):
	def __init__(self, A, B, T=None, Delay=None):

	GPIO.setmode(GPIO.BCM)

	self.T = T
	if T is not None:
	GPIO.setup(T, GPIO.OUT)
	GPIO.output(T,0)

	GPIO.setup(A, GPIO.IN, pull_up_down=GPIO.PUD_UP)
	GPIO.setup(B, GPIO.IN, pull_up_down=GPIO.PUD_UP)

	self.delay = Delay
	self.A = A
	self.B = B
	self.pos = 0
	self.state = (GPIO.input(B) << 1) \| GPIO.input(A)
	self.edges = (0,1,-1,2,-1,0,-2,1,1,-2,0,-1,2,-1,1,0)

	if self.delay is not None:
	GPIO.add_event_detect(A, GPIO.BOTH, callback=self.__update,
	bouncetime=self.delay)
	GPIO.add_event_detect(B, GPIO.BOTH, callback=self.__update,
	bouncetime=self.delay)
	else:
	GPIO.add_event_detect(A, GPIO.BOTH, callback=self.__update)
	GPIO.add_event_detect(B, GPIO.BOTH, callback=self.__update)

	def __update(self, channel):
	if self.T is not None:
	GPIO.output(self.T,1) # flag entry

	state = (self.state & 0b0011) \
	\| (GPIO.input(self.B) << 3) \
	\| (GPIO.input(self.A) << 2)

	gflag = '' if self.edges[state] else ' – glitch'
	if (self.T is not None) and not self.edges[state]: # flag no-motion glitch
	GPIO.output(self.T,0)
	GPIO.output(self.T,1)

	self.pos += self.edges[state]

	self.state = state >> 2

	# print(' {} – state: {:04b} pos: {}{}'.format(channel,state,self.pos,gflag))

	if self.T is not None:
	GPIO.output(self.T,0) # flag exit

	def read(self):
	return self.pos

	def read_reset(self):
	rv = self.pos
	self.pos = 0
	return rv

	def write(self,pos):
	self.pos = pos

	if __name__ == "__main__":
	import encoder
	import time
	from gpiozero import Button

	btn = Button(26)
	enc = encoder.Encoder(20, 21,T=16)

	prev = enc.read()

	while not btn.is_held :
	now = enc.read()
	if now != prev:
	print('{:+4d}'.format(now))
	prev = now

view raw encoder.py hosted with ❤ by GitHub

2020-10-14

RPi HQ Camera: 4.8 mm Computar Video Lens

The Big Box o’ Optics disgorged an ancient new-in-box Computar 4.8 mm lens, originally intended for a TV camera, with a C mount perfectly suited for the Raspberry Pi HQ camera:

RPi HQ Camera – Computar 4.8mm – front view

Because it’s a video lens, it includes an aperture driver expecting a video signal from the camera through a standard connector:

Computar 4.8 mm lens – camera plug

The datasheet tucked into the box (!) says it expects 8 to 16 V DC on the red wire (with black common) and video on white:

Computar Auto Iris TV Lens Manual

Fortunately, applying 5 V to red and leaving white unconnected opens the aperture all the way. Presumably, the circuitry thinks it’s looking at a really dark scene and isn’t fussy about the missing sync pulses.

Rather than attempt to find / harvest a matching camera connector, the cord now terminates in a JST plug, with the matching socket hot-melt glued to the Raspberry Pi case:

RPi HQ Camera – 4.8 mm Computar lens – JST power

The Pi has +5 V and ground on the rightmost end of its connector, so the Computar lens will be jammed fully open.

I gave it something to look at:

RPi HQ Camera – Computar 4.8mm – overview

With the orange back plate about 150 mm from the RPi, the 4.8 mm lens delivers this scene:

RPi HQ Camera – 4.8 mm Computar lens – 150mm near view

The focus is on the shutdown / startup button just to the right of the heatsink, so the depth of field is maybe 25 mm front-to-back.

For comparison, the official 16 mm lens stopped down to f/8 has a tighter view with good depth of field:

RPi HQ Camera – 16 mm lens – 150mm near view

It’d be nice to have a variable aperture, but it’s probably not worth the effort.

2020-10-13
Discrete LM3909: Green LED at 1.15 V

The green-LED discrete LM3909 is still flashing, even with its AA NiMH cells burned down to 1.15 V:

LM3909 green LED – 1.15 V NiMH

If the truth be known, one of the cells is now reverse-charged to 200 mV, so that’s a bit beyond as low as it can go.

The flash period has stretched to 8.7 s:

LM3909 green LED – 1.17 V – 8.7s period

The circuit boosts the battery by 800 mV to put 1.94 V across the green LED at the start of each flash:

LM3909 green LED – 1.15 V – V LED

Admittedly, the LED isn’t particularly bright at 2.8 mA:

LM3909 green LED – 1.15 V – LED current

But it’s still flashing!

Swapping the cells into the LM3909 with a blue LED doesn’t produce any blinking, which is about what the earlier tests showed.

2020-10-12
Arducam Motorized Focus Camera Control
Despite the company name, the Arducam 5 MP Motorized Focus camera plugs into a Raspberry Pi’s camera connector and lives on a PCB the same size as ordinary RPi cameras:

Arducam Motorized Focus RPi Camera – test overview

That’s a focus test setup to get some idea of how the control values match up against actual distances.

It powers up focused at infinity (or maybe a bit beyond):

Arducam Motorized Focus RPi Camera – default focus

In practice, it’s a usable, if a bit soft, at any distance beyond a couple of meters.

The closest focus is around 40 mm, depending on where you set the ruler’s zero point:

Arducam Motorized Focus RPi Camera – near focus

That’s the back side of the RPi V1 camera PCB most recently seen atop the mystery microscope objective illuminator.

Pondering the sample code shows the camera focus setting involves writing two bytes to an I²C address through the video controller’s I²C bus. Enable that bus with a line in /boot/config.txt:
dtparam=i2c_vc=on
If you’re planning to capture 1280×720 or larger still images, reserve enough memory in the GPU:
gpu_mem=512
I don’t know how to determine the correct value.

And, if user pi isn’t in group i2c, make it so, then reboot.

The camera must be running before you can focus it, so run raspivid and watch the picture. I think you must do that in order to focus a (higher-res) still picture, perhaps starting a video preroll (not that kind) in a different thread while you fire off a (predetermined?) focus value, allow time for the lens to settle, then acquire a still picture with the video still running.

The focus value is number between 0 and 1023, in two bytes divided, written in big-endian order to address 0x0c on bus 0:
i2cset -y 0 0x0c 0x3f 0xff
You can, of course, use decimal numbers:
i2cset -y 0 0x0c 63 255
I think hex values are easier to tweak by hand.

Some tinkering gives this rough correlation:

Focus value (hex) Focus distance (mm)
3FFF 45 (-ish)
3000 55
2000 95
1000 530
0800 850
Arducam Motorized Focus Camera – numeric value vs mm

Beyond a meter, the somewhat gritty camera resolution gets in the way of precise focusing, particularly in low indoor lighting.

A successful write produces a return code of 0. Sometimes the write will inexplicably fail with an Error: Write failed message, a return code of 1, and no focus change, so it’s Good Practice to retry until it works.

This obviously calls for a knob and a persistent value!
2020-10-06
Tour Easy: PTT Switch Cleaning

The switch I installed on Mary’s bike a year ago was intended for indoor use only and, without any trace of weather sealing, recently became intermittent. No surprise, as it’s happened before, but, by regarding my vast assortment of little switches as consumables, we get a low-profile / tactile / E-Z push PTT button without forming a deep emotional attachment.

Anyhow, you can see the unsealed square perimeter of the switch actuator:

Tour Easy – PTT button

The light-gray button sits on a post molded into the actuator. Pry the actuator out and the switch dome shows crud worn off the cross-shaped plunger:

Tour Easy – PTT button – dome plate

The underside of the dome has a weird golden discoloration that surely wasn’t original:

Tour Easy – PTT button – dome plate discoloration

I have no idea how a liquid (?) could have gotten in there and done that without leaving other traces along the way. The contact bump on the discolored leg had some crud built up around it which responded well to a small screwdriver.

Contrary to what the symmetrical four-legged dome might suggest, only one leg rests on a contact in a corner:

Tour Easy – PTT button – contacts

So, yes, a bit of dirt / corrosion / mystery juice in a single spot could render the whole thing intermittent.

I removed the obvious crud from the obvious spots, wiped everything down with some Caig DeoxIT, reassembled in reverse order, and it seems to be all good again. Of course, these things only fail on the road, so it’ll take a few rides to verify the fix.

2020-10-02