Building a frankenstein camera | Part 2: The Rangefinder Problem

The Rangefinder Problem

Last week my FED 2 - the shell for the Frankenstein camera - arrived. It didn't take long to run into something I hadn't thought through: since I'd never actually used a rangefinder camera, I didn't really know how they get an image sharp in the first place. A rangefinder uses two viewing windows that see the scene from slightly different angles. As you turn the focus ring, the two images shift relative to each other, and when they overlap perfectly, the subject is in focus - similar in principle to stereo vision, but used to measure focus rather than build a depth map. So the camera needs some kind of mechanical connection to the focus pull of the lens. In rangefinder cameras, that's handled by a small lever inside the lens bayonet that connects internally to the lens. Inside the lens, the focus helicoid moves that lever as you turn the ring, shifting the rangefinder patch and aligning the two images horizontally. That's such a clever mechanism. Because you're not looking through the taking lens, you don't need to rely on a perfectly sharp image on a focusing screen - you just line up the two images in the rangefinder patch. That also makes it a lot easier for people with mild vision impairments, or anyone who wears glasses, to focus accurately, as long as they can still see the two images well enough to align them.

There's one catch, though: you can only use lenses built for rangefinder coupling. That bothered me a lot, because I already own plenty of lenses that simply won't work with this camera as it stands.

So, next deep dive: how do we get full lens compatibility on our Frankenstein camera - without drilling holes or bolting on a screen?

From the Inside: Laser Ranging

The starting point: I have SLR lenses I want to use on this rangefinder camera. Those lenses have no internal connection to a focus pull, so somehow I need to bridge that gap. As technical director these are exactly the kind of problems I enjoy chewing on. I really like how rangefinder cameras nail focus, and I wanted to keep that mechanism alive rather than just replace it.

My first idea - which I dropped pretty fast - was to use a small distance-measuring device, like a LiDAR sensor or one of the tiny laser time-of-flight boards you can buy. The plan: fit its optic into the rangefinder housing, trigger a button to measure the distance from the camera to the subject, and pass that reading to our Raspberry Pi Zero 2 W. The Pi would then calculate the lever movement needed and drive a small servo connected to the same gears the rangefinder already uses. The dealbreaker: you can't really focus to infinity this way, because a sensor small enough to actually fit inside the FED 2 - like the VL53L1X, a compact time-of-flight sensor - only measures reliably out to about 4-8 meters.

Magnetic Sensors

Staying on the inside for a moment: for one of my recent film shoots, I needed to measure the speed of a human-sized hamster wheel and feed that into Unreal Engine to drive our virtual production wall. I actually considered a Hall sensor for that job first, but ended up dropping it in favor of a gyro sensor instead - an MPU6050, which reports angular velocity directly, without needing magnets or pulse-counting at all.

That earlier detour got me thinking a Hall sensor might work here too - mount it right next to the viewfinder facing the lens, with a small magnet glued onto the focus ring. But a basic Hall sensor is a switching sensor: it fires a pulse each time a magnet passes by, giving you RPM if you count pulses over time - it has no idea where the magnet actually is, only that it went past. A gyro like the MPU6050 has the same fundamental problem for this use case, just from a different angle: it measures rate of rotation, not absolute angle. You can integrate that rate over time to estimate position, but the error drifts, and drift is the last thing I want when trying to land a focus point. For focus pulling I don't need speed, I need absolute position. So the right part for this job is a linear or rotary Hall-effect position sensor - a chip like the AS5600, which reads the continuous angle of a magnet mounted on a rotating shaft and outputs an absolute angle rather than just a pulse or a rate. Mount one of those next to the viewfinder, glue a small diametric magnet onto the focus ring, and in theory it can report the ring's exact rotation continuously.

Except a lens is big, and chips like the AS5600 are built for a magnet sitting almost flush against them - the datasheet wants an air gap of roughly 0.5-3 mm. The distance from a barrel-mounted sensor to a magnet stuck on the lens would realistically be at least 3 centimeters, and once you factor in the lens diameter and its range of motion, more like 3-6 cm. That's centimeters where the chip wants millimeters, so the reading would be far too noisy to trust. We'd have needed to sit almost flush against the magnet, not several centimeters away.

Moving to the Outside

Next, I looked at translating the focus pull's movement from the outside in. Since I still didn't want to drill holes or cut into the shell, this idea was harder to pull off - but I developed it pretty far anyway. Something on the outside needs to talk to something on the inside, and the only realistic way to do that without a hole is Bluetooth or Wi-Fi to the Raspberry Pi. Same core idea as before: send distance information to the Pi Zero 2 W, and have it drive a small motor connected to the original lever and gears.

The concept: build a tiny sensor that clips onto the lens. Whenever you turn the focus ring, the sensor tracks the movement and sends it to the Pi.

I took this idea pretty far. The device needed to be as small as possible and sip almost no power, since I didn't want a cable running into the camera (which would have been possible with the FED 2 because there is a small hole to connect power to a external flashlight) or extra gear to carry around. That pointed toward an ESP32 - a microcontroller that's extremely power-efficient and has Bluetooth and Wi-Fi built right in. The next constraint was battery capacity, probably the single biggest thing in the whole stack: the bigger the battery, the bigger the device, and size is a hard limit here - it needs to clip onto a lens without looking clunky or getting in the way while shooting. The largest battery I could justify was a 200 mAh LiPo, which fit into a housing I designed in Plasticity. That housing ended up around 2 x 2 x 2 cm - already about as large as I was willing to go.

Then came the actual hard part: how do you capture the lens's focus movement in the first place? I looked at three approaches.

The first: a small wheel pressed against the lens barrel. Turning the focus ring rolls the wheel, and that rotation translates directly into a measurable signal. But it adds a lot of moving parts - a wheel, a spring to keep tension on it, a housing to hold it all together.

The second: something like a miniature treadmill - a rubber band wrapped around the lens, clamped like a tiny tank tread, measuring movement as the band moves. Still not something I loved, since it needs millimeter accuracy and the band could easily slip.

The most promising: repurposing an optical mouse sensor to track movement. When you move a mouse, you're translating real-world motion into a digital signal - and a sensor like the PMW3901, an optical flow chip originally built for mice and now common in drone position-hold systems, fits the size budget nicely. The only catch is that it also needs power, though that's a non-issue in practice - I could put the ESP32 and the sensor into deep sleep and only wake them when triggered.

I designed a few housings, put together some concept sheets, and ran into one real problem: how do you actually attach this thing to a lens reliably? Magnets felt too loose - I didn't want to risk losing the device, and I didn't want to babysit it either. Double-sided tape felt just as flimsy. The only reliable option left was some kind of belt or strap around the lens barrel.

Honestly, I think that could have worked, but it would have added a lot of complexity. After a few prototypes built from paper, I wasn't satisfied enough to keep pushing on it.

Letting Go of the Rangefinder

As I mentioned, I really wanted to keep the rangefinder. I love how it feels to nail focus by overlapping two images - but I couldn't find a reliable, simple way to make that mechanism talk to a modern sensor. So, back to the Frankenstein project: we want to give the FED 2 a digital sensor, but I don't want a big display bolted onto the back.

My next idea: replace the viewfinder optics with a micro-OLED display fed by the sensor's HDMI output. That would let me see exactly what the sensor sees, enable edge detection, and tell at a glance whether the shot is in focus. Digging around online, though, high-resolution displays that small just don't exist in a reasonable price range - they're expensive precisely because they're tiny. The largest that would fit inside the FED 2 is roughly 1 x 1.5 cm, and I'd still need to redesign the viewfinder's micro-lenses to focus on that panel sharply. The only realistic way to get a proper digital viewfinder would be to buy a used Sony A6000 or newer, since those already have one built in - but that's well outside the budget for this build.

Which brings me to the approach I'm actually going with. Right now, the plan is to use our mini computer (the Raspberry Pi Zero 2 W) only as a trigger, connected to the camera over PTP. But why not also add a capture card, pull the HDMI feed straight off the donor camera's mainboard, and run red-edge detection on the image? To make that feasible on a Zero 2 W, we crop to the center of the frame and check for red edges - whenever there's enough red detected, we trigger a small LED mounted right in the rangefinder's field of view. Looking through the viewfinder, you'd see that dimmed colored light and instantly know whether you're in focus.

I tested the concept with my phone - filled the whole screen red, yellow, or green, and shone it straight through the rangefinder eyepiece. It worked exactly like I'd hoped, and didn't get in the way of framing the shot at all.

Thinking it through further, though, pure red-detection would box me in - what happens if I'm photographing a red car? The system would call everything sharp regardless of actual focus, and there'd be no way to tell whether my current focus point sits in front of or behind the subject. So I kept iterating and landed on this approach instead:

Preprocessing:

• Center-Crop: Instead of processing the full-resolution feed (which would bottleneck the Zero 2 W), we limit frame analysis to a fixed 160x160 pixel ROI centered in the image.
• Grayscale Conversion: The frame is converted to grayscale to simplify the edge-detection matrix and reduce memory footprint.

Sharpness Metric:

Applying a Sobel / Laplacian filter (specifically the variance of the Laplacian, or the gradient magnitude) to quantify high-frequency content within that ROI (region of interest).

• Logic: Higher variance means sharper edges - more contrast transitions - which we use directly as our focus score.

So the technical summary of this workflow, in total:

A capture card draws around 140 mA, which is a lot compared to the Raspberry Pi Zero 2 W, so we should only power the video feed when it's actually needed - which means a "power button" of some kind. Luckily, the FED 2 already has a self-timer button on the front of the shell, which we can repurpose for exactly that. Press it, and the capture card gets power, sends its video feed to the Pi, and the Pi automatically starts the analysis and adjusts the LED color based on the result.

I'm pretty happy with this approach, but we'll see if it actually holds up once it's built. In my next post I'll get into making more room inside the body of the FED 2's to fit all this gear - specifically, designing our own lens adapter to push the flange distance further out.