Ed Nisley's Blog: Shop notes, electronics, firmware, machinery, 3D printing, laser cuttery, and curiosities. Contents: 100% human thinking, 0% AI slop.
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.
Despite the company name 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:
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!
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.
As far as I can tell, Raspberry Pi cases are a solved problem, so 3D printing an intricate widget to stick a Pi on the back of an HQ camera seems unnecessary unless you really, really like solid modeling, which, admittedly, can be a thing. All you really need is a simple adapter between the camera PCB and the case of your choice:
The plate has recesses to put the screw heads below the surface. I used nylon screws, but it doesn’t really matter.
The case has all the right openings, slots in the bottom for a pair of screws, and costs six bucks. A pair of M3 brass inserts epoxied into the plate capture the screws:
RPi HQ Camera – case adapter plate – screws
Thick washers punched from an old credit card go under the screws to compensate for the case’s silicone bump feet. I suppose Doing the Right Thing would involve 3D printed spacers matching the cross-shaped case cutouts.
Not everyone agrees with my choice of retina-burn orange PETG:
RPi HQ Camera – 16 mm lens – case adapter plate
Yes, that’s a C-mount TV lens lurking in the background, about which more later.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As part of spiffing my video presence for SquidWrench Zoom meetings, I put a knockoff RPi V1 camera into an Az-El mount, stuck it to a Raspberry Pi, installed the latest OS Formerly Known as Raspbian, did a little setup, and perched it on the I-beam over the workbench:
Raspberry Pi – workbench camera setup
The toothbrush head has a convenient pair of neodymium magnets affixing the RPi’s power cable to the beam, thereby preventing the whole lashup from falling off. The Pi, being an old Model B V 1.1, lacks onboard WiFi and requires a USB WiFi dongle. The white button at the lower right of the heatsink properly shuts the OS down and starts it up again.
Zoom can show video only from video devices / cameras attached to the laptop, so the trick is to make video from the RPi look like it’s coming from a local laptop device.
Start by exporting video from the Raspberry Pi:
raspivid --nopreview -t 0 -rot 180 -awb sun --sharpness -50 --flicker 60hz -w 1920 -h 1080 -ae 48 -a 1032 -a 'RPi Cam1 %Y-%m-%d %X' -b 1000000 -l -o tcp://0.0.0.0:5000
The -rot 180 -awb sun --sharpness -50 --flicker 60hz parameters make the picture look better. The bottom of the video image There is no way to predict which side of the video will be on the same side as the cable, if that’s any help figuring out which end is up, and the 6500 K LED tubes apparently fill the shop with “sun”.
The -l parameter causes raspivid to wait until it gets an incoming tcp connection on port 5000 from any other IP address, whereupon it begins capturing video and sending it out.
That’s the edge of the workbench over there on the left, looking distinctly like a cliff.
The RPi will happily stream video all day long to ffmpeg while you start / stop the display program pulling the bits from the video device. However, killing ffmpeg also kills raspivid, requiring a manual restart of both programs. This isn’t a dealbreaker for my simple needs, but it makes unattended streaming from, say, a yard camera somewhat tricky.
There appear to be an infinite number of variations on this theme, not all of which work, and some of which rest upon an unsteady ziggurat of sketchy / unmaintained software.
Addendum: If you have a couple of RPi cameras, it’s handy to run the matching ssh and ffmpeg sessions in screen / tmux / whatever terminal multiplexer you prefer. I find it easier to flip through those sessions with Ctrl-A N, rather than manage half a dozen tabs in a single terminal window. Your mileage may differ.
Replacing the battery in an old Craftsman (!) multimeter brought its 10 A current-sense resistor into the light:
Multimeter current resistor – nipped copper wire
Unlike the contemporary AN8008/9 meters, it looks like an ordinary copper wire trimmed to the proper resistance by nipping it with a cutter.
It measures something under 10 mΩ, so I’m sure they adjusted the resistance by applying a known current and watching the meter reading while crunching the wire until the proper value appears.
I may have actually used the 10 A range, but I’d be hard pressed to say when or why, so the resistor is at least as good as it needs to be!
The Smell of Molten Projects in the Morning 