I spotted this little gadget chugging steadily across a table in the living room:
Chestnut parasite larva – detail
Nearby, two of its friends / siblings / clones remained near their landing craft:
Chestnut parasite larvae – overview
They’re about 5 mm long and, although there are no larva-size holes visible in the chestnuts tucked inside the burr, that’s definitely where they started their journey.
A few hours later, the rest of the crew bailed out:
Chestnut parasite larvae – irruption
The exit hole must be on a nut under the curve of the husk, but they’re sufficiently squishy to wriggle their way out. The little brown dot over on the left belongs to the top larva of a pair queued in the exit corridor:
Chestnut parasite larvae – exiting husk
I lost count at 18. There’s surely more where they came from, so I replaced the plate with a bowl to reduce the quantum tunneling probability.
In an ideal world, they’d grow up to be chestnut weevils, but I put them out near the suet feeder and, a few hours later, my offering was accepted.
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:
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.
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.
Much to our utter astonishment, this appeared on the driveway:
Chestnut burr
We’ve since found half a dozen chestnut burrs in the yard, which means at least two trees (it takes two to cross-fertilize) are growing in the immediate area.
We originally thought they were American Chestnuts, but Mary (being a Master Gardener) found enough references including comparative burr pictures to convince us they’re Chinese Chestnuts.
We’ve seen squirrels carrying the burrs in their mouths from the trees to wherever they bury their food supply, as shown by this gnawed spot on the other side of the burr:
Chestnut burr – gnawed section
I regard this as conclusive proof that squirrels either have no sense of pain or no lips, because I can’t imagine carrying that thing in my hand, let alone gnawing through it to extract the nuts inside.
Each burr contains three nuts, although this empty husk shows some nuts can fail to fill out:
Chestnut burr – interior with failed nut
We don’t know where the trees are, but the squirrels seem to carry the burrs across our yard from north to south, so they can’t be too far from us or each other.
Despite our conclusion, it’s faintly possible they’re American Chestnuts, in which case they’re definitely survivors!
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
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
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
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:
In fact, no matter how many edges occur, you only get three interrupts:
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.
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.
The same helicopter thumped over our house, about two miles from the runway as the chopper flies, while I was getting ready for the ride, and it was hovering as I reached the airport. I think the pilot was practicing, because the chopper made very precise movements across the airport, translated front / back / left / right, and hovered motionless for minutes at a time despite wind gusts.
