In this article I'll cover the design and construction of a high performance segmented capture film scanner, made from an off the shelf 3D printer, 3D printed parts, a Raspberry Pi HQ/GS camera, Raspberry Pi 5, and a high performance industrial lens.

Spoiler warning: A future article will cover how I replaced both the camera, Pi 5, and lens with better though more expensive options.

Introduction

The scanner design presented is a first-pass solution to a problem most people don't have, which is a convenient, very high resolution, semi-automatic film scanner that isn't a DSLR scanner.

What it do?

The scanner solves a key problem faced by dozens of photographers all over the world: how to get my film pictures into the computer, without using my normal flatbed scanner, or my DSLR and a copy-stand.

The problem with flatbeds is they're slow and the optics usually aren't that great (even a V850 needs a lot of sharpening to give decent results). Further, the V850's sensitivity isn't actually that great and it will often struggle with dense colour negatives. Scanner software is another thing, Silverfast isn't bad but it's not super stable and has a lot of useless settings and slightly eccentric behaviour.

The problem with DSLR scanning is it's even more fiddly, very manual, at least the scanner can be left to work for an hour per half-roll. Additionally, the DSLR scanner will be resolution limited to the DSLR you have (if you have a GFX 50 or 100 then just use that), and I just don't want to do that because everyone else is doing it.

Concept of execution

If we consider a flatbed scanner, those are basically obsolete tech and use a line scan sensor (usually two sets with an offset to fake more resolution; "real" performance is in the 2400 DPI range at best). Film stays in place and we slide the scanner over it, keeping the motion really smooth. One benefit is these can usually do IR-scan with automatic dust removal for colour film. Overall it's slow as shit and as mentioned even a current V850 is basically obsolete from the factory.

Nikon CoolScan's are better from what I'm told, while I don't doubt their performance these seem to at best use a strip-loader that needs babysitting. These scanners are all 20+ years old and quite expensive so not really an option.

If we then consider a DSLR-scanner setup we keep the film in place and point a camera at it (with the best macro lens you can find), and capture the whole film using a 2D sensor. For larger film sizes you'll probably be doing a segmented capture and merging manually. This is pretty good, the camera is pricey but most people use the DSLR for non-scanner things too. Disadvantage is you have to either move the film or camera, then align it and probably refocus per frame. IR scanning is technically possible but rarely done since most cameras have IR-cut filters.

The initial concept I had in mind was using a 9⁄125 µm fiber coupled light source as a mechanical flying-spot scanner, tracing it across the film plane and capturing the image using APD's on the other side. This was ruled out after a day or so due to the obvious issue of insane mechanical precision requirements and how incredibly slow it would be. This is kind of how a drum scanner works though.

This solution is a hybrid approach of the first two: instead of using a huge sensor to capture each frame, use a smaller and cheaper sensor to capture segments of the film. Then automatically move the camera around to get a whole frame, then merge those segments automatically into a huge image of a film frame.

This approach requires several pieces to work:

• Camera with decent dynamic range and suitable pixel count/size/price
• Lens with zero distortion and incredible sharpness
• Motion stage (X/Y/Z)
• Film mounts that can keep the film very flat
• Backlight, ideally RGB+IR
• Image capture + motion control software
• Image merging software

We'll go through the considerations for each one below:

Camera & lens

The lens is the most important piece, and I figured that if I got the best lens for the job then I could always find a sensor to match. You can generally get CMOS sensors with pixels in the 0.8-8 µm range with varying sizes from 1⁄4" up to a low-cost maximum of 1" (1" sensors are pricey but can often be found used).

To simplify the merging later we really want absolutely no distortion or vignetting. The lens should have a resolution in the object-plane (i.e. the film's size) of around 5-10 µm if possible, this works out to around 4800 dpi in scanner terms or around 30-50 megapixels per 35 mm frame.

Lens considerations

I started with the lens: after some thinking about it I decided that telecentric machine vision lenses seemed like a good idea. These lenses are perspective-free (i.e. give an orthographic projection) and are typically optimised for sharpness, distortion, and to work at a specific fairly short distance. They're usually specified with a magnification which is the scale factor vs. object at the optimal distance vs. how big it will be on the sensor's plane. A common use case for this type of lens might be component identification in an electronics pick-and-place machine.

Obviously we want the best mix of big object size, large image circle (to fit a large sensor) and resolution. What we don't really care about is f-number beyond the diffraction limits it imposes, we control the backlight power and the integration time can be as long as we need within reason.

I initially tried a Daheng DH-MML1-HR65 "1⨉" telecentric lens, which isn't a terrible choice. This lens has a resolution of around 7 µm which isn't the best but also perfectly adequate really. I encountered two issues with this lens: 1) the image was slightly brighter in the corners which was pretty noticeable when viewing the image at lower magnifications, 2) the lens is really 0.5⨉ so I was getting twice the FoV that I expected.

The DH-MML1-HR65 is still good considering it's less than $50 used, but assume it's 0.5⨉ and expect to crop out around 20% of the image to avoid vignetting. Do note that I switched to the EO lens before implementing flat-field correction (see later chapters); with flat field correction the DH-MML1-HR65 may well be completely usable.

The real big boi is the Edmund Optics SilverTL™ 0.6⨉ (56-678) bi-telecentric lens. This is a fair bit more expensive and longer, but it's good. The 0.6⨉ magnification is actually true, there's no vignetting or distortion, and the sharpness is divine at around 3 µm spot size. I think this lens is close to the best possible lens for this project (for up to 1⁄2" sensors), I'm very happy with it! I generally run this lens at f⁄6, though slightly more performance could be squeezed out at f⁄10.

As shown above the selected lens has a very good sharpness both for coarse details (low frequency MTF; often technically erroneously called "micro-contrast") and fine details. The lens will be able to reproduce the fine details of T-Max/Ektapan 100 well, though not perfectly.

Lens alternatives might include other SilverTL™ products or another series from Edmund Optics. I think a bi-telecentric lens is preferable to avoid vignetting artifacting.  One fun alternative might be to use a low-magnification lens and just image the entire frame at once using a higher resolution sensor. The alternatives I found seemed to cap out at around 5 megapixels so a pretty significant resolution drop.

Camera

I initially intended to pick up a GigE Vision industrial camera thing, these are available from various Chinese manufacturers and usually pack some kind of Sony CMOS sensor. These do have a benefit in that you have a good selection of sensors to use, but they're a little annoying to talk to (usually some precompiled driver you have to use).

The optimal sensor for the EO lens is something with around 3 µm pixels up to around 1/2" format.

As a quick start I had a Raspberry Pi Global Shutter camera sitting around, this has an IMX296 sensor with 3.45 µm square pixels, 1440⨉1080 format, and 10 bit output. I did the initial testing with this camera and it's not a bad choice at all. What I didn't realise at first was that this sensor is colour only, and I really didn't want the bayer pattern blurring out my monochrome images.

Once I realised the colour issue I switched to the Raspberry Pi HQ Camera, which uses a rolling shutter IMX477 sensor with 1.55 µm pixels in a 4056⨉3040 format, and it does 12 bit output. This is oversampling the lens, and so pre-processing is to de-bayer then downscale to 2028⨉1520 (4⨉ drop in pixel count), this way each final pixel is represented by 2 green pixels and 1 each of red/blue, and should match the lens very well.

Sony's info on the sensor performance is a bit limited but Strolls with my Dog has done some work calculating performance characteristics here: Pi HQ Cam Sensor Performance. As such we know the sensor is capable of around 11 stops of dynamic range, and if we want to we could disable the defect pixels management (though I've left it on). This is comparable to many cameras used for DSLR scanning, to extend the dynamic range I use a deterministic HDR capture (described later).

The IMX296/GS camera had one big benefit: very high sensitivity, I needed around 5x the exposure time per shot with equal lighting for the IMX477. Given the ratio of pixel area is around 5⨉ this isn't a big shock I guess. "Fortunately" the readout and processing time is much longer on the IMX477 too, so the increased exposure time isn't felt as such. Since there are two extra bits per pixel I could turn down the frame averaging to end up at around the same total time per frame.

Obviously I disable as much of the in-camera and in-library processing as possible, including minimising analogue gain.

Dynamic range & Dmax

The IMX477 sensor natively has a dynamic range of 11 stops. The relationship to Dmax isn't particularly complex^[0], it's simply log₁₀2ⁿ where n is the number of bits or stops. An 11 stop sensor therefore has a Dmax of 3.3, by setting our exposure to the base fog instead of the backlight we can maybe add 0.15 or so to that. This is sufficient for a standard B&W negative, but we don't have huge margins.

In the image capture/processing section below I explain how two captures can be used to extend the dynamic range somewhat. By using a HDR gain of 64 our dynamic range is in theory extended by 6 stops, to a new Dmax>5. This corresponds to >17 stops of dynamic range for reference, we'll call this a theoretical Dmax since I don't have the equipment to prove it's real.

In practice the dynamic range is scene dependent: imagine a pair of lines of density 5.0 with full transparency in between. Depending on the width and spacing of the lines there will obviously be a glow effect around the lines. This is what the lens MTF chart above is showing, for finely spaced lines we simply can't see the true density in between them due to glow from the transparent areas: we have low contrast for finely spaced line pairs (= high spatial frequency). This is not something generally talked about with film scanners but is a limiting factor in basically all optical systems, and is analogous to bandwidth in an electrical system.

I'm pretty sure the "clarity" slider in most image editing programs works to increase low-medium frequency contrast; it would probably improve my scans, though I'm hesitant to do processing in a scanner that might degrade image quality in edge cases.

The ability to punch through a dense-ass negative is quite useful in general, even if fine detail contrast is still limited by the lens.

^[0]: This is the case for "raw" linear light sensor data; an 8 bit gamma-encoded image is not limited to 8 stops of dynamic range.

Alignment

It's pretty important that the camera sensor plane is perfectly parallel to the film plane, otherwise you'll get blurry corners and any vignetting is magnified. I use a kinematic lens mount (kind of annoying to mount but very easy to adjust), this lets me adjust the lens and camera plane in the X/Y axis.

As for how to optimally align it, the use of a telecentric lens actually makes this easier than you'd expect. Just place a precision pin on top of the film plane and look down at it.

Since the pin is reflective on the sides it makes a ghost image around it, and adjusting the kinematic mount to center this reflection around the pin body ensures the optical axis is parallell to the pin outer walls. Since the pin is precision, the pin should be normal to the film plane and we've achieved alignment.

This is significantly more precise and faster than tricks like trying to compare corner sharpness etc.

A secondary alignment that's more obvious how to do is aligning the sensor's X/Y axis with the motion stage, just twist the camera until horizontal moves don't also cause vertical moves.

Motion stage

The motion stage needs to translate the camera vs. the film in the X/Y plane, and move it up and down (Z axis). There's only one obvious choice here: a 3D printer. If you have a higher budget a desktop CNC-router would also be a good choice, though backlash in lead screws might be more of an issue.

I considered buying the cheapest printer available new but those look awful. I found a Creality Ender 3 V3 SE lightly used locally so picked that up. A used 3D printer is by a very wide margin the cheapest way to get a motion stage. 3D printers are generally pretty damn precise and have very little of e.g. backlash due to being belt driven. Since I already have a slightly nicer Ender 3 model I felt comfortable using this as a starting point.

To control the printer I obviously ditched the built in control software and flashed it with Klipper, and went with a moonraker + fluidd control UI. Connecting to this from my Python script went very painlessly and it's just worked since I got it working. Waiting for motions to finish was also quite simple, just issue an M400 command after a motion.

Klipper makes it very easy to manage the changes I make to the printer, e.g. my machine dimensions and probe offsets are different than stock, but this just means working out the new parameters and updating the configuration file. One funny is that the 3D printer control software Klipper for some reason isn't very happy with my machine if I remove the extruder details , so I just pretend we still have those parts. This is similar to how most chess playing engines don't like it if you give it a board without a king on it.

Now a 3D printer doesn't really need to be very precise in a lot of ways that we care about, but it's over all perfectly acceptable and with the steppers configured for optimal resolution it's surprisingly good. The X-axis seems to tilt up/down a bit vs. position but this only amounts to approx. 50 pixels alignment error over a 35 mm frame which is handled in software.

Configuring a suitable acceleration is very important to avoid shaking the machine during image capture, and is fortunately trivial to do.

As mentioned above keeping the film plane aligned to the sensor is very important, but it's also important to keep the film-sensor distance constant. What may not be obvious is that bed flatness is relatively unimportant (which is good, the E3 V3 SE lacks the adjustment screws). Using Klipper's bed mesh mapping feature and the honestly quite good optical-pin based CRTouch probe we can have Klipper compute a Z-correction mesh that is transparently applied. If the bed is a tilted plane then the pin-alignment described above will make the sensor parallel to it, and the bed mesh will adjust the Z-offset automatically as we move around, in theory this perfectly cancels out any bed levelling issues.

I do notice some backlash in the Z-axis movement, on the order of 50 µm or so. This is mostly solved by fine tuning the autofocus in the middle of each frame before starting a capture, which also ensures that any remaining bed mesh error is minimised in the scan-area.

Film mount

I initially intended to use a glass sandwich with ANR+clear glass to squeeze the film between. This was a good way of making newton rings, future work will be to improve this situation. Double ANR-glass might be one way to solve this, though sharpness could be an issue.

For initial testing I used some photo paper with a hole cut into it as a film guide and mask, photo paper is a bit thicker than typical films so if the film was naturally flat this was fine. Curved films that touched the top glass consistently caused newton rings. 

I still had the V850 film holes so I used these for most scans, these don't hold curved film very flat but with per-frame autofocus it works out ok.

If you wanted to you could probably use the extruder motor drive to run a film-puller to scan a whole uncut roll. This is a whole project in itself, but could be super neat and a 35 mm-only scanner could be made much smaller if this were done.

A fun side-project could be a 8/16 mm film scanner; this would be easier since with a reasonable lens and sensor combo you wouldn't need any stitching. I don't currently work with motion picture stuff unfortunately.

Backlight

A set of 3 pcs 8⨉32 (10 mm pitch) WS2812B ("Neopixel") flexible light panels are used as the backlight. A future upgrade will be to add IR capabilities, which I expect to do by making some super thin IR LED strips to go in between the Neopixels. 

The use of a spatially controlled backlight has a huge thermal benefit and makes tweaking uniformity easier. Lighting the entire film-area up evenly to a level where ambient light won't affect the scanning would require on the order of 100 W of LED's, while <10 W is used to light up a given 35 mm frame.

For one-shot colour the R/G/B PWM-balance is adjusted to compensate for orange-masked negatives. (An alternate approach is to do field sequential capture with variable exposure time)

Future work will probably involve making a custom backlight assembly with more precise PWM control and IR emitters. If the backlight is wired to the camera hardware trigger lines then PWM control could be synced to the camera exposure.

Capture and image processing software

I wrote a basic capture program in Python using a variety of libraries. The bulk of the camera work is done by Picamera2/libcamera, which while slightly lacking in documentation is a very nice project once I got my head around it.

For actual image crunching it's the obvious choice: numpy and OpenCV. I use a variety of OpenCV functions to do filtering in the capture system. Unless otherwise noted the entire processing chain is 32-bit floating point up until where TIFF's or similar are generated.

The control software is a basic terminal curses application that configures the scan size/start point, exposure control, and autofocus. When set up it scans the image and outputs 32-bit float images (actually compressed numpy arrays) as well as some JPEG's and histogram plots, these can be viewed in a basic HTML site as the scan happens. After a completed scan a JSON file is written out containing the frame parameters like number of segments, overlap in pixels, filenames, frame/roll ID to name the output file, and parameters that go into the EXIF data later.

For colour scanning the colour captures are merged during scanning; with monochrome scanning the output is still RGB with equal R/G/B values. IR data is stored separately.

The control software calculates segment positions using the sensor/lens configuration, and ensures a 50 px per side overlap is present in each frame for later merging.

It also has a concept of a "roll ID" and frame number that are used to name the output files, usually I just go with a format of "YYYYMMDD_n" using the date of development and n just incrementing for each roll that day.

The frame index is at present used to automatically step over to the next frame when using my 3x6-strip 35 mm stencils, though in future it will need to be configuration controlled to support medium format (or 4x5/8x10 if I ever go down that road).

I also make a real-time image view with overlays to help alignment and monitoring, this is shown on a 5" DSI LCD on top of the printer, or it can be viewed in a webpage remotely. To make the real-time viewer I use the CLI image viewer 'feh' which is great for this, I just launch it as DISPLAY=:0 feh /dev/shm/cam.bmp -F -Z and it will automatically update the view every time a new file is written by my program.

The overlays include a histogram with min/max indicator, gamma/HDR info, Z coordinate, a view of the number of segments to be captured and location (bottom right, currently showing a capture in progress), and the autofocus indicator (Green/Blue/Red bars upper right). The green box is the ROI/colour match/AE-zone and is placed over the film base, the blue box is the AF area, and the red box shows where the overlap will be between segments. The yellow arrow in the upper right changes every time a frame is generated to make it easy to tell if it's live or not.

Bayer sensors & monochrome light sources

One issue you'll run into using an RGB sensor with monochrome light is that the saturation level of the sensor will seem to be dramatically reduced. This happens because a normal RGB-greyscale conversion uses weighting of the RGB-values that assumes you have a pretty grey scene.

When using monochrome backlighting I only use the intensity value from the corresponding channel and the rest are discarded after debayering. This seems to work ok.

Autofocus & auto-exposure

The autofocus system used is fairly simple, and is provided as an operator aid and normally done automatically in the center-patch of each frame before scanning a frame.

To evaluate sharpness I do a laplacian transform over the image (a sort of edge-filtering operation), and compute the variance of the laplacian transformed image. This becomes a unitless number that is used as the AF score (grainier film stocks obviously end up with a higher variance). The autofocus algorithm performs a trinary search about the selected distance, this means it checks the AF score at Z positions +/0/- the selected range and goes to the best position of these, repeating about the new optimal value for each iteration. The range to search is divided by 2 per round and typically I search ±0.15 mm down to around 25 µm step size in the automatic frame-center mode. The manual activation searches a larger range.

Auto-exposure is a pretty simple integrator regulator that can be activated on demand. It takes a couple of averaged images, reverses the gamma correction to work in linear units, works out the percentage-error and scales the exposure time by the error. This converges quite quickly, so there's an early out if the 8-bit equivalent error is less than 0.5 levels. The green patch in the display shows the ROI which is averaged for auto-exposure, it's small enough to fit between sprocket holes easily. A simple template matcher runs in parallel and updates the position based on a sprocket-hole template to ensure it's always positioned sensibly.

In monochrome mode autofocus and auto-exposure is done using the green light source, since this is the wavelength where the lens has best performance. 

Colour negative film base correction

To simplify my mostly manual colour negative inversion process I use the adjustable RGB backlight to adjust the film base colour to neutral.

This works by positioning the green ROI marker over the film base, the blue backlight is set to around 80% of maximum and the exposure time is set as usual based on this. The average value for blue is then used as a target for green and red, adjusting the backlight intensity for these channels to match.

By doing this the inverted image at the end of the chain will have the film base at a neutral grey level, and in theory all that's needed is contrast adjustment to have a "precise" colour response.

In general this adjustment is only done once per roll if at all. A set of presets can be loaded as starting points and refined if desired.

Image averaging

To reduce readout noise I accumulate somewhere between 4-16 images depending on how I feel. This is done using a simple flat weight so e.g. if I wanted to merge 16 images then I'll multiply each image by 1⁄16 and add them together. Readout noise is as expected reduced by √N for N captures, while the film being captured is unaltered since it never changes.

Flat field correction

The IMX477 seems to be a very stable sensor with low drift and readout noise. I apply the standard darkframe/flat field correction principle to correct for a slight non-uniformity, leading to the lower right corner being slightly darker than the rest.

For the two-exposure HDR mode separate corrections are used since exposure time and analogue gain are quite different. A third flat-field is applied to the merged image to further refine the image quality.

HDR capture

While various HDR techniques exist, I don't care for the standard ones since I need the HDR to be applied equally to all the composite images. I also don't care for tone mapping algorithms in an automatic pipeline, they tend to produce obvious aberrations.

I use a simple deterministic HDR technique where each sub-frame is captured using different analogue gains up to the maximum, adding exposure time if required.

I then mix these with a scaling factor (OpenCV AddWeighted): with a factor of e.g. 64 the weight is simply 1/64 since the sensor provides linear-light values.

When averages are called for I average high/low captures then merge these. If e.g. an HDR gain of 64 was requested then the analogue gain will be capped at 8 (16 is sensor max), and the exposure time would be multiplied by 8 to make up the difference.

As I discovered in the docs, there is no guarantee for how many images need to be read out before a change in exposure time or analogue gain is effected, but I found stopping then starting the picamera2 instance made it apply the settings on the next frame. This was way faster than waiting for a correctly set frame to pop out of the pipeline.

Gamma-management

I elected to use a continuous^[0] gamma (𝛾) of 2.4 for my system to sort of match Rec.2020, this became a necessity in the HDR modes to give presentable images that didn't need a ton of post processing.

For real-time use the preview-image is converted to 16-bit and a LUT is used, during stitching a floating-point gamma is used.

^[0]: Continuous meaning my gamma correction stays a true gamma down to 0, as opposed to switching to a linear scaling near 0. My offset-correction keeps the black level under control despite this.

Capture time

With the configuration discussed here, each sub-frame covers around 10⨉7 mm with some overlap. Using 64⨉ HDR merging and averaging around 2-8 frames the capture time per sub-frame is around 2-5 seconds. Motion time is typically 1-2 seconds between frames.

Some optimisation has been done to avoid slowdowns such as using multiple threads to handle e.g. display updates, talking to the camera in general, and saving output files. This means the capture cycle is effectively time limited by 1) printer motion, acceleration has to be low to avoid shaking or you have you wait a bunch after motion, and 2) actually capturing the images where 2a) multiple exposure averaging takes a bit of time and 2b) switching exposure time and analogue gain takes a bit of time.

Image merging software

The image merging software is written in Python as usual for my image processing. It's designed to run on a much more powerful computer than even the Pi 5.

I chose this split since I expected the amount of number crunching and RAM needed to be fairly large with medium format scans, and waiting for merging to happen between scans would slow down the capture process. A script running on a server polls the output folder of the Pi and automatically grabs and stitches each scan.

Merging

To merge the mosaic images I initially tried the obvious solution of just asking OpenCV and Affinity Photo to put the frames together for me. This approach works sometimes but failed tremendously in general. 

I think the issue with standard image merging algorithms is they're very clever and optimised to handle a bewildering array of lens and camera distortions and to reject noise/fine detail.

I had the basic idea down before starting, getting it working wasn't too difficult and mostly boiled down to figuring out how to make OpenCV do what I want and learning the basics of image processing again.

The idea is this: we know that all our images have an amount of pixels overlapping on each side, and we know their approximate orientation. I decided to only handle orienting two images at a time along one axis. In the right hand image, we select a rectangle on the left side which is our template (cropped to less than our expected pixel-offset error in the X/Y axis), then we grab a fairly large chunk of the rightmost edge of the left hand image and call this our reference.

Then I use a standard OpenCV template matcher, using the Square-difference comparison method, this returns the pixel offset in the left image subset where our right-image template is the closest match. It does this by picking a point, "placing" the template over the image at that point, then it adds the square of the difference in pixel value for each pixel in the template vs. the reference image. This is the "score" for putting that template at that position, this is repeated for each offset the template can fit into. It's kind of like putting two transparent images on top of each other and trying to line them up as best you can.

This matching technique would be sensitive to intensity variations, optical distortions, noise etc., but since I built a system with the best lens the idea is that the images will always contain film grain patterns in the overlap. Film grain is basically random, and by selecting the biggest template that will fit it's all but impossible to get a false positive.

During development the false-matches I've had were caused by misalignment of the camera, incorrect overlap settings etc. that combined to make it impossible for the simple alignment to work. I also noticed that humans are pretty bad at quickly spotting a poor merge job, I had to zoom in on details to spot some errors.

With the template position found it's a simple matter of calculating the X/Y offsets to apply when putting the two images next to each other. I crossfade a few pixel region between the frames in the overlap, which can sometimes be seen at 100% zoom as a slightly blurrier band. The blur-band doesn't seem to be visible at normal magnifications. For the Y-axis offset I simply crop both images, allowing images to contain dead areas would complicate processing and isn't necessary when the scanner is well aligned.

The merging works its' way along the X-axis making strips, then later loads and rotates the X-strips to merge along the Y-axis.

The Y-crop is a good indicator of how well aligned the camera is vs. the printer, the Y-axis error should be adjusted to +0-10 pixels per sub-frame. If the Y-crop is negative the Y-axis overlap region tends to be cropped out, causing issues with the later Y-axis merging.

For my own reference: rotating the camera clock-wise decreases the Y-error. For those wondering: the focus-adjust ring on the HQ/GS camera is M1.6x8 mm, I replaced mine with a DIN912 style hex-head screw since the flat head was damn near impossible to precisely turn.

The processing is fairly amenable to multi-threading, each X-strip is processed in parallel, and rotations/gamma/sharpening are applied before merging for the same reason. Typical wall-clock time for a 35 mm frame is 30 seconds for a 50 MP sprocket-hole scan.

Sharpening

I do a basic unsharp-mask over the image to improve sharpness. The parameters that seem to work best are a strength of 1.3 and a pixel-dimension of 2. I obviously want the sharpening to never be excessive, but I also prefer not to have to apply sharpening in post processing.

I did briefly experiment with using a Wiener filter but found this to be unnecessary in this system, it leads to very visible artifacting if not perfectly tuned and my PSF is very close to 1 px anyway. A Wiener filter is basically guessing at what the "point spread function" (PSF) is, then using this as a filter to reverse the system blur. It can give very impressive results for unsharp or motion blurred images but it doesn't seem suited to general purpose photographic use due to the hideous artifacting. Github user michal2229 has a nice repo you can run to try it out yourself: dft-wiener-deconvolution-with-psf, though note that you have to change cv2.CV_AA to cv2.LINE_AA to make it not crash with circular PSF's.

IR dust removal

Making a good IR dust removal system will require a lot of testing, at the time of publication my backlight lacks IR emitters so I haven't been able to start on this.. The minimum viable product as I see it is creating a dust-map to highlight image areas with dust for manual painting. This in itself is probably a worthwhile feature.

I expect the sequence of operations will be to threshold the IR image, then perform some morphological operations to create a slightly larger mask around each object found to paint out. These object-masks can then be applied to guide an image infill algorithm of some sort.

Other functions

My merge script also does a number of other functions including sharpening and generating EXIF-metadata to embed in the pictures. For posterity this scanner is called the "LA2YUA E3V3SE Scanner" in the EXIF data, named based on the printer used as a base.

I decided to limit the output image to be less than 10'000x10'000 pixels since images exceeding 100 megapixels are pretty problematic to work with.

The standard output format is a 16-bit greyscale or colour TIFF file. Exporting DNG files is entirely possible (and experimented with) but I've found DNG files to be annoying to handle in a scanner workflow. Note that to output 16-bit TIFF's in Python, use the tifffile library instead of OpenCV, it supports way more esoteric TIFF features.

Future work is improving colour management and applying ICC profiles generated by e.g. imaging an IT8 chart for colour modes.

Export scripts

My workflow is a bit primitive in some ways, I use Affinity Photo for editing, touching the original TIFF's generated by the scanner. I typically add adjustment layers for every adjustment including dust removal, so the original image data is retained.

After editing each file, I save it and use macOS tags to quickly identify which images I consider worth keeping (red tag is Control+1, very quick to do).

I then run a simple shell script to convert the TIFF's to JPEG and AVIF outputs, keeping the tags for easy sorting. JPEG's are copied into an export folder, the AVIF's are only used for my iCloud photo library. AVIF's are pretty good if slow and a bit buggy when loading 50+ MP images, but macOS Preview.app doesn't support writing them so JPEG's are preferred.

Report generator

Since each roll is typically 10+ GB of image data after conversion, I don't want to keep the original files in online storage forever.

For posterity my storage tiers are: local SSD replicated to server SSD in real-time, older files deleted to keep space free, an online HDD copy manually rsynced, and a set of LTO-5 tapes (approximately 1 tape per year's worth of pictures). I'm considering moving to LTO-7 as prices come down.

To quickly let me reference what images are on a given roll, and to keep a record of e.g. what camera/lens/film/processing was done to a given roll, I make a one-page "contact sheet" report. This is a PDF that I retain in online storage to let me quickly look up any roll I've scanned.

I originally did this using some templates in Affinity Publisher, but since that can't be scripted it was a bit tedious. As part of this project (while waiting for some long 3D prints) I wrote a simple Python program to load a simple text file containing roll information I input manually, and the JSON files for each frame.

The text file contains all the information shown in the table at the top, except the roll reference (inferred from the as-scanned roll ID), film type (can be overridden if desired). There's a free-text area which is put into the large area in the table, this will usually contain information such as what kind of event the photos are of, notes regarding development where I tried something new, or comments on issues in the scanned images.

The Python script downscales images to an appropriate resolution (~600 DPI is reasonable for a digitally viewed PDF) and a coloured border is added to each image based on the macOS tag (red border = not tagged, probably rejected). Finally a LaTeX file is written out containing the information, 

This is a work in progress, I'd like to make the actual image grid a bit nicer looking and put the frame number as an overlay over the images, but LaTeX isn't the easiest thing to fine tune.

Summary

The presented system is a nice starting point, though some issues are present that makes this a less than optimal system. At the time of publication this system has been partially dismantled to start work on the follow-up, which will be the subject of a future article.

The main issue with using CSI-cameras on a Pi is the very limited selection of sensors, and their poor speed as a result of this. There's no particular upgrade path available either, it's more of a take-it-or-leave-it situation. Due to the low speed of the HQ camera I ended up with a parallel-colour image, which has moderate colour separation without a colour correction matrix. The use of a faster monochrome camera and field-sequential colour should give better uncalibrated performance.

The choice of a bi-telecentric lens seems to stand the test of time: the exceptional distortion performance and resolving power is real, stitching images captured with this type of lens is trivial compared to more standard lenses. As noted at the end of the timeline below some lens issues were found with stray light, but this can be worked around. The most major issue is where the film strip is shorter than the mask opening, leaving a large clear area. The workaround is basically to put some tape over that area.

The film mount is not an optimal solution, initial tests with the ANR-glass stack suggests newton rings are very much a problem if the film is curled. This is future work.

The choice of a 3D printer with belt driven axis and stepper motors seems sensible, it is a highly affordable motion control system that seems to offer acceptable performance. The choice of my specific Ender 3 V3 SE wasn't optimal, the motion range is slightly limiting and makes comfortably scanning full 35 mm rolls impractical. Further, the system speed is limited by the "bed-slinger" approach since the bed now contains a fairly large assembly with a lot of inertia and poor stiffness. A gantry-type CNC router base, or some type of Core-XY printer would be a better choice since the camera-lens assembly will always be easier to move than a giant light-box.

The Pi 5 is a capable little computer, but it's at its' limits here and is easily outclassed by a SFF computer from 2018 that cost around the same. For reference the Mk. II system uses a HP ProDesk 600 G3, which can take a 10 Gbit⁄s network card.

Future work

As mentioned above I'm publishing this article after starting work on a Mk. II system.

Key points expected for Mk. II include:

• Use a GigE-Vision camera for speed and to give better control over the image capture
  • 10GigE-Vision as a future upgrade path
  • Use a normal computer to support higher-speed I/O
• Replace the SilverTL lens with a CobaltTL lens that can support a 1" sensor, giving a ~4⨉ increase in FoV while retaining the same spatial resolution—a major speed improvement
• Camera will likely be an IDS uEye variant, since their software stack seems to be pretty good and a wide array of used cameras are available
  • I did some experiments with MDVision cameras but found the software to be somewhat unstable and the camera didn't really behave as expected according to the docs. I think this could be worked around but an IDS camera was available to borrow.
• Backlight will likely be a custom panel optimised for this use case:
  • RGB+IR LED's as tightly packed as practical
  • Each pixel only needs on/off control, not per-pixel PWM like a Neopixel
  • Array update speed doesn't need to be all that fast
  • Each colour channel needs a high speed PWM that can be synchronised to the camera flash trigger output line
  • I expect the Pi Pico PIO-functionality will be well suited to implementing this control scheme
  • If the backlight is only on exactly when the camera is exposing, the power consumption should be significantly lower than the current system by only enabling the LED's when their output is useful
• Nicer film holders will be a mechanical engineering challenge

Timeline

Initial idea

Late February 2026 I was scanning some slightly cooked pushed Vision3 250D and noticed that the blue channel was close to saturated in my V850 scans. I was also generally unhappy with the sharpness of my scans, especially when dealing with Kodak's classic curvy 35 mm base.

Sketching a concept

In early March 2026 I started thinking of a silly idea, looking at using a 9⁄125 µm fiber-end as a flying spot scanner. This idea was sketched out and I did determine that I could get the required laser sources to make a RGB+IR signal to drive the emitter. Obviously this was ruled out once I started thinking of the mechanical requirements to move such a tiny spot over the negative, and the required detector performance would be pretty challenging too. I never bothered calculating the scan time (hours?).

A reasonable concept

Later in March 2026 I started thinking along the lines of a segmented capture scanner, and started looking at motion stage components. After looking at really cheap 3D printers on AliExpress and checking reviews I decided those are basically useless. Looking locally (via Finn.no) I found that a lot of people were and are still selling barely used 3D printers for a solid discount, and the E3 V3 SE was available barely used in box for less than half the new price. A real "for sale: baby shoes, never used" moment. I picked this specifically since it's a fairly pro looking closed design instead of looking like a collection of loose parts in formation.

At this point I was looking at Chinese made GigE Vision cameras, and had selected a reasonable monochrome camera, with the idea being that I'd use a PYTHON1300 based camera I had bought previously for a prototype. These cameras would be more optimal since I could get monochrome sensor variants, but once I remembered I had a RPi GS camera sitting around I decided to use this, figuring that this was a decent monochrome camera.

For lenses I remembered thinking telecentric lenses looked cool previously, and looking into what was available in AliExpress I fairly quickly found the Edmund Optics lens I rave about above, showing it to some optics designers I know they seemed impressed by the stated performance figures. For concept-proving I ordered up the DH-MML1-HR65 since it's a lot cheaper.

I also spent some time thinking about backlights and film mounts, after discussing the concept with some older colleagues who had clear memories of mounting slides I figured that the ANR glass + top cover glass might be viable.

Camera prototype

In the middle of March 2026 I had the 3D printer, the 1⨉ lens, and the GS camera in house. I did some initial testing and was quickly impressed by the achieved sharpness. I had issues with sensor/film plane alignment that were solved by the kinematic mount later, and I had to work out how to actually verify my alignment (pin-method described above is the best).

3D printer interfacing was pretty unproblematic, the moonraker example code was lightly modified to take G Code input in a thread-safe queue and it's stayed that way.

I also realised I had to buy a Raspberry Pi 5 since my old CM4's all had 8 GB of storage which just isn't enough for this kind of development work.

I went through a number of iterations of the lens+camera mount, 3D printers aren't really designed to take precision optics but I think I ended up with a pretty sensible mount that doesn't seem to move around too much.

Merging artifacts were an issue during this time that were caused by both misalignment of the sensor plane, and the cheap lens vignetting. Cropping the image helped with the cheap lens but the real fix was switching to the expensive EO lens. I think the bi-telecentric design is part of why it doesn't have field flatness issues with these sensors, since both should be vignette-free.

The merging software was started on 2026-03-22, the day after a 4 hour photo walk and 8 hour post-walk beer session (results: 1.5 rolls Double-X, 0.8 roll Tri-X, 0.5 roll Fuji 400, indeterminate beer amount, 1 midnight burger). It only took a few hours to get usable results, though tweaking of parameters went on for a few days after.

When I switched to using raw data from the camera (one thing the Pi 5 does better than Pi 4's, it always outputs left aligned 16 bit, the only rational way to supply 9-16 bit image data) I discovered the bayer pattern of the GS camera. Having previously ordered the HQ camera just in case I switched to this. I'd already prepped the code so switching to a new camera with different pixel geometry was relatively straight forward, an hour or two of tweaking.

With this kind of telecentric lens sensor dust tends to be pretty visible, especially if stopped down a bit. If blowing dust off isn't enough, I pull the C-mount off the camera board and stick some standard office tape on the sensor and pull it off slowly. This picks up most marks including fingerprints. I picked up that trick from an old telecom R&D engineer where they used to clean fiber optic connector ends that way before the purpose made products were available.

IR filter removal was harder than the documentation suggests, I can inform the reader that hitting the filter glass with a 300°C hot air gun will crack it in around 1 second. Heating the C-mount piece up to maybe 50-60°C made it possible to cleanly remove the glue as well, and a hand-vac was used to pick up all the fairly sharp glass shards.

Fine tuning monochrome

The last week of March 2026 was spent fine tuning the capture process and supporting aspects. I added the HDR-mode and implemented gamma correction, which required some iteration to give results that looked ok and were possible to work with later. This mode was successful enough that I now use it as the default, since the only downside is a straight export looks pretty flat without applying a tone curve.

Initially I used a gamma of 2 since floating point power functions are too slow for real-time preview, and square root and a power of 2 are relatively performant. After a while I switched to using a 16-bit LUT for real-time preview (less precise, around as fast as a floating point square root) and a pure power gamma of 2.4 for capture.

JSON outputs were added to provide "frame info" to the merger used in determining what files are there, how they're aligned, exposure parameters, type of scan etc.. A lot of the parameters are just formatted and put into the EXIF tags of the output image for posterity.

Since the CSI & DSI cables showed up I could mount the Pi and 5" display where the spool holder is meant to go on the printer. 50 cm long CSI cables seem to work fine, and the X-axis can traverse the entire width at minimum Z without snagging.

A nice heat sink for the Pi 5 with a big fan showed up, an instant 30°C temperature drop. Mounting the Pi 5 behind the screen severely degraded Wi-fi performance so I decided to run a fiber from my main switch and put a media converter into the final design.

Film mounts and backlight, round 1

The first week of April 2026 was spent getting a prototype film holder and backlight operational. In the same bag as the RPi HQ camera there were also two pieces of glass inside an extremely well padded box (shoutout to my AliExpress glass-store shipping department bros', you rule).

I set up a private Gitea-server, since I develop the capture software straight on the Pi 5 it was nice to have somewhere else to push to.

Since I had realised that I'd need to build a custom backlight controller to properly support colour scanning, I decided to initially use a set of monochrome LED strips. Green was the obvious choice for a monochrome scan, having twice the photodiodes per output pixel than the others.

A fairly immediate issue I noticed in the first test scans was the awful quality. After some testing I realised using green-only lighting with a pipeline tuned for white light meant my green channel was way overexposed since the RGB-Greyscale-RGB pipeline was giving me RGB averages values in greyscale. This meant when only the green was responding it would saturate quickly but the greyscale value would be at most 70-80% of max. I tested this by just underexposing the scan a lot and it looked fine again, it's a simple fix: just use the channel corresponding to the backlight colour and ignore the rest.

The backlight prototype had a lot of vignetting due to simply not being big enough, but I was able to get a couple of scans of the last roll I'd shot. Stacking more diffusor plates and increasing the LED-diffusor distance to 100 mm helped a fair bit. As part of this process I also added support for frame-indexing to X/Y positions corresponding to negative frames, and worked out that for 6-long strips my Y-axis margin was technically -10 mm, though in practice I had 5 mm to spare.

Above is a comparison of a lightly processed scan vs. a "final" V850 scan at 3200 dpi, I think the difference makes it fairly clear why I wanted a better scanner.

After scanning a couple of fresh rolls by moving an old LED-panel around to get the illumination reasonably flat, I implemented a template based automatic sprocket hole finder to make auto-exposing faster. I was doing it for basically every frame so this was worthwhile.  Over 3 rolls with straight glass I encountered a few cases of newton rings during this round, and I suspect my film/sensor planes weren't fully aligned.

Flat field correction, round 1

The above image suggests that the lower right corner of each sub-frame is darker than the rest. I ruled out reflections by temporarily mounting a polariser on the lens, figuring that e.g. a bounce off the sensor/lens, back to the glass then in again would probably be affected.

After a bit of testing I determined that this effect gets worse with increasing f-number so leaving the lens wide open helps. I spent an embarrassing amount of time trying to invent flat field correction from first principles before I just implemented the Wikipedia formula, which worked. I decided to capture a separate flat field for the long-exposure HDR merge capture, since this uses a different analogue gain.

Below is the result of doing a flat field correction with separate HDR, but using a shorter integration time for the high-gain capture to avoid needing an attenuator.

Same shot using an attenuator (film-leader) for the high-gain HDR flat field:

The capture-highlight side of the correction works quite well:

I also ordered a tube-style shade for the EO lens, just in case stray light was causing these effects. I don't believe this is the case but using a hood can't exactly hurt either. Future work is to e.g. attenuate the backlight using the backlight controller to make it faster to update the flat field.

While waiting for the backlight components below I made a start on the report generator code, which initially was an HTML output that I figured I'd print through WebKit. CSS is a very capable way of describing a page layout, and you can do incredible things with it. Later I rewrote the output to be LaTeX format since this is a simpler way of making a PDF with somewhat predictable behaviour.

Later I also optimised the display output to improve performance by e.g. only doing gamma-correction on data going to the display instead of at full resolution. Turns out the M2 Mac I use is pretty fast at floating point gamma.

Planning a better backlight

Making a good backlight that would fit inside the printer area was challenging. After the initial diffusor + LED-strip concept proved too uneven I reassessed.

I decided to order the following, hoping it would let me solve the problem:

• PE thin diffusor film (30 cm by 3 meters of it, type no. LGT125J)
  • To hopefully provide more diffusion than the acrylic plates I started with
• A couple of A4 size fresnel-lens panels
  • Hoping to improve efficiency, letting me stack more diffusors
• A set of 50 W RGB-LED and 10 W 850 nm LED modules
  • Hard to drive, probably a mistake
• A set of 8x32 WS2812B flexible LED panels (these are also around 8 x 32 cm)
  • While adding IR would be challenging, by using a pixel-grid array I could reduce power consumption by a lot by only lighting up the area under the current frame.
  • IR could be added by making a set of thin panels that fill the gaps between the RGB LED's
  • Using these in on/off mode should avoid PWM-flicker issues; I figured I could adjust the density of on/off pixels to improve backlight uniformity
  • Also gave me a use case for one of several mil-spec isolated 28 to 5 V at 15-20 A modules I had sitting around waiting for a use case.
  • A Pi Pico module would work as the USB-bridge to let me drive the backlight from my capture program.

A challenge with this setup was achieving good uniformity along the X-axis, since I could only go 8 mm out from the bed before hitting the X/Z posts. Along the Y axis margins were plenty. A fairly simple fix is to just move the film strips closer to the centre. I had initially spaced the 35 mm strips out a fair bit, but since I could only fit 3 anyway there was no reason to spread them out as much as I was doing.

I did some modelling of the printer Y-carriage and made the frame setup shown above. This uses a set of base-plates that bolt on to the carriage and extend past the scanner area, a set of L-brackets that hold the glass are mounted on these plates. A set of 4 mm steel rods are used to make the L-pieces self-supporting.

The L-pieces have a set of M3 holes in them to make it practical to install diffusor and fresnel panels, the nominal build height is 130 mm up to the film.

An old box-lid was cut down to form the backlight base-plate. On the underside a DE-9 connector block and a thickened riveted section is installed to allow mounting of the DC/DC converter and Pi Pico for control. The RGB-panels have connection points on the bottom, so a set of holes will be drilled to access these from the bottom.

A better backlight

Upon receipt of the backlight panels I installed them, a process that took a couple of hours to get all the wiring in place. Did I mention these panels need a lot of current?

On annoyance with the panels is that they go in a zig-zag configuration, and to make the wiring easier I installed one backwards. A lot of messing around to make that code work…

Actually getting the panels to work was really easy though, I used Circuitpython on the Pi Pico and enabled the data USB endpoint to receive and transmit display commands without the REPL stuff interfering. My capture program sends an ASCII string, where the value is a simple bitmap of bitfields corresponding to R/G/B on/off. The Pico works out the details of what order the actual pixels go in.

To generate the backlight image, I get the X/Y position of the camera whenever something changes. I make an image with 1 mm pitch (320x240; pixels are 10 mm spaced), and draw an ellipse centred on the camera position, sized to be ~4⨉ larger than the image field of view (larger lit up area = more light, due to the diffusor). The image is then blurred, thresholded, decimated to the actual LED grid pitch, and sent to the Pico. Once the entire backlight image has been uploaded the Pico sends back an acknowledge to allow blocking calls.

The Pico has a 30 second timeout to ensure the backlight won't stay on forever, the capture program refreshes the last configured backlight image slightly faster than this ensuring it won't go off during capture.

To support colour preview I extended a number of functions such as AE to calculate a set of R/G/B exposure times, capture was extended to capture R/G/B if configured, and the preview mode was extended to support approximate colour balance in white light mode (since previewing R/G/B sequential would be too slow and annoying).

I also discovered that despite working in R/G/B order in most of my software I had a couple of bugs: using the red channel when illuminating blue led to some very long exposure times. The display output was also done in RGB but the bitmap output is natively BGR so some conversion had to happen there.

Milestone: first colour image!

Presented for your viewing pleasure is the first colour image I scanned, it was selected randomly from the last roll of colour I shot before starting this project. It's scanned with white light, with no cover-glass, in the storage foil, with no concept of colour management. It still outperforms the V850! Highlight retention is significantly better, which was a major issue with this roll.

Since the WS2812B "NeoPixel"'s "white" output is quite blue the white light mode isn't too far off from the mix you'd want to counter an orange based negative.

Another comparison from the same roll, this time using field-sequential mode with auto-adjusted colour balance:

Obviously these Vision3 250D frames are pretty flat and "raw" so finding how to best work with them will require some experimenting.

End of colour-honeymoon, even flatter fields

Up until this point I had targeted sequential colour capture, but after testing it out I found that since my exposure times were in the hundreds of ms anyway my PWM-flicker concerns were irrelevant. As such I reworked my system to PWM-control the backlight to white-balance off the rebate area, and to grab direct captures. After a bit of tweaking the achieved white-balance is quite good, giving reasonable colours right out of the scanner.

I also wired the backlight power supply in to the heater PWM output, I had to reconfigure the Klipper configuration since heater outputs have hard-coded self-check features (a good idea, but in the way here). Fortunately you can configure "generic" outputs and sensor inputs that are still easy to control.

This does add a slight colour error due to crosstalk between the different colour channels, but since I expected to use an IT8 target for calibration anyway this would be compensated later.

I ran into some weird colour patchiness that was hard to track down, it was entirely deterministic for a given setup and seemed somewhat related to whether the sprocket holes were in frame. Scanning through the foils seemed to make this issue more apparent but going to normal glass didn't entirely remove it. Curiously the issue seemed to follow the frame, so one possibility is some automatic adjustment in the camera I haven't managed to disable.

I ended up removing the lens hood since it seemed to make no difference whatsoever. I also reworked the flat field correction to actively use the backlight control system, and I was able to stop down to f⁄10 again for slightly improved sharpness.

I verified that the flat field performance seemed to be unaffected by the glass plates, so the easy way to do a flat field is to pull them and look straight at the diffusor.

While thinking about these issues I added a couple of other nice-to-haves that will be useful to make batch scanning possible:

• Using the sprocket-hole detector to automatically align the Y-axis when at the starting area for a new frame — a useful feature to have if negatives aren't perfectly aligned (X-alignment is less critical and harder to do)
• A simple exposure-ok check based on the sprocket detector having found a match + the AE area having an acceptable exposure.
• Slightly modified the merging software to run on my old home server instead of my poor M2 Mini
  • It ran perfectly well but the RAM usage in particular made itself felt when multitasking
• Since my home server is kind of meh, made the merging software multithreaded and made sure as much processing as practical was done in threaded form (e.g. doing gamma conversion on each sub-frame instead of at the end, converting to greyscale as soon as possible etc.).
  • Net result: around 30 seconds per 35 mm frame, on a 12 year old Xeon
• Since these files are around 300 MB per 35 mm frame before any processing, I started a side project to upgrade my home network to 10 Gbit⁄s. This was long overdue, obviously I did have some 10 Gbit⁄s gear already but SFP+-only 10GbE switches are now quite affordable. 10 Gbit/s uplink to 2.5GBASE-T switches are also quite affordable.

Later, I started looking more into the magical tuning JSON file that's loaded on every startup. I swapped to the stock _scientific.json file and started chewing on wires, leaving nothing but the lux-estimator (since it complains without it), DPC-disable, and the basic auto-exposure definition since it apparently can't set analogue gain without it. Notable removed or disabled features included: dead pixel correction, automatic lens-shading, colour correction matrix, automatic white-balance, green-equalisation, any kind of noise reduction, and sharpening. I repeated my flat-field correction after each change.

I did notice that some residual flat field error now showed up, so I implemented a third flat field correction that is applied to the merged HDR-image instead of just to the individual components. This flat field image ended up slightly countering the previous two wrt. lens shading though at fairly low magnitude, suggesting some residual error was present (if the other two were perfect the flat field shouldn't have any texture). A direct comparison is shown below.

If you're wondering: the colour balance being different was caused by the second flat field causing an RGB balance shift which would only show up in final captures and not preview modes. To avoid this I normalise the RGB-gain individually (which may negatively affect the correction…)

A residual error that might be a lens limitation is where large parts of the image are heavily saturated, such as this edge where the backlight is visible due to an oversized mask:

These frames are slightly shifted towards orange after inversion which seems to make sense as a purely optical crosstalk since this is the colour of the backlight. I tried disabling the black-level clamping but this made no difference.

As shown above blocking the light seems to fix the issue and it's repeatable between different sensors, but this does point to a limitation of this type of system. It also seems to imply that including sprocket holes in the scan may be detrimental, though I haven't really seen any clear indications that this actually causes issues.

As it stands, using a more precisely made mask and ensuring that the mask blocks most of the light seems to be sufficient. In cases where backlight-exposure will happen, any kind of light-proof mask can just be placed on top of the top glass as shown above to resolve it.

Charting a path to greatness

After these last tests, I started evaluating what options were available. As mentioned I upgraded my home network to 10 Gbit⁄s and as part of the acquisition process I ended up with one more computer than I needed. Starting from here, I started re-evaluating the whole system and—saving you a lot of words—ended up switching to my Python1300 global shutter camera using GigE-Vision. This camera isn't as good in most aspects but there a lot of GigE cameras available with optimal sensors.

This marks the end of this article, as I feel the Mk. II system using higher end components deserves a separate article.

My future upgrade path involves a CobaltTL™ lens with higher optical performance (though less available on the second-hand market), 10 Gbit⁄s GigE-Vision cameras, and probably the same 3D printer chassis.

The 3D printer wasn't the optimal choice for performance, though it was extremely affordable. A Core-XY machine or gantry-style CNC router would make a more sensible base, moving the entire light-box and film assembly isn't the best solution for speed.

A different style of writing than most previous posts, I try to decipher why digital cameras didn't show up before they did, what forces made them appear, and just for fun: a look at what electronic cameras could have looked like in 1980.

This article is essentially a "well actually" to the completely unfounded idea that "Kodak had a digital camera in 1975 and chose not to make it because they wanted to sell film". This is of course untrue, like most other anecdotes are when you look into them. Ruin the joke with this one weird trick (knowledge).

Do note that I consider electronic cameras to be a better definition for this purpose, specifically we know that digital stills cameras didn't show up until the early 90's but electronic cameras were around in the 1930's as analog video cameras.

Executive executive summary

Internet. Computer.

Executive summary

They existed before this but they really started becoming popular in 1995-2000. This happened because the Internet suddenly created a consumer use case for poor quality low resolution images that didn't previously exist. Further, consumer grade colour printers started to show up making home printing of images onto copy paper a thing.

Over the next decade or so the same technological advancements led to rapid improvements to image sensors and by 2002 or so they were good enough for most purposes assuming you had $10,000 to drop on a camera.

Background

So film cameras were a thing since photography existed, assuming you count glass plates as film. By 1900 or so film in a recognisable form was moderately well developed and starting to become a consumer item.

Performance was limited compared to modern film, but just making the negative bigger made up for this for professional use where cost was less important. We saw a general trend in the 60's from medium format roll-film to 35 mm cassette format film for most consumers as film quality improved, lowering cost and expanding the market.

During the 1980's autofocus point & shoots were made practical by miniature xenon flash-bulbs and newly invented T-grain based high speed colour films.

Disposable cameras started showing up around that time as well, and were still relevant until the early 2000's.

APS showed up in 1996 and was fairly popular among consumers around 2000-2002, but was very much a product that showed up 20 years later than it should have.

Electronic imaging & Vidicons

Electronic cameras didn't really become a thing until the 1950's or 1960's when television rose to prominence. These cameras initially used a variety of variously terrible camera tubes, but ended up settling on the Vidicon and various other variants by the late 60's.

These Vidicons were in theory capable of decent resolution, but were in part hampered by the ever present 1930's reaffirmed in the 50's decision that "480 lines ought to be good enough for everyone". I doubt the creators of television expected their "Standard Definition" format would last well into the 2010's or they might have allocated a bit more bandwidth. Since the only real use case for imaging tubes was TV, there wasn't much need for higher resolution models.

For a long time zoom lenses were only available for TV cameras, not for cost reasons but simply because they were the only market with standards low enough to put up with the abysmal quality of pre-computer optimised zoom lenses. For photographers zoom lenses didn't reach acceptable quality until the late 1980's.

Vidicons seem to have been somewhat susceptible to microphony, where horizontal bands appear in the image when exposed to high vibration or sound pressures. This is quite noticeable in the UK portion of the Live Aid recordings, for example.

CCD's

During the 1980's Vidicons were gradually replaced with CCD sensors, a now classic technology that didn't really die until the late 2000's. Typically a 3CCD sensor was used, where a beam splitter divided the image by colour onto red green and blue sensitive CCD's. This let broadcast grade cameras output up to 4:4:4 video in principle, which is useful for chroma keying. The CCD was a staple of prosumer "portable" video cameras by the late 1980's, sometimes 3CCD and sometimes with RGB colour dye filters.

Bayer patterns were also used in the 80's (invented 1976); I expect that performing de-bayering in mostly analog circuity presented a bit of a challenge as it usually requires some kind of memory to perform the 2-D colour matrix operations. This was likely done using clever tricks in the CCD readout circuitry.

Fun fact: CCD's are a sort of hybrid of analog and digital with discrete pixels but distinctly analog signal chain; a CCD can be configured to output an analog video signal more or less directly for this reason. You can also store an image in there for some (short) time as it works like an analog shift register, all CCD's had electronic global shutters.

Why not an electronic camera?

The idea of replacing photographic film with a video camera still is basically canonical (meaning: it's an obvious thing to do). This seems like a great idea until you start looking into what the performance figures are for even low quality film vs. what a broadcast grade video camera could do. I'll refer to pixels here even though pixels don't technically exist in analog TV; lines are a thing though so the vertical resolution of TV is knowable. Unless you include the temporal aspect of moving objects with natively interlaced sensors.

Resolution

A bad quality 35 mm film frame from a modern disposable camera has a usable resolution somewhere around 3-10 megapixels, and a good film and camera combo can probably be expected to give you 20 megapixels (I usually scan colour film at ~10-15 mp/3200 dpi).

Your broadcast TV camera generates something like 768⨉494/752⨉582 pixels, or somewhere around 0.3 megapixels. CCD's technically had more pixels (e.g. 811⨉508 & 795⨉596) but they were masked from external light and mostly acted as black level reference pixels.

At full print quality (300 dpi) this corresponds to something like 5x4 cm, making enlargements bigger than this would yield a noticeably soft image.

Do also note a peculiarity of video vs. a still image camera: digitally sampling a TV CCD to make a still image would result in a somewhat sharper image than an equivalent video-processed signal from the same sensor. This happens since while the CCD can output discrete pixels in time with a pixel clock, analog video is a continuous time process where the video has to be low pass filtered to around 4-5 MHz to fit into a broadcast TV channel's bandwidth. This has the effect of smoothing out the otherwise sharp pixels from a CCD, blurring the image horizontally. Turning it into composite  color—compatible colour—often leads to further losses of sharpness unless fairly sophisticated comb filters are used to separate the luma and chroma components. Video signals are usually sharpened to improve subjective sharpness (a basic "treble" filter), leading to bright/dark edge effects clearly visible in the gullcam around the coax lines.

Vidicon type imaging tubes can be made in several different ways, and sharpness depends on the "target" design (the front face), RCA made Vidicons with the imaging area made from discrete silicon photo-diodes acting more or less as pixels (used by the Lunar Rover's ground controlled TV camera) with resolution figures matching later broadcast grade standard Vidicons.

This is a funny sort of hybrid approach since the fundamental operating principle is at a surface level even more similar to much later CCD or CMOS sensors than a normal Vidicon: an array of silicon photodiodes convert photons to electrons and store it in a "bucket" capacitor; periodically the bucket is drained (by the electron beam, in the Vidicon case) and the amount of charge corresponds to the image. Of course the normal lead-oxide Vidicon (Plumbicon) also does more or less the same, storing charge on the surface of the lead oxide target.

For an example of this see RCA AN-4623. Readout of discrete sharp pixels would require very precise control of the electron beam however.

A much newer Hamamatsu Vidicon catalog lists silicon target tubes separately and the specifications for resolution are around half that of the unspecified type used otherwise—presumably lead-oxide—though they do have reduced ghosting and higher sensitivity.

I suspect silicon target Vidicons were mostly used for scientific and industrial applications. One of their key benefits was good near-IR sensitivity out to beyond 1000 nm; this would for example be useful for many military applications such as imaging Nd:YAG laser beams. Alternate photocathode materials were used to support X-ray, UV, and SWIR wavelengths: old Vidicons remain the only somewhat economical way of viewing 1-3 µm wavelengths today.

Smaller Vidicons have a spatial resolution figures fairly similar to modern film stocks, but the size is significantly smaller in standard models. This shouldn't come as a big surprise since the pixel pitch of a 1⁄3" TV CCD is only slightly larger than a modern CMOS sensor pixel.

Incidentally, the size of sub APS-C sensors is often listed as fractional inches and this is a carryover from the Vidicon days, the listed size is the outer diameter of the tube assembly, with the active area being a fair bit smaller. 

Dynamic range

Another issue: the dynamic range or "latitude" of a film negative is quite high, often exceeding 10-12 stops (ratio of exposure of 1000-4000⨉) and good slide films sit happily around 8 stops. A stop is a doubling of light, and is basically analogous to bits in a linear light system (no gamma).

A Hamamatsu 8134 is a relatively late period Vidicon, operated in high dynamic range mode it has a dark current of around 5 nA and a peak listed signal current of 350 nA, indicating a dynamic range of around 70⨉ or 36 dB. I'm not sure if gamma correction should be applied to this number, if so it would be higher, but 30 dB SNR was as far as I know considered to be good enough for broadcast television over the air. RCA catalogs for the previously mentioned silicon target Vidicon indicates 100:1 dynamic range is possible, but they also say the noise is so nice to look at that it really deserves even higher numbers.

The XC-75CE is a late 80's 1⁄2" 9 µm pixel pitch monochrome technical camera that listed a maximum SNR of around 56 dB, but what we actually have to look at is the ratio of maximum optical signal to minimum optical signal. Taking the specifications at their word with gamma on the minimum intensity is 3 lx for an IR-cut monochrome image, and peak sensitivity is 400 lx giving a ratio of 133⨉ or around 42 dB.

Kodak 5279 "VISION" film in 1996 was listed with a guaranteed dynamic range of roughly 10 stops of exposure which equates to a ratio of around 1000⨉ (60 dB), though the "usable" range of the VISION film will be a fair bit higher since a CCD sensor will clip highlights (sometimes leading to charge leaking outside of the storage capacitor, resulting in white vertical stripes in the image) whereas a negative film will progressively compress the highlights (soft clipping). Further, the D-max of the film isn't really specified so the true maximum is not directly readable from the datasheet.

Modern day Tri-X black and white film seems to have a D-max of around 3.0, and extrapolating a low-contrast development to D-max of 2.0 suggests the dynamic range could be as high as 90 dB (15 stops) though the images would probably be hard to work with.

The sensitivity of a video camera is unfair to directly compare to stills cameras, but suffice to say that sensitivity⨉resolution was typically far better for black and white film than any practical electronic camera made before the 2000's.

We've covered some major downsides to old electronic video cameras compared to film, it's also fair to mention that the cost of these sophisticated broadcast grade cameras likely exceeded the yearly income of most middle class families throughout most of the 70's. Meanwhile film had cheap cameras available for a long time (Brownies and Instamatics barely had anything inside them) and benefited from massive economies of scale, well within reach of most middle class families from the 1930's onward. A given camera could also within reason be upgraded by buying new better film and in some cases better lenses.

What do?

So for sensor you have two choices really. It's the 60's or 70's: you will use a Vidicon tube, maybe an RCA silicon intensified target tube. You'd need to make specialty tubes with ~4-8⨉ the resolution of standard video tubes and you'd need three of them to get colour. It seems likely that existing tubes could be used in a slow-scan mode to give finer resolution.

Dynamic range would be limited compared to film, but as we saw with e.g. the Voyager probes this would certainly be possible to do. You could use a photo-multiplier tube and spot-scanner but that would be even more complex, but could achieve great sensitivity.

It's the 80's: if you can see the future you'd develop a giant CCD. It could probably outperform the Vidicon for sharpness, you'd probably want three of them with a beam splitter for colour. These would also need to be huge compared to TV types to pack enough pixels, so yield would be low, cost would be significant, and power consumption would be fairly high during operation.

According to Wikipedia's sources the Japanese 1035i MUSE HDTV used high resolution Vidicons cameras up to at least 1993 due to their still higher performance. Existing and well-understood Vidicon technology could probably be more easily coaxed to output a reasonable HD signal than comparably immature CCD's where the maximum resolution is finite. The famous 1993 New York HDTV demo footage that reappeared a few years ago is believed to have been shot on a Sony HDC-100 or later HDC-300, both were 3-Saticon tube (SeAsTe, S-A-T) cameras first introduced in the mid 1980's. These were likely replaced by the Sony HDC-500 shortly thereafter; this is apparently the first CCD HDTV camera though details seem scarce. While significantly better than SDTV the 1993 footage is considerably softer than 2000's HDTV systems and the limited dynamic range is very visible here as well.

In 1995 the Minolta RD-175 used what I think is a fairly unique solution to the resolution problem. Presumably lacking access to their own CCD fabrication line they used a complex optical system to split the image onto 3 video-grade CCD's as usual. However, they used one of the CCD's to record red/blue at low resolution, then they used two green sensors diagonally offset to give a double resolution green image. Extensive and time consuming at the time off-board digital processing was then required to interpolate up a 1.8 mp output image (they made the image from 3⨉0.3 mp, so some "cheating" was involved as usual).

Using a video CCD with an alternate colour filter arrangement was likely a significant cost savings vs. commissioning a fully custom CCD layout. I wonder if they might not have had an easier go at it if they had split the image into 3-4 equal images and put in some standard bayer pattern CCD's instead.

Meanwhile in 1995 Kodak had released their first 6 mp sensor in a camera costing only $35,600, at a 9 µm pixel pitch this seemed to be a bit of a resolution wall for Kodak that they didn't really exceed until 2009's Leica M9 at 6.8 µm pitch—6.5-6.8 µm pitch is about the size used for 1⁄3" standard definition CCD's since the 80's by the way. I expect that massive improvements were made to cost, dynamic range, and sensitivity in this time period however.

The size of pixels isn't so much a sign of quality as it is a fact of physics that if you want a pixel to sharply resolve something then it has to be at least a couple of wavelengths long, which seems to put a practical limit at around 4 µm in most cases. Smaller pixels than this presumably require very complex designs and probably post processing to compensate for the diffraction limited resolution they must have and I suspect this is part of why they don't start shrinking to this size until the 2010's.

The storage-problem

So let's for argument's sake say that we bump up the resolution of these electronic cameras enough to make a decent sized print. This is after all merely an engineering problem if you ignore yield: just make the sensor bigger/electron beam focus finer and add more silicon target diodes in the case of a Vidicon.

Where to store it? Well, tape obviously. Tape showed up in the 60's for video, and by the mid 70's there was a boon of professional and home video tape recorders; clearly there was a huge demand. It's fairly obvious that you could use a tape that can store hours of 50-60 fps interlaced video to store a couple of higher resolution still images instead.

Keep in mind a general rule I've observed: storing or transmitting any kind of uncompressed digital signal onto/via a fundamentally analog medium usually requires a massive increase in bandwidth. See for example analog composite video vs. the equivalent SDI bitstream. A full TV signal with stereo sound requires around 6-8 MHz of RF bandwidth, an SDI bitstream runs at over 100 Mbit/s to do fundamentally the same thing. Analog voice needs 3 kHz of bandwidth for phone quality audio, digitally it needs minimum 64 kbit/s.

Digital is harder to store for this reason, storing everything as ones and zeroes with sharp transitions turns out to be a very inefficient use of bandwidth in an analog medium. Packing digital tighter requires very powerful signal processing (see e.g. OFDM/QAM) and/or computationally expensive lossy compression schemes in the case of audio and video.

For most of this time period it would make most sense to store an electronic image as an analog video signal, this requires far fewer transistors to implement than anything digital. Kodak's famous 1975 digital camera stored the 100x100 pixel image digitally at a measly 6 bits per pixel and it took 23 seconds to write it out to tape, during this time the image had to live in hideously expensive RAM chips. It is said this project was so secret only a handful knew about it, I'd say it's equally likely the invention had so little utility at the time that only a handful saw the potential.

If this Kodak digital camera were storing the image in analog form it would have taken less than 1⁄60th of a second to store it with resolution to spare on any readily available video tape recorder, but this wouldn't make for a good story since it would just be a terrible video camcorder instead of a digital camera. Indeed, the only real difference between a CCD digital stills camera and a CCD video camera is the digital storage medium.

Digital tape

Generally available digital tape storage for audio showed a while after the CD in the form of DAT (basically a modified miniature VHS tape recorder for CD-quality audio, released in 1987), but it took until 1995 with DV before a consumer digital video format was invented. DV tape is impressive, but by 1995 it was also clear that flash storage would be the big new thing and dealing with tape is horrible. In 1995 we're also approaching critical mass of early digital cameras, so I doubt DV was ever seriously considered as a way of storing high resolution stills in real-time.

Digital compression?

Do keep in mind also that JPEG wasn't standardised until 1992 though products made use of it as early as 1990; JPEG was made practical as a consequence of computers becoming fast enough to make use of the fairly impressive compression it can achieve.

Before this you'd need much more digital storage for similar quality images; in the early 90's there was a brief market for JPEG accelerator cards for computers since general purpose pre-SIMD processors didn't find it particularly easy to do quickly.

One prominent example of this is C-Cube Microsystems CL550 and CL560 launched ca. 1990 (the head engineers were JPEG committee members). Per their chip datasheets the enhanced CL560 can JPEG compress full RGB colour images at up to 15 megapixels per second using a 35 MHz heavily pipelined processing core. This was sufficient to perform real-time JPEG compression of standard definition video (JPEG for motion) and was used in some of Avid's early non-linear video editing products. Other cards were intended to make Photoshop and similar programs save files faster.

What do?

What are your options? So in the 60's you'd call Ampex who would laugh at the idea of making even a man-portable recorder capable of storing your still image signal. By the early 70's you could probably make it work as long as you were content to wheel it around. You could perhaps use a satellite uplink to live-broadcast your images to a mainframe somewhere, the satellite uplink truck would be more convenient since you could live in it after selling your mansion to afford the camera.

By the 80's you definitely could make a somewhat portable recorder capable of putting an analog still image onto tape, assuming you uprated something like a Betacam recorder and had a CCD that could keep the image in the charge domain long enough to avoid needing a bunch of RAM. In fact they did make this sort of thing, floppy discs were a thing for computers for a long time but these early cameras were TV-quality CCD's storing a single analog video frame at a time instead of digital data on a floppy. It was called a "still video floppy." These had nowhere near good enough quality for any real purpose at that time and don't seem to have achieved much.

By ca. 1990 you could fit enough RAM into a device to store a digital copy of the image, and you could in principle use JPEG to compress it. Storing an analog high def still image would be quite feasible as well, though no one seems to have tried it outside of the early 90's push for HD TV that didn't go anywhere.

In practice we saw the first digital floppy-storing TV or sub-TV quality digital stills cameras, as well as e.g. the Kodak DCS 100 which used a hard drive to store a digital image at over 1 (real, not interpolated) megapixels. That camera and some later models were mainly used by entities like NASA for Space Shuttle missions, where sharing a high resolution image with the ground was a huge improvement over video links; 1980's shuttle missions had approximately as good of a video link as the moon landings did.

This was followed by a wide array of increasingly powerful CCD based hybrids and later dedicated digital cameras. I thought Kodak killed digital to save film, why did they lead the charge into digital cameras?

If you're wondering: the CCD division's last great successailure was the Leica M9 sensor which famously started falling apart after a few years leading to a major recall. The division was later sold to onSemi who closed it in 2019, though they still make competent industrial CMOS sensors.

Also for fun: the easiest way to record an electronic image in any of these time periods would be to use a flying spot scanner to expose a piece of film that you then develop later. This was a real practical way to record certain scientific images as late as the early 90's. It would only take a small leap to go from this to just putting this film in the focal plane of a camera and you're back to square one.

WTF do you do with an electronic image?

So the elephant in the room is that yeah sure you could make an electronic stills camera even in 1970 if you had to. Now what? You're not e-mailing it to anyone are you.

The only practical way to view an image was over a standard TV screen (bad quality), CRT projector (could be better than a TV), an eidophor (if you work for NASA), a print (great quality) or as a slide (great quality). Digital picture frames were still 40 years out and it would be at least 50 years before they had acceptable image quality.

Instant review of an image would invariable involve a CRT until the 80's, LCD's weren't really good enough until the 90's at the earliest and in my opinion it took until the 2010's for portable LCD's to really look acceptable. Plasma displays existed but were basically monochrome.

Printing an electronic image onto paper or reversal film would certainly be possible, but at that point you do need to ask why you didn't just get a point & shoot with some film in it.

I've argued in favour of analog recording previously, but to do any sort of editing you couldn't already do in the darkroom printing process you would essentially need to make the image digital and put it into a computer. The problem is that RAM was so expensive until the 90's that storing even full quality TV stills was a huge undertaking.

What do?

So in the 60's and 70's you're not doing anything other than projecting or printing an image; there simply isn't consumer technology suitable for anything else. Of course it would be possible to make a computer capable of editing a megapixel image digitally in 1970, it's just that you'd need a city block's worth of space to keep it in.

In principle you could probably make special TV's to display the image but printing would effectively still be a film-process with RA-4 colour paper or telecineing it onto a slide. Digital image editing is impossible by most standards.

By the 1980's you could perhaps start to imagine our current future, but telecommunications and computers weren't good enough to store transmit or display even very low resolution pictures at a consumer accessible price.

By the 90's you had computers that could fit on a desk that could in fact start to be useful with colour displays, as well as colour printers capable of printing images. Coincidentally you also had digital cameras at the same time.

So why did the digital camera show up when it did?

As mentioned initially I believe the internet and general availability of computers with moderately high resolution screens and fast processors was a massive driving force.

By 1992-93 or so many people (workers, at large companies) had access to high colour depth moderately high resolution displays on their computers (assuming they had a Mac IIfx with $10,000+ worth of accessories). There was enough ram to actually buffer up an entire screen's worth of image, and the processors had become fast enough to do useful image editing. By 1995 the situation was much more democratised, with Windows 95 capable computers (and PowerMacs) generally also being capable of showing megapixel images and low resolution video. You'd definitely want a lot of RAM in there but it was possible if you were patient.

Further, advances in the 80's in computerised printing had led to general availability of colour printers capable of acceptable results; it was then possible to make your own prints of low quality and moderate cost.

These same advancements in semiconductor manufacturing made it simultaneously possible to make computers powerful enough to work with >1 mp images, made it possible to process and buffer these images in a camera and store them, and presumably also made it more feasible to make higher resolution CCD's with acceptable yield.

By 1995 the internet was a thing everyone was excited for, and this seems to coincide with mass marketing of more consumer priced variants of the tech that mostly existed as early as 1986 with analog still video cameras. These cameras were initially basically all made with TV-grade CCD's, some kind of slightly inappropriate storage device, some even had JPEG compression to let you fit more than one image per floppy.

The reason seems obvious in highsight: it's exciting new tech, review your images instantly, and most importantly: e-mail them to friends! The limited telecommunications bandwidth of the time necessarily made it impractical to share good quality images but the low low image quality of a TV CCD is fine to downscale, compress, and send over dial-up. At around the same time journalism started their first steps onto the information superhighway, and these postage stamp sized images were about the right size for the early internet news sites.

I believe this huge interest in these low image quality cameras then drove CCD manufacturers to start serious work on high resolution CCD's instead of only catering to video cameras and NRO surveillance satellites. By 1996-1998 or so multi-megapixel cameras were available for professionals who presumably only used them to shoot sports for quick turnaround but film's fate was sealed as progress accelerated rapidly from there.

The storage problem wasn't really solved until the late 90's to my mind with flash storage for small to medium amounts of images, and e.g. microdrives for larger amounts for professional use.

These days when looking at image archives there is a hugely noticeable drop in image quality in the 1998-2004 period when most snapshots and childhood pictures were rapidly transitioned off film and onto consumer digital cameras. This reduction in technical quality would have been obvious even then, but it does indicate that while film held a very real quality edge until probably 2002 at the earliest (See EOS 1Ds, which roughly matches 35 mm Ektachrome in many quality aspects) and probably more like 2010 for lower cost cameras, your average consumer was very interested in getting away from film and the (at least perceived) high cost per frame.

I'd wager the amount of images taken rose rapidly in this period, and further I'd guess the number of usable pictures taken probably also rose since your average joe plumber could take 10 shots instead of one or two of the same scene and just keep the one good frame.

Film fights back

In the early mid 90's Kodak spent a fortune developing and marketing APS cameras, which were honestly pretty cool for consumers. The new cassette was much more user friendly than the 35 mm ones, the subminiature format wasn't that much smaller and made perfect sense for consumer grade cameras.

If they had introduced APS in 1986 instead of 1996 it could have owned the market. APS and stiff competition in the early 2000's for CCD's and CMOS image sensors is probably what killed off Kodak in my opinion.

However, during the 80's and 90's the biggest advancements I can think of are T-Grain films with much higher sensitivity and finer grain, and compact mini labs that can very rapidly turn negatives into prints at low cost. This change also led to a shift in consumer film usage away from primarily reversal (slide) film for projection and to more flexible negative film.

These days we also enjoy instant review of images on screens; this was a major benefit to even early digital cameras. This market was served by Polaroid and similar technologies, though the technical performance was much worse than standard film.

How could you make digital cameras in 1980?

The easiest way to accomplish this would be to retroactively change the calendar, making 1995 actually be 1980 now.

In 1980 most of the high level technology needed to make a digital camera make sense had been invented and could have been put together if an infinite amount of resources and money could be poured at the problem.

To make a digital camera itself you need:

• Image-sensor: the CCD was invented, in theory you could make one with sufficient resolution if your life depended on it.
  • Assume 1.2 megapixel is possible, a 4⨉ bump in pixel count vs. a TV sensor
• Video-ADC to make the digital copy of the video from the CCD: technically quite possible, but very expensive and power hungry if it also had to be fast
• RAM to store the digital image: sure, but needs a lot of space and power if you want all of the image stored at once
• Man-portable storage media: you'd probably start with a VHS or similar video tape recorder. Alternately a hard drive could be made to work.
  • Hard drives capable of storing more than one image were typically mounted in 19" racks at the time
• Ideally you'd want image compression: not sure what the state of the art was in 1980, but the ASIC to do some compression would probably be fairly compact next to all the RAM to store the image.
  • In the mid 80's semi-digital video compression systems like the Japanese MUSE system and EBU's later MAC systems were doing relatively sophisticated digital processing on live video to try to enhance the image quality of the 30's and 50's designs of analog TV
  • These systems were basically failures, though MUSE gets credit for being basically HD TV 20 years before widespread consumer availability in the rest of the world while no one has ever heard of EBU MAC
• Viewfinder to review the image: not strictly required but a high-ish resolution CRT would be quite possible to manufacture, see e.g. the Sony Watchman. An SLR-design wouldn't require an electronic viewfinder.
  • Designs for TV use would use an electron beam large enough to avoid visible spacing between the lines; a CRT is basically a special case of an electron microscope and so the capability to create very high resolution monochrome screens existed for a long time.
  • High resolution colour monitors would present more of a challenge since shadow mask TV's were all awful and would require a very very fine mask, eliminating most of the light output.
  • A colour sequential system using a DLP-type colour wheel in the optical path seems like it could be the easiest way to achieve a small high resolution compact color CRT.

This all seems like you could have made it, it would probably be much easier in 1985 vs. 1980 but still doable. It would involve a backpack full of electronics to make it happen, and it would undoubtedly have very poor sensitivity and dynamic range vs. any negative film of the era. Do keep in mind that in 1980 the IBM PC and analog walkie talkies with barely enough processing power to do automatic channel switching (pre-digital mobile phones like NMT-450) were considered to be state of the art.

Here's the fun part, what do you do with the image?

• Long term storage: definitely tape here, not a huge problem except it's tape so it sucks. It won't keep as well as black and white negatives but it might last longer than 70's and 80's colour negatives, which were notoriously prone to fading.
• Making prints: inkjet printers were quite possible to acquire in 1980, flying spot-scanning an image onto RA-4 colour paper is also possible.
• Projecting it: CRT projector could do it, or better yet use the flying spot-scanner for making prints to print onto a Kodachrome slide and project it normally
• Displaying it digitally: high resolution displays were definitely possible to make, but the amount of expensive RAM chips you need in this pipeline is getting pretty insane. Possibly made easier by using a slow scan monitor with long-decay phosphor (see e.g. old vector CAD displays).
  • Storing a full colour quality 24-bit per pixel standard definition TV image (which is 0.3 mp) requires around 1 MB of RAM, or just under twice what an IBM PC could make use of directly.
  • Our proposed system would likely need around 4⨉ more than this just for video-RAM to truly compete.
• Editing it: You'd need at minimum a fridge-sized mini-mainframe to usably digitally edit the image, but it would be technically possible.
  • Assuming we want to keep a single copy of the 1 mp image in RAM we need around 4 MB of RAM
  • An IBM System/38 the size of a large chest freezer had around 1.5 MB of RAM in 1978
  • An IBM AS/400 from 1988 had a dramatic increase, apparently 64 MB wasn't unheard of.
• Sharing it with friends: get a stamp and mail them prints like people did ca. 1890-2005.
  • If you want it electronically then you need to get a beefed up ISDN rolled out to the masses 15-25 years ahead of the actual schedule.
  • You also have to convince the phone company to not treat data transfer as if it's a phone call to really boost adoptation.
  • In theory you could just print it and put it into a fax machine, but colour fax was never a mass market thing. Also you don't have a fax machine at home unless you're a stock broker.

It bears repeating that many or all of these limitations were solved or nearly solved by 1990 or so. CCD manufacturing was technically capable of megapixel sensors (Kodak DCS 100) and presumably much cheaper to manufacture. CRT displays for computers were full colour capable and megapixels full colour displays and associated graphics cards were quite feasible though very expensive and mainly used for professional publishing. Putting 16 MB of RAM in a computer in 1990 was quite possible, and in theory up to 128 MB was possible but outrageously expensive. Computer storage had major leaps in the same time period, both tape, solid state, and hard drives. A miniature floppy drive in 1990 could easily store a single uncompressed TV-quality image and JPEG compression was right around the corner. Printers were much more capable and compact. Though fax machines still hadn't grown colour.

As it so happens it looks a lot like 1990 or so was a critical mass for the technology to start emerging, the image sensor was only one part of the puzzle. The crazy speed of 80's and early 90's computer technology made the things that could technically be built ignoring cost in 1980 accessible to companies in 1990, many consumers by 1995, and commodities by 2005.

Conclusion

I hope this illustrates why digital stills cameras happened when they did. Even if it could have happened a few years earlier (and attempts were made at it as early as 1986), the convergence of especially consumer-accessible digital computing power and telecommunications advancements in the form of the internet seems to have created a real consumer use case for nascent digital cameras in spite of all their limitations.

Prior to the internet there really were very few useful things a consumer could do with a TV-still quality digital or analog camera that wouldn't make for an incredibly expensive and inconvenient camera with dramatically worse image quality than even the disposable cameras of the era. All with the further downside that the image would realistically have to live on a TV or computer screen afterwards.

In around the same era we also saw further enhancements to film photography probably partly owed to improved computing power in the R&D departments. To mention two technical enhancements I'd suggest T-grain films of the 80's which were initially black and white (e.g. Kodak T-Max) but were rapidly applied to create much finer grained high speed colour films than were previously possible. This made it possible to make the small-aperture autofocus zooming point & shoots of the 80's and 90's, as well as disposable cameras for even lower TCO for occasional shooters and children.

Another technical/process improvement was the proliferation of the mini-lab which made film developing much easier to perform in a limited space, leading to one-hour development shops popping up all over the place.

These factors kept film relevant for probably a decade longer, though I still suspect most families at the time only handed in their film roll for development somewhat begrudgingly once a quarter at most and were definitely ready for digital by the dawn of the new millenium.

Following the previous entry, the PCB's for the early summer 2024 assemblies have arrived. First out is the Falcon II KDU PCB's, which replace the original PCB while reusing some of the key components.

Design Goals

The purpose of this design was to make a form-fit-function replacement of the KDU internals. As mentioned previously the KDU used early 2000's design and with absolutely no software interface documentation it was not feasible to reverse engineer the existing design.

Additionally since I am also making the PRC-152 front panel, and the 152 KDU replacement, I want to standardise software interfaces with more flexibility than e.g. the original 152 KDU offered.

I'm also trying to make all devices in the system remotely programmable over serial – as such I made the original "KDU Detect" line in the 7-pin connector connect instead to the STM32 BOOT0 pin. This pin can be set high before powering on the device to enter serial bootloader mode. This change may actually make this incompatible with the original PRC-150 radio, but it's not like I have one of those.

Above the new bootsplash image is rendered. This image is shown for a second or two on power-on, and whenever serial communications stop for more than approximately 1 second.

PCB's

The circuit boards are relatively simple, but with some relatively complex geometry.

A 4-layer board was used as usual, and I chose to use ENIG and epoxy filled/capped vias to use via-in-pad. This saves some space, but is not a critical requirement.

Above a front 3D render is shown, where I basically have nothing. The LCD is not modelled, but slots are present to use the original mounts. The pin header connectors simply reflowed off the old board and soldered onto the new one.

Q1/Q2 are phototransistors, which are not currently used but by drilling some holes in the case these could be used as light sensors. 

A JST PH connector was used for the two LCD heaters, the original connector was slightly more compact but the new design had plenty of room and this was cheaper.

On the back we have some stuff. The main processor is an old standby, the STM32F103RE. This is a processor with a reasonably large 64 kB RAM and 512 kB of flash, in a 64 pin package. It's a good choice where a relatively large amount of I/O is needed. An F-RAM IC is used as usual to store configuration parameters such as the LCD contrast.

The LCD interfacing added some complexity since the data lines run at 5 V, while the control lines can be 3.3 V. A 74LVC245 level shifting bus transceiver was used. I found that the 2 kHz LCD clock can be overclocked but it doesn't seem to affect anything, at excessive rates the LCD visual quality is affected somewhat.

For interfacing, a slew rate limited RS-422 transceiver is used, and a TI TPS560430XF DC/DC controller was used to support a wide ~7-28 V input voltage range.

To bias the LCD an opamp and an ICL7660 was needed to generate up to -5 V. I used one of the MCU's DAC outputs to drive this, giving ample resolution.

I opted to modify the button board by replacing the original green (0805) LED's with more modern and æsthetic orange LED's. This increased efficiency was a mixed bag, since I couldn't easily replace the LCD backlight.

This backlight is very dim, requiring a very high ~100 mA operating current to reach approximately 1⁄8^th of the intensity of the orange LED's. Naturally, all the LED's are PWMed so I was able to adjust the intensity to be reasonably well matched.

The pinouts for the other connectors are shown below, but note that I had to make special mirrored footprints to make these line up with the original pinout markings. Ignore the part numbers, I hot-aired the plugs off the old board and used those to save mone—to ensure perfect compatibility with the LCD and front panel.

Software

The MCU software is written in the STM32 IDE, where I opted to use FreeRTOS as a dispatcher, similar to the RF-5980 design.

LCD

The LCD interfacing was surprisingly simple, and getting an image on the screen only took an hour or two. The parallel 8080 interface is not particularly difficult to generate using GPIO, and I saved myself some grief by ensuring that the 8 data bytes were placed in sequence on a single GPIO bank. This way I can easily use the BSRR registers to flash out my data byte.

I also implemented BUSY signal readback, but this is not generally needed in my experience. I was only able to exceed the LCD controller's speed once I switched to -Ofast optimisation. A few strategic 1 µs delay calls ensure appropriate  delays even in this case, and reaching ~100 Hz update rates was not difficult.

Most of the hard-ish work of getting a graphics library working was already done for the TRI PRC-152 front panel shown in the previous log entry. As such all I had to do was clean up the code a bit and modify it to use a 122⨉32 display instead of the (even weirder) 128⨉34 display of the front panel (and the less weird 128⨉64 display of the TRI KDU).

This difference amounts to one less 5⨉7 character of text on screen, which shouldn't be too difficult to deal with later when I will want to use the same code to talk to both devices.

Comms

The serial communications use DMA as expected, running at the maximum 230'400 baud (with 250 kbaud⁄s limited transceivers). A simple framing format used for the speaker is repeated — a message starts with a ':' and ends with a carriage return, a newline can be used but is ignored by the parsers. I also use a pipe character ('|') to separate the header from the payload, making manual decoding of the data easier.

All data is encoded as a hexadecimal string, meaning a 2x overhead is incurred, with the benefit being highly reliable framing, and the communications are printable making debugging easier.

A separate FreeRTOS task polls the DMA transfer and processes data, along with scanning the keypad and generating messages periodically and when keys are pressed.

Some header information indicates source/destination and message type, length, and a CRC-32.

This header is common for all messages in the system, and ensures that a message router can receive, verify, and pass along an unknown message. E.g. the RF-5980 speaker controller does not have the headers and code to parse and inspect the contents of KDU messages. Instead, it only needs to know the routing information (what UARTs the packets will go to/from, and their source/target id's).

Interface

The KDU accepts a structure defining the display state. The default display has a 2-line 5⨉7 center text field and top/bottom 4⨉6 text fields. Small bar graphs on the top/bottom are controlled numerically and can be turned on/off, and larger bar graphs on the center lines intended for volume/RF level display are also parametrised.

It's also possible to switch to all-text in large or small text, making a character-mode display suitable for making e.g. menus.

The keypad is scanned and debounced continuously. When a key down event is detected, an output field containing an ASCII representation of the button is output once per press. This makes it easy to implement getc() type serial processing of button presses.

Additionally a bitfield is output representing all currently pressed keys, and various runtime parameters like backlight state, LCD bias levels, serial number, reset-cause, on-time, and a sequential message counter.

The output data is generated twice per second, and whenever a key-down occurs. This ensures that the device will respond quickly to keypresses without overwhelming the speaker-radio serial bus with excessive data. The timer based transmission is useful to ensure that the KDU is always signalling its presence to the upstream controller.

Testing suggests that any 4 keys can be detected properly, when a 5^th button is pressed depending on combination some ghost keys are detected. This is sufficient to implement e.g. a shift-key type overlay.

Test Integration

As part of the larger system, the RF-5980 speaker connects to the KDU and acts as a message router. Messages are then passed between the KDU and the Pi Pico based interface test board, and then passed along to a PC control software for monitoring.

Above a screenshot of the console mode monitoring application is shown. This program is really just an interface test, and has been very useful in developing and debugging the system. In the current state, the program talks over USB-serial with the Pi Pico.

When running on Linux it can also be connected directly to the RF-5980 speaker — the restriction is mainly caused by the macOS USB-serial drivers not supporting baud rates above 460'800 while Linux ones do.

Lacking an actual radio as part of the system, the KDU currently controls some parameters of the RF-5980 speaker system. This is done by parsing the RF-5980 telemetry in the Pico board and generating display data for the KDU (e.g. handset type selected, on-time, audio routing, volume levels etc.).

Above the KDU is presenting parts of the RF-5980's state. Top row shows HS state (muted), volume (~–3 dB), on-time of the RF-5980 speaker (60 seconds), and S/PDIF lock state. The center rows show the names of HS1 and HS2 profiles, and the dashed lines switch to VU-meters when PTT'd. The bottom row shows the loudspeaker is unmuted at around –5 dB volume.

The KDU response is parsed in the Pico and controls parameters such as handset type.

Notable Issues

The major issues found during initial assembly and testing included:

• Swapped Anode/Cathode on the LCD backlight – modified the LCD
  • The newer LCD modules used by most of the KDU's I have include solder-bridge pads to make this easier
• Swapped +/– on the RS-422 transmit lined — fixed by mod-wires
• Excessively dim LCD backlight – fixed by reducing series resistance from 24 to 8 Ω
  • This is using a large part of the 600 mA 5 V bus current budget. I should also swap the 2N7002 for something with low on-resistance since this is probably significant now.
  • Partial disassembly of the LCD module suggests that LED replacement is not trivial
• Surprisingly high LCD bias currents – originally I had 10 kΩ in series but I ended up using 120 Ω instead.
• RF-5980 S/N 1 had a defective RS-422 receiver
  • A 0805USB common-mode choke had an open pair.
  • This still allowed data transmissions with a high bit error rate, preventing successful decoding.
  • Fixed by swapping the choke. These devices are pretty fragile and harder to hand solder reliably than most other SMD devices.
• Software bug introduced in the Pico interface board had me chasing spurious button-presses for ages
  • Turns out the Pico would sometimes forward KDU keypress packets twice.
  • Fixed by using the sequence counter field to handle this case. I also fixed the logic bug in the Pico code, of course.

Conclusions

Over all this project has been successful.

The issues identified during assembly and testing were not unreasonable. The mechanical aspect worked out perfectly, electrical interfacing was a success and the mods were not excessive.

Software-wise no major issues were found really. An attempt to use FreeRTOS queues to pass messages along seemed to have some issues with latency, though I suspect they were overloaded due to a bug elsewhere that caused excessive traffic.

The addition of relatively high speed message passing for the KDU does not seem to have significantly affected the workload of the speaker processor.

At the time of publication I have assembled 3 units, with the only adjustment needed being the contrast voltage. Sadly, the first unit I tested seems to have a better LCD panel than the remaining units, which show somewhat reduced contrast.

The original Tri PRC-152 I purchased in 2023 was not a very good radio, with the biggest issue being a very limited radio with very poor audio.

This is a summary of the current work up to summer 2024, with future entries to be added as I go. Realistically this won't be a finished design before mid 2025.

Replacing the Front Panel (Finished)

The first board I made was the front panel replacement, a mostly standalone assembly. I elected to add a local micro-controller to the front panel to handle button readout and LCD control. Additionally, I moved the speaker power amplifier and microphone pre-amplifiers to this board, and I expanded the number of microphones from 1 to 2.

The new PCB actually worked out just fine, though it took me almost a year to bother getting the LCD code working. I decided to also use orange LED's for the keypad backlight, and I added a red/green LED and light sensors to the chassis.

The biggest issue faced here was that the 2 W capable speaker power amplifier combined with FFC 5 V supply resulted in severe voltage drops when driving the speaker hard. I ended up modifying the design with around 1 mF of bypass capacitance (glued into the casting) to keep the 5 V rail stable, and I added capacitance multipliers to the 5 V supplies for the two microphone preamplifiers.

Once I started the only processor issue was that I had misidentified Data/Command and the enable line, which caused some head scratching. Fortunately this was easily swapped around in software.

I also revised the phototransistor sensors range, these are used to dim all the LED's using PWM.

Battery Interface (Finished)

The battery interface was made twice, the first one being kind of a rushed design made to fit into a system design that then moved on.

It had a linear slow charger IC, active ORing between internal and external power, and a 5 V power supply intended as the always-on regulator.

I later re-spun the board, making some changes:

1. Ditched the 5 V regulator
2. Kept the active OR circuitry
3. Added a boost regulator powered only off the external supply input, allowing the battery to charge off lower input voltages
4. Kept the slow linear charger

Ideally I would integrate USB-C PD capable charging circuitry, but there simply wasn't room for this.

The design is relatively simple and allows powering off an external ~12-13 V supply with seamless battery switching. When powered externally, the battery will charge. If the radio is off, the battery will be able to charge even with lower voltages.

Initial Processor Board Concept (Abandoned)

The processor board was initially meant to use a Digi SoM device, but this turned out to be very hard to get as an individual. I then later changed tactics and made a design based on a Raspberry Pi CM4.

The Digi SoM EVM was ordered, and I used this with two RTL-SDR dongles to make a prototype AM/FM receiver, using the redesigned front panel as a speaker, and the Tri KDU as a serial display. This was fairly successful on a technical level, the performance of the AM/FM receiver was top notch, so the code will hopefully be reused.

This design would have integrated 4⨉RTL-SDR receivers, a LoRa modem, a short wave AM/SSB receiver, and a GNSS receiver. Additionally, it would have included wired Ethernet on the side connector.

I did completely route the design and I was fairly close to ordering it, but upon reflection I decided that the software work to support this as a practical radio would be enormous.

I was also painting myself into a corner wrt. the transmitter side – the idea was to use a CATV hybrid as a power amplifier without any output filtering. Then a number of different simultaneous carriers could be transmitted at the same time. I realised that actually making this RF board would be very challenging.

The parts purchased for this concept are planned to be reused for an entirely different concept.

The Requirements Set

I spent the early part of 2024 rethinking the concept. I concluded that making a one-off design of this complexity would be pretty wasteful. As such it was decided that the design had to be somewhat flexible to let me repackage the radio boards as e.g. base station radios.

I had some vague requirements for this project, so I'll try to summarise them here:

• Has to make the PRC-152 radio useful, and utilise the capabilities the large chassis and battery offers
  • Has to be possible to hook up to an external RF-5980 speaker and Falcon II KDU with an interface board for the base station variant
• Great audio with internal and external devices
  • Including RX AGC and noise reduction for AM/FM
• AM receive/FM transceive, 118-174 and 400-470 MHz min frequency coverage
  • Target: DMR transceive for VHF/UHF
• Minimum 2 W RF output power
• Minimum of 3 receiver channels for any mode to support scanning
• Capable of full duplex VHF/UHF operation
• GNSS receiver for APRS/Meshtastic beaconing and time synchronisation
• APRS transceiver
• 6-pin handset interface supporting powered headsets and a V60 PTT (digital)
  • Initially I planned to use 5 V power like the Tri, but changed this to 12 V nominal later
• For base station: support for 2-4 external analog radios

Some nice to have requirements also appeared:

• Short-wave receiver with minimum AM/SSB, when paired with appropriate antenna
• Wi-Fi remote control when at base (web interface to program channels)
• Meshtastic 868 MHz support
• Bluetooth audio support
• Interface between Radio and Control board should be compatible with a TLK1501 SERDES IC

The New Concept

My new concept started at the radio board end. I elected to put as much as possible into the radio side then the control board would have to fill the rest in.

For the base station configuration there will be at least 2-3 additional circuit boards to support e.g. the SERDES routing and things such as external analog radio interfaces. These functions will hook up to the future processor board, which has not been fully designed yet.

RF Board (Future Work)

To support FM receiver for e.g. APRS, I plan to use 4 pcs. RDA1846S SDR receivers (the core of a Baofeng UV-5R). An option to use the RDA1846 transmitter directly (no PA) is also planned, to allow for ~1-10 mW very low power transmission, and possibly full duplex operation over short distances.

The current working model of the board is shown above, with the ISM and transmitter board (not visible) modelled in.

To support AM receive, the plan is to use AK2401 SDR receivers. These devices include a zero-IF complex downconverter and high performance ADC, and I plan to connect them to a DSP/processor using I2S to process the I/Q signal for AM/FM/other demodulation.

The processor is planned to be a STM32H7 dual core (M7/M4) device, with the big core doing the DSP work and the M4 doing the housekeeping.

DMR/FM Radio Board (Planned)

I've elected to use niceRF modules for the transceivers, and two options are suitable here. The DMR818S can be used for DMR for VHF/UHF. For initial testing I plan to use SA868S modules instead, which are FM only but otherwise similar, and cheaper.

As a future upgrade I may try to make my own SDR transmitter in place of using the modules, hopefully as a swappable module. I'll try to add some signals to the interface that may be useful there, such as a clock signal for a synthesizer.

These modules along with the antenna interface will be made as a separate pluggable mezzanine board. This will be mounted to the RF board with a cooling interface to the center casting of the radio.

This board is planned manufactured summer/autumn 2024. Above a 3D printed model of the PCB is test fitted after machining the central casting of the radio to accept it.

I've found that 3D printing models of circuit boards is a very good way to match more complex geometries.

ISM Board (Planned)

To support Meshtastic, GPS, and Shortwave reception, a second mezzanine on the other side of the RF board will contain the required hardware for these functions.

The Heltec HT-CT62 LoRa module will be used for Meshtastic, a Si4735 receiver for short wave, and a uBlox MAX-M10S will be the GNSS receiver. Additionally, I had room for a RTC battery on this board.

A second antenna interface will be used here, and a new antenna mount was retrofitted to the radio back shell. This was 3D printed out of stainless steel, which was a delight to put threads into. These were made by JLC, and the quality was quite good.

I plan to make this board in summer 2024.

Processor (Future Work)

For the processor board, the plan is to use a Raspberry Pi Zero W (version 1). This is the slowest but also literally the cheapest Linux capable processor module available. Given that the bulk of the signal processing will be done in the H7 MPU, and I plan to use a SigmaDSP (likely ADAU1442) for audio processing, the main job of the Zero will be housekeeping. Mainly, the plan is to hook up SPI for DSP control, and a USB hub with CH340 serial converters to talk to other devices.

The Zero W has the benefit of being very low power and relatively compact. I will make an interposer board to make mounting more convenient.

Additionally, I am trying to make it feasible to put a SERDES IC between the RF and control board. This would allow remote mounting of the actual radios, with a fiber optic link between it and the control board. The main restriction there is some potential clocking issues and the added delay for the I2S audio links, but I consider these to be solvable problems.

External Speaker, RF-5980 (Finished)

Since I now knew I wanted to make more than a single radio out of this design, the extra radios would need their own speakers and displays.

I was able to find a couple of Harris RF-5980 powered speakers with dual handset ports for relatively little money on eBay. These were determined to be a good base for the non-portable radio variants. At the time of writing I have two in perfect condition, and am looking for a third since I made 3 electronics sets.

The speaker itself has a radio interface, a power interface, dual handset ports, a speaker, and volume and on/off controls for both speaker and handsets.

I made new electronics for these speakers, adding a processor, a DSP (ADAU1701) to process audio, digital audio in/out, and a serial port for control. Additionally, I added a V-60 interface to one of the handset ports, and repurposed the original power plug hole to be a KDU interface with serial port and power.

The build went pretty well, the major issues I had were:

• Incorrectly measured mounting holes – drilled two new holes and plugged the old ones
• The WM8804 S/PDIF transceiver is hard to use in full duplex, see linked article.
• Some strapping to make the ADAU1701 send and receive data based on the WM8804 I2S clocks (need to hook up both input & output LRCLK/BCLK pins)
• Turns out the ADAU1701 1.8 V supply needs to be fairly beefy, so an LM1117 had to be modded in to drive it
• Also turns out that isolated DC/DC's are pretty noisy, so I had to add 78/7912's to the DC/DC converter output to quiet down the supplies

It has been commented that a speaker has two wires, but this design only needs twenty. As seen above, the speaker's on-axis response is not all that bad.

The V60 interface is software selectable, and just uses a set of analog switches to select between the analog mic/speaker signals and the digital lines. The S/PDIF audio to/from the V60 is simply passed through the speaker, while the serial port is routed to the MCU in the speaker which can pass messages as needed.

Similarly, the KDU interface has the serial interface routed through the speaker MCU. I chose to use a 6 pin MiniXLR for the KDU. This is a low cost shielded connector that fit the existing holes with a simple 3D printed bushing.

The radio interface uses a 20 pin Hirose LF13 plug, which was the best option for something that fits in the existing holes and isn't crazy expensive. All the interfaces are differential RS-422 or similar, and I had some shielded twisted pair industrial cable sitting around that was used to make interface cabling.

1. Isolated 24 V supply
2. High speed serial port (~1 Mbit⁄s)
3. S/PDIF TX/RX, speaker
4. S/PDIF TX/RX, V60
5. Reset & Bootmode

The radio side is simply a 25 pin D-Sub, for simplicity's and costs's sake.

A Pi Pico based board was made to act as an interface tester for the speaker, I probably won't use the Pico again except for special circumstances. Above an interface tester program is shown, which shows the state of the speaker control and selected audio profile. This program can talk directly to the speaker using a RS-422 adapter, or (like above) can talk at reduced rate through the Pico USB serial interface.

The interface board was over all a success though, I added V60 style mini-XLR connectors that lets me connect an analog radio. Currently this is in operation with an Ericsson Orion for transmit/receive and an Icom IC-A6 airband transceiver (no transmit, through fiber optic).

The RF-5980 is considered finished aside from assembly of the additional units. Software-wise the core functionality is finished, but support for e.g. KDU/V60 serial data routing and polishing of the serial interface is still needed.

I also made 3D printed TPU dust covers for the connectors, this saved quite a lot of money!

KDU (Assembled)

I previously wrote about the Falcon II KDU that is available quite inexpensively on eBay at the time of writing.

See my separate devlog on this: Devlog 2 — The Falcon II KDU

This device is quite cute, and I decided that this would be a good HMI device to use with the base station radio concept. Having worked out the pinout, adding the electrical interface to the RF-5980 speaker was relatively simple.

While I did consider trying to reverse-engineer the software in the KDU, I didn't have the appropriate programmer to read the original flash code. I was also scared by the enormous size of the flash, fearing that it may contain an entire operating system and a million layers of abstraction.

Further, redoing the electronics means I can make my own interface, hopefully making the TRI KDU, the FCII KDU, and the internal PRC-152 keypad module very similar in capabilities and software interfaces.

Since this design is very neat, I ended up buying five of these in total. I figure I can use these for other things later.

TRI KDU (On order)

The TRI KDU was discussed in the PRC-152 article. I managed to pry it open, and made a new electronics set here as well.

There wasn't much wrong with the original design, but since the processor used by the Tri device wasn't pin compatible with my STM32 devices I ended up with a respin. Further, I wanted light sensors, PWM dimming, and a more flexible software interface to support additional display modes.

Additionally, I added a DC/DC converter on the input to support 8-24 V power.

More details to be added in a future entry since these parts are on order.

V60 PTT/AMP Headset (On order)

The V60 PTT and FCS AMP headset combo was also designed into the system. The V60 PTT is a 4-way PTT with 3 radio interfaces.

I redesigned the PTT circuitry entirely, with a similar feature set to the RF-5980 speaker. The main radio interface is now a serial port and S/PDIF audio going both ways. The original V60 design was completed before making the RF-5980 circuitry, and I used the RF-5980 design as a prototype for the more compact V60 system.

A number of minor issues were found in the RF-5980, and I have addressed these in the V60 design so hopefully I won't have as many issues this time.

The V60 PTT then has the main digital I/O, the headset interface circuitry, and adds two generic radio interfaces.

These generic interfaces will contain speaker audio inputs, microphone (simulated) outputs, PTT out, and retransmit (RT) in. RT is basically a squelch-output that is supported on some radios including the PRC-152. This can be used to make a simple radio relay with two radios, interconnecting the RT/PTT's both ways. This interface is also part of the RF-5980 interface test board.

With four PTT buttons, PTT I/II is nominally the PRC-152 A/B channel, with the III and IV being the two generic radios. There is also an uncommitted button.

More details will be added to a separate log entry, once I have working boards.

AK2401 Test Board (Planned)

Since the RF board is intended to use AK2401 SDR receivers for e.g. AM receive, I need to prototype this to ensure it will work as intended. Of particular concern is the I2S hookup for the AK2401 digital I/Q data. I have previously found the STM32F1 and F3's I2S peripheral to be largely ornamental, so I'm hoping that the H7 has something that actually works. Previous testing of the SAI peripheral indicates that this does actually do what it's supposed to, but the SAI's will be used for other functions.

The plan here is to make a board with an AK2401 and an ADF4351 synthesizer. Two of these will probably be hooked up to a STM32H745 Nucleo board as a proof of concept. This will also let me start working on the software demodulators.

I'll probably build this as a separate project and make the test assembly into a standalone AM/FM receiver with e.g. a Falcon II KDU interface and internal speaker. While this will be obsoleted by the PRC-152 when finished, it will be useful in the mean time, and can probably find a home somewhere.

(2024/08): The AK2401's are on hold, pending evaluation of using EFR32 Sub-GHz receivers instead — these are lower cost, seem to offer 16-bit I/Q data, and include a 40 MHz Cortex-M4F core that should be sufficient for demodulation. Will return to this in a future article.

This is my collection of SWR measurements of various antennas I've bought, partially just to keep them somewhere I can find them.

This article will likely be updated as I acquire new antennas to test.

This set of measurements was performed on a nanoVNA V2 using a minimal ground plane to simulate a hand held device. I decided to touch the ground plane to extend it for some antennas, since they performed significantly better this way.

My goal is to determine optimal antennas to use for a combination of fixed install and portable use, to cover the range of 433, 868, GPS L1, and 2.4 GHz.

Additionally, I am interested in VHF/UHF antennas to cover ideally 100-500 MHz, preferably continuously.

5G/IoT Antennas

Summary

The Taoglas Apex IV is the only choice if you need 433 MHz, and it's competent otherwise.

The Pulse W5084K is probably the best over all portable antenna in this category, with better than 2:1 SWR across the board.

The 2J "Dagger" is also a good option given the performance to size ratio.

For fixed install the Laird TRA806/17103P is a really good option when given a bit of ground plane.

Taoglas TG.46.8113 Apex IV

This antenna is specified for 410-450 MHz as well as the usual ~700-6000 MHz range.

It performs with around 2:1 SWR in the 70 cm band when provided with a little ground plane, decent 868/915 MHz, and very nice GPS and Wi-Fi performance. It's pretty big.

Pulse W5084K

This is a similar antenna to the Taoglas above, but it lacks the 70 cm band. It's shaped like a lollipop!

The antenna looks messier, but has decent 868, GPS, and excellent Wi-Fi.

2J Antennas 2JW1483 "Dagger"

The only whip antenna in its class for the initial tests, this antenna looks really nice and feels pretty solid. It offers borderline 868 performance, decent GPS, and excellent Wi-Fi.

TE/Laird DBA6171C3-BSMAM

A smaller antenna than the two above, this antenna is not very good below 1 GHz. Usable for GPS and Wi-Fi, not particularly good at 868.

TE/Laird TRA806/17103P

This is a fixed install version of the NMO antenna, it's part of the "Phantom" series of dome-antennas commonly seem on public service vehicles. It's pretty heavy for the small size, and performs really well!

The test was performed with a hand on the ground plane, this dramatically improves 868 performance. My SWR plot looks quite similar to the datasheet one.

Gizont 5G Gooseneck

This is a large gooseneck antenna marketed as covering 600 MHz and up. It has a very poor performance in the lower end, and smooths out later.

Not a great choice over all.

VHF/UHF Antennas

For VHF/UHF antennas we do have to consider that the minimal ground plane will affect the performance. Further, narrow-band antennas are prone to shifting their resonant frequency by quite a lot depending on installation.

I later repeated some tests with a ~40x20 cm aluminium ground plane, these are marked as such below. For the Comrod antennas below I use an IC-705 with a Windcamp cage and a custom alu. plate as a mount.

Summary

The TCA VHF/UHF goosenecks are good choices, the VHF one does seem like it could be used at low power as a dual-band antenna.

If you can get a Comrod, Radiall, or genuine Harris then these antennas do offer good SWR but lossy matching over a very wide range. Generally a bigger antenna will perform better in this domain.

TCA VHF & UHF Goosenecks

These gooseneck antennas can be found on AliExpress, they have a relatively thick whip section (~⌀20 mm). They perform relatively well given their size, the VHF one can almost be used as a dual band antenna.

Not sure why this antenna performed so poorly on the second attempt.

Triumph PRC-152 Whip

This 33 cm long whip is the standard antenna for the TRI AN/PRC-152 as supplied in 2023.

It's not amazing, but it looks like an attempt at covering the intended range (136-174, 220, 420-440) was made.

Unknown, ANT.BROADBAND 90-512 MHz

This TNC antenna is marketed as being for the PRC-148. It's better than the Triump one above, having a more wide-band but poor match across most of the specified range.

20 cm long gooseneck

This gooseneck antenna has a 20 cm long fiber-glass whip section and is marketed for 144/430 MHz operation. No real change when a ground plane is added.

It's got relatively sharp match in the 150 MHz range, and a very broad-band match from around 300-470 MHz. Not the worst thing I've seen but poor on VHF.

LB-ANT-8W (Harris clone)

This is a clone of a Harris manpack antenna, the typical blade one. I did a couple of tests with this one. I believe this one is made by Triumph.

The markings are "LB-ANT-8W", P/N RF-3152-AT152, which is a real P/N but is not a 30-512 MHz antenna. I think the 8W suffix indicates this is an 8 W rated antenna. The antenna as mentioned is really meant for a manpack, but removing the gooseneck makes it slightly more practical as a portable antenna.

It has good matching across a wide range, but the second plot shows what it looks like without the blade attached at all, I'd wager the matching unit gets pretty warm.

Above a picture of the matching unit for the specific clone antenna I tested shows what I believe is a 1:9 UnUn transformer and a couple of dummy resistors. The antenna reads as a slightly reactive 100 Ω down to around 5 MHz, see Appendix A for the reason. It is surprisingly usable as an SWL antenna.

"LB-ANT"

I purchased what I thought was another LB-ANT-8W in May 2024. Several differences were noted:

1. For clarity: the item listing did show what I received, though some photos in the listing appeared to be of other variants of the antenna including the one received previously.
2. Marked as a 136-480 MHz antenna instead of 30-512 MHz
3. Matching unit seems to be a cast plastic piece instead of the lathe turned plastic of the previous unit
4. No Harris™ logo
5. If there is anything inside it's not the wide-band match design, since it has very poor SWR with no whip attached
   1. Performance at 400+ MHz seemed pretty poor
6. The screws used on the previous unit were ¼" with a thread pitch close to 1 mm (probably ¼"-24)
   1. The new unit seems to use M6x1 screws instead, which I think is more common for the Chinese made units for obvious reasons
   2. These are one-way compatible, the previous base with ¼" holes will accept M6 hardware but not vice versa
7. Tape-whip was somewhat shorter, but seems to be built with decent quality parts

All in all it seems the variant of the antenna has been cost optimised, while I probably received an earlier run in 2023.

The choice of changing the matching network may in part be due to users burning out the antennas.

I'm somewhat disappointed, but the new hardware was repurposed a little. I used the new whip with the old matching unit, being slightly smaller it fits a portable radio a little better. The new assembly is a decent fit for VHF use.

I suggest users looking for the proper wide-band design check to make sure that the listing shows a picture of the matching network inside the antenna and is marked with the appropriate frequency range.

I later purchased another set also marked LB-ANT that said 30-512 MHz, and this seemed to be approximately the same as the first one I purchased, including using ¼" thread forms.

Harris 12011-2710-03

This is a believed genuine Harris stock PRC-152 antenna, with a ~10" (13" total length) non-removable blade section. It is labeled as a 10 W 30-512 MHz antenna.

It seems to basically perform better with a smaller ground plane or when the blade is in body proximity.

Comrod VHF30512MP/TNC

This is a legitimate military whip antenna intended for manpack radios (not really for hand helds). Comrod (🇳🇴!) is a pretty large manufacturer of various military antenna systems, in the same vein as e.g. Harris, AeroAntenna (more of an aviation manufacturer), and Radiall.

It covers the 30-512 MHz range and is not specified for gain, but has a maximum specified SWR of 3.5.

The antenna as measured drops below 3.5 SWR around 20 MHz. Further, it maintains SWR up to around 600 MHz, and in theory it might be usable for GPS L1 and 2.4 GHz Wi-fi since the SWR comes down in this range.

It is rated for an unusually high 25 W for this type of antenna – the base is quite thick, ⌀33 mm or so at the widest point.

The whip seems solidly attached (possibly held with some set screws to the matching unit) and is 1.2 meters long including the gooseneck.

SWR performance was tested using an IC-705 Windcamp cage with a custom 3D printed aluminium mounting base, giving it a slightly larger ground plane than the previous tests. This is likely on the small end but a fairly reasonable manpack simulacrum, and this is where I currently plan to leave this antenna.

The antenna basically meets the SWR performance specification, though it has relatively large SWR ripple.

The datasheet notes that a low loss matching network is used. This is likely why we can see 3-4 distinct resonance dips across the band rather than the smoother response of a lossily matched antenna like the Harris ones shown above.

The HF performance doesn't really flatten the way a resistor-matched antenna does as shown in Appendix A, also suggesting a different network is used.

When folded the SWR plot is very sensitive to the exact orientation, and the datasheet subtly implies the antenna is only meant for use in the unfolded position, given a velcro strap apparently isn't even offered as an option. The tape section is also pretty hard to actually break for bending.

Body proximity near the base seems to slightly improve the SWR of the antenna, and this case would be typical for a body-worn use case.

Comrod VHF30512HH/L

This is the handheld variant of the above manpack antenna. The rated power is lower at 16 W, and the total length is around 80 cm instead of 120 cm. Gain is specified as –12-0 dBi, obviously dependent on installation type.

It's supplied with a velcro strap for folding, and is generally much lighter (and easier to fold). Mechanically it's a good fit for a PRC-152 type radio.

It seems to have a slightly different matching network vs. the manpack antenna with lower ripple. 

Radiall MD10-004 Flexible Whip

This is an overmolded whip antenna that is available through Mouser (some other models are also in stock). It is manufactured by French manufacturer Radiall, though the country of origin is in fact Mexico.

The MD10-004 doesn't have a public datasheet but looks basically identical to the TRI PRC-152 stock whip (and the Gizont wideband mentioned below), it's a ~13" overmolded whip specified for 30-512 MHz coverage with an 8 W power rating.

Build quality is quite good, with a solid feeling. The antenna is embossed with a Radiall logo and a text reading "Antenna, Wideband, 30-512 MHz).

Testing was performed using the IC-705 ground plane, and it shows a >3 SWR across the board with >2.5 at most frequencies. The response varies a bit with body proximity, the change is primarily improved SWR at various frequencies.

We can see from the smoothness of the plot that it's probably a very lossy match, the ~2:1 SWR areas look very much like a 100 Ω resistive load. The HF response is very deep hitting 3:1 below 10 MHz.

The antenna very much meets the requirement of "low SWR wide band", I expect it'll perform about as well as the genuine Harris 13" whip. The main difference being that this whip is more floppy, while the flat blade can be collapsed but is stiffer over all.

Appendix A: What's inside a wide-band military-style antenna?

I had also purchased a Gizont wideband (30-512 MHz) whip antenna but unfortunately I broke this prior to getting proper measurements.

I was however able to disassemble it and figure out the circuitry, which is relatively simple:

The circuit has an input low pass filter, which is probably not critical but not a bad idea. A set of 50 Ω load resistors make up the lossy element, and a 1:2 transformer (hooked up like an auto-transformer) makes a 1:9 un-un so a 450 Ω or so nominal output impedance.

For a shorted antenna the minimum impedance will basically be ~50 Ω to ground, and for an infinite impedance antenna the maximum load impedance then becomes ~100 Ω.

I think this a very similar circuit to what is used in the Harris knockoff and probably the genuine article as well. The bottom 50 Ω was made of two 100 Ω resistors, and relatively high power (2 or 5 W each).

This article covers the Harris Falcon II KDU, P/N 10511-1300-03 and the associated cable and KDU-adapter P/N 12065-7100-02.

Where was this used?

Above shows a view of the Harris AN/PRC-150 HF radio, with the associated KDU installed as the operator panel.

You may recognise the "CCI" marking shown above the Harris logo, short for "Controlled Cryptographic Item". This is an NSA classification, and ensures that the actual PRC-150 radio will be destroyed rather than resold to civilians. Fortunately, the KDU itself is not CCI and so can be freely exported.

The kit I sourced includes a long cable and a KDU adapter – and the KDU seems to be identical to the PRC-150 one. The adapter looks like it might be intended to fit a PRC-152 or similar handheld radio.

The adapter is identified by PRC68.com in their Harris RF-5800V article. Here they've also identified the 9+9 pad connector as the one used on the RF-5800V-HH. The RF-5800V-HH is a Falcon II predecessor to the Falcon III PRC-152 that e.g. only covers up to 108 MHz.

Frankly I think this adapter looks pretty ridiculous on the side of a PRC-152 but ok. It contains a bit of electronics which may be to e.g. boost the voltage from the PRC-152 (~11 V) to the 26.5 V the Falcon II KDU wants. I think it also converts TTL levels from the PRC-152 to the RS-422 levels the KDU uses.

As such it's most likely the kit I received was sold for use with PRC-152 radios, it seems to be most sensible when used with the VRC-110 vehicle mounting kit, where Harris marketing shows a configuration including this kit. Note also the weird plugs near the antenna, I think this is an inline adapter that keeps the antenna plugged into the radio, but routes the RF through the amplifier pack.

This KDU is also specified for use with the PRC-117 (RF-7800M-MP) which is also part of the Falcon III series:

Pinouts

KDU

The KDU uses a 7 pin ODU MINI-SNAP® F panel connector on the left side. I believe a K20F1C-P07LCC0-400S 7 socket, shell size 0, orientation 1 plug is what fits on the KDU, but I haven't bought one to test.

The listed P/N to plug onto the radio end is a S10F1C-P07MCC0-4000, presumably the radio has a socket connector since that P/N is a pin connector that will not fit the KDU.

I found it more cost effective to just buy a second KDU+cable kit just to get a cable to reuse.

The rear pin seems to be a slightly custom modification, it's the same connector but with sockets and inside a plug shell without any connector retention features. I believe the panel mount G10F1C-P07MCC0-0000 or the cable mount K10F1C-P07MCC0-5000 will fit. Both of these seem to be unobtainium at the time of writing, but you could harvest the panel mount connector from the PRC-152 adapter since that will fit.

Above shows the pinout for looking into the face of socket and pin connectors.

Above an excerpt from Appendix A of the PRC-150 Operation Manual (10515-0103-4100) shows the KDU pinout. Not sure why RS-485 is listed given it seems to be a RS-422 interface.

Cable

The cable P/N 10511-0704-040 (40 feet?) rev T is a thin and weird but nice feeling socket-socket cable.

It has shielding and an internal drain wire, and 6 coloured wires.

To verify you've got things mostly right, check Red to Ground, I read around 47 Ω. RX+/RX- should have around 220 Ω across it.

PRC-152 adapter pinout

The PRC-152 aux connector is not publicly documented as far as I know, but we can infer some of the pins from analysis of the adapter used here.

As mentioned above, the 9+9 pad connector is identified by PRC68: Harris RF-5800V so we know what goes there.

The pad numbering is labelled on the adapter PCB, and looking at the radio it looks like this:

I didn't bother trying to probe out every connection, but this board and the adapter to the old-style expansion port with a known pinout does provide a partial Rosetta stone that could be used to work out most of the pin functions.

This numbering scheme is consistent with the 2x9 pad connector listed in PRC68.

Interfacing

The KDU will power up at around 12 V minimum. On startup it doesn't seem to do much other than show a Harris logo. The serial port seems to operate at 19200-8N1.

When keys are pressed, a sequence of bytes is output where two bytes seem to indicate which key was pressed.

This is actually somewhat similar to the TRI PRC-152 KDU interface, though that KDU uses ASCII outputs for the keys, and it continuously transmits the state instead of being reactive.

Serial Data Output

The KDU outputs a short packet whenever a key is pressed – pressing multiple keys seems to d0 nothing.

The output seems to always start with:

0x88 08 24 01 25 xx xx xx

The last three bytes seem to change in sequence with some internal key number, for example the '0' key outputs 0D 46 E7, and the 1 key sends a 0E 47 E8. This seems redundant, so presumably some checksum is part of this payload.

The sequence for '0' without the last two bytes:

0x88 08 24 01 25 0D

Has a sum of bytes (modulo 256) of E7, the last byte is therefore likely the sum of the packet bytes, excluding the last two bytes.

The purpose of the second to last byte is not known, it seems to always be 0xA1 less than the last byte, or 0x39 larger than the key byte.

The table below lists the 6th byte of the emitted string and the corresponding physical key:

Control interface

I decided to just linear fuzz the interface to see what happened, this could potentially take years to cover all combinations so it's not a great way to accomplish anything really.

Sending:  b'8e62000000000000'
Received: b'88 08 24 01 26 00 3b db' (NACK)

Corrupted data in upper left section of the logo some time after this. The sequence did not return anything on the next attempt.

Continuing through xx77000000000000 entire screen starts going weird. Repeating from 0x85 60 did not make the same thing happen – it seems to crash after some time fuzzing. Likely the length byte being set too long causes an overflow.

Sending:  b'8808240125000156'
Received: b'88 08 24 01 26 00 3b db – maybe a NACK? This response seems to happen a lot when fuzzing this region.

Hot-plugging:

Received: b'88 08 24 01 26 00 3b db fc' one time - looks like last byte is in errorReceived: b'88 09 24 01 24 00 00 17 da' every hot-plug event.

NACK from: b'e3083e9acb930021' to b' e3 08 3e 9a cb 93 00 21'

Received: b'3030. 88 08 24 01 26 01 3c dc 8808240126013cdc' then crashed. Delta A0

Byte 2 seems to be total packet length.

After this effort, I decided that this was pointless, and decided to instead attempt to dump the flash memory of the device. Failing this, I will simply make my own controller PCB. Stay tuned for future articles on this topic.

Internals

KDU

The KDU itself it pretty easy to take apart, and uses a flex-PCB for connector interfacing, a main PCB with interfaces, processor, and display. All you have to remove to get at the internals is the four corner screws, using a 7⁄64" allen key.

The keypad is a separate PCB inside a cast enclosure with a 0.1" header acting as a board to board connector, when taking the front panel off the keypad connector is to the lower left and should be levered loose first to avoid bending it.

The external connectors are paralleled via a flex-rigid assembly and connects to a 2-row 0.05" pin header.

A shielded can contains a DC/DC converter controlled by a LT1676. A MAX680 charge pump is probably used for LCD biasing, and there's two LDO's.

A MAX3488 slew-rate limited RS-422 transceiver is no surprise, but this is a nice part since it has limited slew rate for improved EMI performance.

A Freescale MC68311 processor (MC68CK331CAG16) with external flash and SRAM is used to drive the display and read the keypad – given the era (~2001?) this is not a surprising choice. There is a small header on the corner of the PCB that may be a JTAG port.

The SRAM is a CY62146 4 Mbit type, and the M29W160EB 16 Mbit flash is under the LCD. Other highlights include a DS1276 "DigiPOT" type DAC, which probably controls the LCD contrast and maybe the backlight, and a 93C86 2 kb SPI EEPROM for parameter storage.

LCD

The LCD is connected via a low profile 20 pin header (0.05" pitch). There is a 4 pin connector coming off the LCD. I spent a lot of time trying to work out what this was for, before finally dismantling the LCD module a bit more.

The two red lines measure approximately 470 Ω, and the two white ones measure around 290 Ω. Given their location immediately behind the LCD, this would seem to be an LCD-heater. Probably intended to keep the LCD working well across the whole temperature range.

The part number seems to be 1223H1+DG, which leads to a couple of places. The 1223 part suggests this may be a 122x32 display, and given the age of the design it's likely to be built as two 122x16 strips with a separate controller. There is a 3.3 V logic to 5 V buffer on the LCD, meaning 3.3 V logic can be used to drive the control lines, but the data bus is 5 V. A bidirectional level shifter is used to convert between the levels in both directions.

The OEM seems to be Phico, and the closest datasheet I could find is the Pacific Devices 12232-10. This indicates that a SED1520 controller is used.

Having acquired additional KDU's, another variant of the LCD was found as well. The different modules are form-fit-function compatible, but seem to my eyes to have slightly worse contrast than the older Phico unit. On the other hand, the backlight is slightly brighter and more uniform. 

A probe around the LCD module and board suggests that the pinout listed in that datasheet is applicable here too. Do note that the pin markings on the controller board are mirrored vs. the LCD markings, I used the LCD markings as my reference.

The LCD cover glass has some type of plastic coating on it that is solvable in isopropanol, on some of the units this was annoyingly opaque and reduced the apparent contrast of the LCD in indoor environments.

The plastic coating will be severely fogged if exposed to isopropyl alcohol (and probably acetone). Naphtha based brake-cleaner did not seem to affect it. 

I removed it and found that the visual quality of the slightly worse performing newer LCD's was improved. This coating may be intended to reduce specular glare? 

PRC-152 Adapter

The PRC-152 adapter is a pretty complex flex & PCB assembly.

It contains a ISL4223 dual TTL-RS232 converter, and a ISL83071E full-duplex RS-422 transceiver. One set of the 4223 is presumably converting RS-232 from the PRC-152 to the RS-422 that the KDU wants. The function of the other set of RS-232 transceivers is not known at this time.

It also has a LT3012B linear regulator presumably making the logic supply for the serial converters, and some type of mystery-IC marked 59IAJ or 591AJ that looks like it's wired as a boost converter with a 4 µH inductor. The latter presumably makes the 26.5 V that the KDU wants from the radios ~12 V battery supply.

The ODU connector used in this adapter can be harvested for use on the rear port of the KDU. 

The PCB markings around the 2⨉16 pad PRC-152 connector does give a somewhat authoritative reference for the pad numbering, seemingly starting at the bottom left of the radio port at pin 1, counting to the right and returning to the left for pin 5.

There are several transistors and diodes around the place, a lot of these are probably for protection, but it seems the main function of the device is to convert RS-232 signals from the PRC-152 to RS-422 signals for the KDU, and to boost the battery voltage to 26.5 V.

KDU Mount

A simple mount has been modelled for your convenience, it can be 3D printed as required, I used PETG.

It's not a complex design, and is printed in several parts and screwed together, this allows for ease of design iteration but could perhaps be optimised for parts count. I also made an attempt at making drawings.

Download here: FCII_Mount_v1.zip

It also requires some screws, all DIN912 spec:

1. 2 pcs M2⨉10 for mounting the Connector_Adapter to the Connector_M12 block
2. 6 pcs M4⨉16 for mounting the M12 block to the Block, and for screwing on the stands
3. 6 pcs M3⨉16 for screwing on the support posts and pins
4. 1 pcs M12⨉1.5 mm cable gland or similar to hold the cable

You will likely also need taps for M3, M4, and M12x1.5 to clean up the holes. The M2 holes are fine to just screw right in. I found going slow and using lubricant is a good idea for PETG, most taps get pretty warm tapping it and eventually it can start to melt the plastics instead of cutting them.

Above the light blue Block (main body) is shown, with a darker blue Pin part. The Pin (2 pcs) mates with the hole-sliders on the KDU. The Pins are retained using M3 screws, and are deliberately slightly long.

I place 1 mm thick foam along the sides to provide a cushion (spring), and the tightness of the pin screws can be used to fine tune the fit.

Above the interface for reusing the PRC-152 connector is shown, it has two parts, an "Adapter" that the ODU connector is screwed into (grey) and a M12 block that screws into the main Block.

There is no rotation indexing for the ODU connector, so the rotation is set by the front nut for the connector — I installed it hand tight, then rotated it into alignment using the connector block when mated, then went back and tightened the nut a bit more. It's a bit fiddly. Be careful installing the cable gland to prevent rotating the wire.

Additionally, some at present untested feet may hold the KDU at a reasonable angle for desk mounting, with flats for taping or M4 screw holes for screw mounting. Some 50 mm long M3 posts are used to provide sideways stability (also untested).

Future Work

As mentioned above, I plan to dump the ROM of the KDU to see if I can work out the command interface. This would make it quite practical to repurpose these displays for hobbyist projects or to control other existing radios. I decided to replace the internal electronics, see Devlog 2.

I am working on my own heavily modified TRI AN/PRC-152 and had planned on making the PRC-152 adapter compatible as is, but I have decided to re-make the adapter since this will let me freely use my own pinout.

Quick post, yes they work, and one fell apart so I took a picture.

Fiber Optic HDMI cables are readily available on sites like AliExpress and eBay these days and have been for a few years now.

I recently bought a few extras and one turned out to be poorly assembled and it fell apart, giving us a look at the inside:

This is the transmit (source) side, there's some circuitry on the bottom, and we can see some kind of blob presumably containing a VCSEL or laser transmitter. It looks like a QFN packaged IC may have been removed from the design, or it's possibly wire-bonded in there and not visible in the picture.

HDMI to fiber conversion either requires multiple fibers (one per data line, there are 4 including clock), or a serialiser/deserialiser chip to put all 4 into one signal, it looks like a single fiber is used but not entirely sure.

We can also see decent strain relief with a metal clamp holding in a moulded cable retainer.

These cables do have some electrical signalling making them not entirely galvanically isolated, this is a simplification of the problem by presumably passing the DDC (I2C like) negotiation bus on the electrical wires and running the video signal over fiber. These signals are pretty low speed so are likely able to work over quite long distances provided sufficient wire gauges and perhaps a signal buffer are used.

Compatibility seems good, though I have found one of my on-camera HDMI monitors won't properly power up the transmitter. Presumably these cables use all of the 5 V power available to an HDMI cable, while the battery powered monitor may limit the power supply more than a typical PC.

DisplayPort cables also seem to work, though I suspect they may have issues with the more esoteric parts of the specification like two-way communication. Also, they are slightly wider than a normal cable, so adjacent connectors may interfere (though I have been able to force them to work).

I super-glued the chassis together and the cable kept on working.

The TRI(iumph Industries) AN/PRC-152 two way radio is at first glance a rather silly device, a clone of the extremely capable and expensive Harris AN/PRC-152 (Falcon III) software defined hand held radio.

Is it worth the money at all?

Introduction

TRI is a fairly well known name in some circles, the company seems to have very limited direct presence with no English language web site. They seem to have found a niche in catering primarily to the airsoft/mil-a-boo crowd, a market that generally favours authentic-looking military replicas including for their communications solutions.

The TRI 152 is certainly polarising in the ham radio world, and looking at various forums we generally find a few different groupings which I'll summarise as:

• ”it's for fucking plebs that can't afford the real thing”
• ”it's probably shit for airsoft weebs”
• ”I used the real thing in —insert country here— and the real deal was shit too”
• ”I bought one and it's cool”
• ”—various racist remarks on Chinese manufacturing—”

I will admit to having a certain attraction to the military æsthetic, and so I ordered one to try out. Shipping took a while, I was informed by the seller that the delay was due to this being the latest production batch directly from the factory.

It is worth noting that these radios exist in various variants, with some differences in features. TAC-sky is another manufacturer of a seemingly very similar device, that model seems to include a GPS receiver as well.

Pre-2022 models of the radio seem to have a more limited feature set. The first issue of this radio from memory popped up around 2017, and seemed to essentially be a Baofeng UV-5R radio in every way.

Specifications

The basic listed specifications are:

• Aluminium shell, æsthetic replica of the Harris product
• Compatible with e.g. H-250 handsets, dynamic or electret microphones supported (MIL-DTL-55116 6 pin handset connector; 5 pin compatible)
• Compatible with genuine Harris batteries and antennas
  • One battery option is a 6-cell 12 V (3S) case that can be fitted with 6 18650 cells
• Transmit/receive coverage 136-174 and 400-480 MHz at 15 W power, standard narrow-band FM
  • Limited power in the 220 (220-259) and 350 (330-370) MHz bands
  • (The Harris device covers approximately 30-512 MHz with software defined modulation types)
• Broadcast FM and Air-band AM reception
• Dual receiver (implied to be a true double receiver, not just a scanner)
• Cross-band repeater support
• Speech compander & encryption (assumed to be a basic spectral inversion type)
• Support for an external wrist-mounted external control unit (KDU)

The TRI variant does not seem to support PC-programming, while the TAC variant seems to have a USB-cable that plugs into the U-229 connector. The TAC variant does seem to be slightly different from available pictures, using e.g. a slightly greener LCD backlight vs. the TRI unit.

The biggest question to answer is how does the radio perform, have TRI used the fairly large internal volume and price to stuff in a high performance radio with excellent performance, or did they just put some COTS radio modules in a fancy case and call it good?

Is It Good?

The answer to this question revealed itself pretty quickly when I received it, it's an extremely well made enclosure around what is basically a slightly upgraded standard radio, probably some earlier variant of a Quansheng UV-K5 based on the internals. There are however some nice touches here.

I won't be too hard on it but there are certainly issues that could have been resolved with slightly more engineering and user testing put into it. I'm not sure I'd recommend it unless you go hard on mil-sim.

The biggest issue I had with the radio is simply that the audio quality is not very good and the audio routing system is not very flexible. The original speaker rattles like crazy at even slightly elevated audio levels, and there is a compander-like noise reduction system that seems to make things even worse in most modes.

Further, there is no option to route audio to both the handset and internal speaker, or to auto-switch it. Additionally there is no option to use mic-follows-PTT, so if you set it to external handset mode the internal PTT works, but the handset microphone is used. This may be usable in some configurations but for a handset the microphone is normally switched so no audio is transmitted.

Transmit audio quality with an external H-250 handset was quite poor, with lacking treble and distortion, but receive audio was fine (better than the internal speaker).

The user interface is also somewhat confusing, especially the way air-band and broadcast FM reception is implemented as some kind of transient overlay mode. Also there is no squelch for AM receive, a pretty serious omission.

In general it seems like a fairly standard radio firmware was used (hell, it's likely software-compatible with some other radio). This means the UI doesn't really utilise this radio's user interface options, and things like the keypad arrow markings don't really mean anything.

Cross-band repeat does work, but the repeated audio is severely degraded, most likely due to improper filtering and level adjustment (this could probably be fixed with firmware or minor hardware modifications).

Hardware Overview

I'll skip a software overview, it's a mix of fairly standard two way radio interfacing (similar to Baofeng, Tyt etc.) and slightly confusing additions and one typo. At the time of writing, the original PCB's are spread across various tables anyway.

I took various pictures of the radio while disassembling it:

Processor

The main radio processor is a Weltrend WT58F165 ARM processor, a relatively low powered but moderately capable processor for the task of running a basic radio.

Radio Transceiver IC's & PA

The radio includes two transceiver chips, BK4819 by Beken. These are typically used in $20 two way radios, though from what I gather they are considered quite good for their price range. However, this is a $300 radio. I suspect a very large portion of the price went into the mechanical aspects.

Quite recently (during the course of writing this article) a firmware hack was announced for these devices, which could in principle be applied to this radio as well. See https://github.com/Tunas1337/UV-K5-Modded-Firmwares

Additionally, there is a BK1088 broadcast receiver which is presumably used for the FM broadcast reception. This chip is underutilised, being capable of AM and SW reception as well, but only the FM side is used here.

The main PA is common for VHF/UHF, it is a HTL7G06S011P, which is listed as an 11 W PA transistor, but I will note that there is fairly decent heatsinking so running it at ~11 V to give around 15 W is likely not a major issue.

Audio/Interface Board

Opposite the RF board is a relatively packed but simple interfacing board which connects to the RF board and provides connections to the audio PA's, microphone preamps, the front panel PCB, side panel PCB, aux connector, volume/AF mode select (top), and the 6 pin handset connector.

Basically every interconnect in the radio is a flex, with several custom flex PCB's made, which does speak to the good build quality.

The side connector only breaks out a handful of the connections as seen in pictures above, the majority of the pads on the side are unconnected. It was also quite strongly glued in place.

The handset connector seems to be a genuine quality part, it has 5 V available to power external circuitry if needed.

The top knob has two decks, one is a volume control potentiometer (top) and the bottom deck has 3 positions selecting between different audio modes (bad, awful (companding), and spectral inversion scrambler). The bottom deck is a bit too lose in my opinion, and it is relatively easy to move accidentally.

Note that the original hardware clearly has a 9 position (36° increment) rotary switch for the top position, but from what I can tell there is no open-market combo switch that would work so they used a potentiometer with switch + coaxial encoder for the bottom deck.

Curiously, there is an option to switch between potentiometer or digital volume, digital volume is adjusted with the top left side buttons like a real PRC-152. The KDU supports 20 volume levels, but I found both the analog and digital volume levels were far too high for indoor use (especially with such a poor speaker), and only the bottom 3 settings were usable.

Front Panel

The front panel has a custom PCB which interfaces the LCD, speaker, and microphone, as well as the keypad. Note that for some reason the chassis includes positions for dual microphones but only one is installed (this may be intended as a pressure relief port though).

The keypad itself was adequate though not amazing.

The LCD controller appears to use an ST7567 controller or something very similar. The actual display is a pretty unusual 128⨉34 line. The two centre lines are also mapped to the end of the display memory, making bitmap-displaying pretty annoying.

Over all it's a pretty good display with decent viewing angles and contrast, and the pixel density is acceptable for a device of this type. The user interface implemented is not optimal though.

While the flex is marked YJD7567-64 this doesn't seem to turn up anything, but I believe the YBC12834 by Shenzen Ya Bin Electronics co. ltd. is a close match, and similar products can be found under various brands on sites like AliExpress.

Above is the dimensioned drawing of a module that appears to match the original LCD mechanically and electrically, but I have not purchased one to verify this. Just look for "12834 LCD" or similar.

The table above shows the pinout, which seems to be correct.

KDU

The KDU is a very nicely constructed device, it comes in a dedicated box as well!

The device is fully glued together, and I didn't initially attempt disassembly. It appears to be more or less waterproof, and feels very solid. It uses a Hirose HR10 series 6 pin connector.

The KDU a serial device, the radio sends display state ever 50 ms or so in the form of a 32 byte burst, which is interpreted by a processor inside to drive the display. If the KDU is not refreshed every 100 ms or so it blanks the display.

This means there is no bitmap mode from what I can tell, and the display is largely limited to displaying the elements shown in the pictures. The top/bottom row indicators are generated by the KDU and mostly match what's printed on the radio button membrane.

It also transmits its' state every 10 ms, in the form of a 4 byte burst, this starts immediately upon power-on, even if no communications come from the radio.

The KDU is actually a pretty nice device on its own, and I've used it as an interface for a future project.

The main processor is a GD32F330C8, which is somewhat similar to a STM32F303 (but lacking the more advanced ADC's). This is a pretty powerful processor with an ARM-Cortex M4 processor core at up to 84 MHz. Below I clipped the GD32 and STM32F3 device pinouts, showing that they are almost pin compatible, except for pins 35 and 36.

There is an unpopulated SWD programming header on the PCB that could be used with a GD-Link programmer to reprogram this device if desired.

The LCD is heat-staked and soldered in place, but can be removed by sacrificing the heat stakes. The closest match for the LCD is a ERC12864-8, but some dimensions are slightly different.

Case disassembly was slightly painful but using a metal spudger I was able to crack the glue at the corners and work my way through until it popped open.

Battery

The battery supplied seems to be around 60-70 Wh, and feels very solid. The charger PCB is just a straight adapter, only containing a single fuse (which is good).

I didn't measure idle power consumption, but the radio seems to have strong power saving modes typical of analog hand held radios (with no option to disable it). I would be surprised if the battery life was anything less than 48+ hours in standby.

This is basically excessive in my opinion, and they could have burned a bit more power instead to achieve more functionality.

RF Performance

I didn't bother testing it beyond the basics, it's a modern single-chip radio, and performs as such. Sensitivity is excellent as usual, but audio quality is lacking.

The RF power seemed to be in spec for the standard 144/433 bands.

Summary

It bears repeating; the chassis and build quality is excellent, all the right gaskets are in place, custom flex PCB's with gold plating are used even where cheaper options would have worked.

A significant number of gluing operations have been done to ensure watertightness. The side connector seems to be made from custom machined metal pieces and plastic casting jigs. The chassis is cast and machined aluminium. The battery spring terminals have their own PCB with a custom silicone moulded plug-seal.

All the buttons are snap-domes which seem to be assembled in a jig and retained with a clear polyester tape that covers the PCB (fairly standard high-volume technique).

It seems like several custom hardware pieces were made for this device even though they could have easily skimped out. 

Unfortunately the audio and UI issues were a bit too much for me to actually use this radio.

Future Work

I have deemed the chassis to be worthwhile, and my current long term plan is to design a new SDR transceiver to fit inside the rather spacious internal volume.

At initial issue of this article (July 2023) I've gotten to the point of driving the external KDU with custom software demodulators (using two RTL-SDR's as receivers, currently capable of FM/AM/SSB). Some chassis pieces have also been modified.

This system will definitely burn significantly more power, but one benefit of a large chassis is the accompanying large battery.

Additionally, I've made a new front panel PCB with a better speaker and dual microphones, though the work of driving the original LCD (it's an unusual LCD…) with a new processor has not started yet.

Chassis Upgrades

Note: the new front panel PCB is in no way compatible with the original radio hardware, though it would be possible to e.g. replace the speaker with the OWS-4065T-4C 4 Ω 3 W speaker I used here without any major issues.

This waterproof speaker works fairly well in this enclosure only requiring a 1st order 400 Hz high pass filter to eliminate some boomyness.

I also selected CMC-2742WBL-25L IP57 microphones for this project. This microphone doesn't fit the holes as such, requiring some minor reaming on one side and a bushing on the other. They also require a 1st order high-shelf filter to boost the treble to acceptable levels.

I decided to put in a front facing bi-colour LED, and added top/front light-sensors to auto-dim the backlights.

The top knob can be replaced with a MA00S1NCGF 10 position rotary switch with only a minor reaming operation and fits the top knob both in shaft distance and angular increments. Two pins can be installed in this switch to limit the rotational range to the 9 assigned positions.

Above the mentioned rotary switch is installed and aligned, a new FFC PCB has been ordered for this purpose. Also visible are new custom FFC PCB's to break out all the side-connector pads (though a few are dedicated to ground and commoned).

As part of this effort, I had reason to work out the exact make and model of the original LCD to be able to drive it properly.

Above a work in progress from April 2024 shows the new front panel with functioning keyboard, backlight, and LCD drive. Additionally, a red/green front panel indictor was installed, and a set of light sensors is used to control the brightness of all indicators.

Addendum: Reliable AM Squelch & FM Threshold Extension

During my recent work on implementing my own SDR transceiver (at present only a receiver though), I implemented FM reception and noise squelch using fairly standard principles.

The basic concept of noise squelch for FM reception is to detect the signal to noise ratio of the received signal, for FM this can be done by tapping the discriminator, passing it through a band-pass filter centered higher than the audio cutoff (e.g. 5-10 kHz), and rectifying this.

With decreasing SNR, a combination of gaussian noise and impulse noise increases significantly near the quieting threshold (typically around 8-10 dB RF SNR). This increase in noise occurs at higher frequencies first (in particular, the impulse noise generates high order harmonics). By sensing high frequency noise, a reliable SNR estimator can be made, and the squelch simply checks the level of the noise detector to determine if a signal of sufficient quality is present. For more information look up FM thresholds effects, and also this NASA paper: A study of FM threshold extension techniques

Note that since higher frequencies degrade first, CTCSS reception is generally possible at extremely poor signal levels, which is why CTCSS detectors are always paired with a noise squelch system. Use a Goertzel tone detector for CTCSS by the way, I implemented a single detector and found performance was excellent, though it needs noise squelch to work well (since it only measures power in a band, it will trigger on noise as well).

Note also that the noise squelch detector signal can be used as a gain-control signal for the receiver audio to implement a basic noise reduction/soft-squelch system in combination with a noise-gate signal from an audio level detector. When correctly tuned, a few dB of extra sensitivity can be achieved for typical speech.

In any case, I started with FM reception and then later implemented AM reception (which is far simpler, and actually a side-product of my FM demodulator). I was initially surprised I had a functioning squelch, given that I hadn't implemented AM squelch yet. The FM noise squelch system was instead active, and this actually worked!

My observations indicate: running a full FM receiver with noise squelch in parallel with the AM demodulator works, though is a bit resource intensive. The reason this works is since the FM receiver is more or less able to lock on to the AM carrier and detect this (also possible is AFC, using this system).

The SNR to noise-detection function is more linear with AM signals (it's quite non-linear with FM), requiring different thresholds and narrower hysteresis to work well.

Testing thus far indicates that this squelch method works quite well in my area, and the noise-rejection ability is more or less equivalent to an FM receiver (i.e. significantly better than what actual airplanes have).

I suspect this squelch method may have some caveats in certain RF environments with e.g. adjacent channel signals, though I haven't tested it yet. In my area this does not seem to cause issues.

Red Hat Enterprise Linux and the closely associated CentOS Stream 9 remove a lot of legacy kernel modules from their kernels. This seems to also include removing sources from their distributed kernels.

I wanted to add the scsi/bfa driver to support Brocade Fibre Channel adapters, this is mainlined but not part of the RHEL kernel sources.

To actually use a Brocade FC adapter you also need the bfa-firmware package, which can be found in the Fedora repos (just download the RPM and install directly, it's not getting any updates). For Debian the package is firmware-qlogic.

DKMS is the de facto tool to add kernel drivers to your Linux, this tool will automatically re-compile and install any out-of-tree kernel drivers you add. Unfortunately the documentation for adding something that's already part of the Linux kernel but was left out intentionally is less documented.

The CentOS Wiki has good documentation on usage  https://wiki.centos.org/HowTos/BuildingKernelModules

I installed kernel-devel and kernel-sources packages, and the other requirements for compilation as defined in various wikis.

I then downloaded the matching kernel base version from kernel.org, in this case 5.14.19, and extracted it.

To add my drivers/scsi/bfa module, I made a folder /usr/src/bfa-5.14 and copied the contents of the kernel source drivers/scsi/bfa folder to it.

I then made a dkms.conf file in that folder:

PACKAGE_NAME="bfa"

PACKAGE_VERSION="5.14"

BUILT_MODULE_NAME[0]="bfa"

DEST_MODULE_LOCATION[0]="/kernel/driver/scsi/bfa"

AUTOINSTALL="yes"

There is a problem with the module Makefile, which I fixed manually:

obj-$(CONFIG_SCSI_BFA_FC) := bfa.o

Should be replaced with:

obj-m := bfa.o

This is since the Makefile is conditionally compiled based on the kernel .config, which doesn't include this module. You can also build by passing CONFIG_SCSI_BFA_FC=m to make, but adding this to the dkms.conf seemed daunting since I would have had to define the entire make-command from first principles.

As root:

dkms add -m bfa -v 5.14

dkms build -m bfa -v 5.14

dkms install -m bfa -v 5.14

This then installed and compiled successfully, and I observed that the module was recompiled automatically by yum when a new kernel release was installed.

Now I haven't actually tested this module, since I'm still waiting on the Brocade hardware, but the module is definitely compiled and plumbed up!

Update! It works, so if anyone needs to get a Brocade 400/800 series (e.g. 815, 825) FC HBA working on RHEL/CentOS, these are the exact instructions.

Use the open source LTFS project to talk to tapes.

A followup to the previous NAGRAFAX article, this details how I fixed the automatic phasing circuitry, and has some detail pictures of the electronics boards.

PCA Overview

The PCAs are hinged at various offsets, once a few sets of screws are undone all the cards can simply be rotated up to access the front and back. The only annoyance is the short cable going to the write head (the coax).

How The Phasing Circuitry Works

Below is an example of the defective phasing circuitry I received the fax with. The diagonal lines are the index pulse, and DIP switch 1 is on to make the fax print the entire phasing sequence. The diagonal lines is the fax trying to synchronise by speeding up the chain drive slightly.

Clearly not working right, the phase is random at the end, and it only goes in one direction, even passing the correct phase without doing anything.

The system took some head scratching to understand, I drew a block diagram of approximately how it operates to aid in understanding it.

• Video Sync is the video synchronisation pulse, the period of this pulse is measured in the phase accumulator. It controls a ripple counter U21 that clocks a 7 bit counter (2⨉4522) acting as the phase accumulator
  • This is clocked by the chain drive direct tachometer signal, this is fairly high speed signal
  • I think using the chain drive speed signal instead of the crystal speed affects the loop dynamics, probably it results in a stable loop gain independent of the LPM count
• The phase accumulator is sampled (latched) once per head sync pulse
• If in phasing mode, the 2-line head pulse counter triggers a JK flip flop that modifies certain bits in the phase accumulator result
  • (Not shown in the block diagram) I think this pulse counter ticks up when the measured phase is a specific value, terminating the phasing operation early when it find a good lock? 
  • When not in phasing mode, a fixed divider value is used
  • When in phasing, the phase-count is added to the divide ratio, and the base value is offset such that a mid-scale phase accumulator will yield the nominal divide ratio
• The phase accumulator result is used to set up a chain of frequency dividers, which run off a 100 kHz crystal controlled clock
  • In normal locked operation, the divide ratio is such that it generates 400 Hz pulses
  • When the phasing circuitry is activated, the divide ratio is modified proportionally to the phase error
• The 400 Hz clock is compared to a fixed 400 Hz (i.e. divided down based on speed selection) chain drive pulse in the 4046 PLL
• By modifying the divide ratio proportionally to the line phase error, a digital PLL is effected, this adjusts the frequency of the machine to align the phase
  • The phasing circuitry also seems to increase the PLL loop gain/control authority when active, adding in additional loop filter components with a lower impedance
• After a timeout of around 25 seconds or successful lock for two lines, the phasing circuitry is disabled and the standard frequency is output under crystal control
  • My unit seems to have been built with a 4-line phase check, but this had been modified to only check for two lines, matching the schematics
• By this time the phase should be aligned, and it will print under crystal control from then on, ignoring the video signals synchronisation pulses entirely (and it it failed to lock, it will just stick with whatever phase it happened to align to)

The schematic above shows the functionality.

The design is clever, I do feel that it could probably have been implemented in a simpler way, but it's a good example of a fairly sophisticated control system implemented using the then modern 4000 series of CMOS logic.

The Issue

After doing some analysis of the circuitry and probing the video and tachometers, I determined that the video sync pulse should be 90° off the phasing tachometer signal.

I made a test loop recording that contained nothing but synchronisation pulses, allowing me to quickly start/stop the fax to test the sync circuitry.

I had good tachometer pulses, and good video sync pulses, but the phasing circuitry appeared to only apply a slight fixed speed offset (1% faster) instead of adjusting the frequency to lock.

Probing U33 (the head pulse divider), I found no activity whatsoever, this should be receiving tachometer pulses. Tracing back, I found U30 pin 2 was stuck low, this is the small Schmitt trigger inverter that drives the tachometer signal to the phase accumulator latches and frequency divider.

I also found another inverter output in the same chip that seemed bad, but this didn't seem to affect the primary function.

Lifting pin 2 and shorting the pad to pin 1 (bypassing the inverter), I immediately saw the phasing circuitry start to operate! Since the tachometer pulse polarity was now wrong it locked in slightly offset, but this was repeatable, which is a good sign.

Above a looped recording was played two times, showing repeatable results!

A replacement 4584 hex Schmitt trigger inverter has been ordered, and is expected to fully correct the issue. A 4069 non-Schmitt inverter is installed temporarily, and functioning quite well.

I had noticed some occasional phase glitches during poor signal reception previously, I now suspect this issue may have been caused by the failure of the phasing circuitry. This may have been left partially active, allowing it to occasionally try to phase even after it should have terminated.

What Do The Potentiometers Do?

The front panel potentiometers are in fact the horizontal adjust feature. Measuring the Stylus Correct strap during operation made this pretty clear.

The way it works: during printing, the 4066 switch cycles through each potentiometer in turn, applying the potentiometer voltage to the speed reference signal (which is normally crystal locked by the speed PLL).

This applies a dynamic speed shift, shifting the phase temporarily. This allows fine adjustment of the three heads in the horizontal direction without bending the styluses around.

What's It Like?

Very cool, everyone loves weather faxes.

The NAGRAFAX is an early 1980's weather-fax printer, sold as a kit along with a weather-fax FM receiver and intended for marine use. I picked up this unit for $10 at a local auction (first and only offer, surprisingly).

Overview

The NAGRAFAX was manufactured by Swiss company Nagra Kudelski (I believe these are two separate companies working together). Nagra is fairly well known for making tape machines, and I guess making a fax machine is not too big of a stretch.

The manual indicates this unit entered the market in 1980 (Crypto Museum says 1977), and was likely sold for some time after. Surprisingly Nagra still provides schematics and mechanical alignment information on their official website, though the quality of the scan is not exactly great which made some things hard to work out.

Above the machine is shown without the plexi-glass front cover, and with a modern LED strip replacing the two light bulbs that would normally (poorly) illuminate the printer area.

The fax machine is housed in a two-piece aluminium chassis with various gaskets. I/O is via two 9-pin D-Subs, which have port covers providing some weather protection.

The power supply for the fax is approximately 13 V and up to somewhere near 30 V, making it easy to power. The current consumption in operation is typically less than 200 mA average at around 14 V. The paper advance stepper motor pulls a further 300 mA or so when active.

This fax can still be used with a suitable demodulator and radio in 2023, and for European users DWD (Pinneberg, Germany) and GFA (Bracknell, UK) are still on the air every day on multiple HF frequencies.

The specific unit was the property of the Norwegian Meteorological Services communications department. From what I have learned, these units were installed at various sites such as airports which had use for meteorological data. In this use case they were connected to telephone lines rather than radio receivers, and provided with video data that way.

At the time of initial publication, only the low resolution scans from NAGRA were available, making repair challenging. I have since recovered original copies of the schematics for the fax and HF receiver. See Nagrafax_Schematics.pdf (~150 MB!)

Principle of Operation

The fax machine was primarily meant to be used with a "FAXDM" HF/VLF receiver, which was a crystal controlled receiver that generated the video signal for the fax, as well as providing some signal monitoring capabilities beyond just looking at the print.

Unfortunately this receiver was not available.

Printer Mechanism

Above the print heads and drive chain are shown, the mechanism is fairly unusual these days. The printer uses special aluminised paper, which seems to be a laminate of aluminium over dark paper, not dissimilar to old school candy wrappers.

The printing mechanism selectively darkens the paper by striking an arc between the print head and the paper, this vaporises the aluminium layer, exposing the darker paper below. This paper seems to be fully waterproof and no ink/toner is required, both would be a benefit when operating at sea.

The printer came with some spare paper, I don't know if it's possible to get any more.

This process deposits vaporised aluminium all over the machine, which made it quite messy after probably 10-20 years of operation seemingly without any cleaning. Surprisingly this dust doesn't appear to be conductive, so even with the electronics covered in dust they still worked.

Control Circuitry

Above the rear of the machine is shown after some compressed air removed most of the dust. The right-most circuit boards are stacked and hinged allowing for service. They are documented in the manual and contain the video amplifiers, servo drive, and logic state machines.

The logic seems to be entirely 4000B series running at 10 V, in mostly ceramic packaging indicating high cost. The left-most circuit board is discussed below. Capacitors appear to be almost exclusively military-grade silver-tantalums, which are not great capacitors but as far as I know these are not known to fail.

Weird connectors are used, they use a retention screw with micro-D like contacts only much much bigger, and the PCB side of the connector is simply a set of sockets with no shroud.

The center motor is the chain drive motor, which is a standard brushed DC type. There is magnetic tachometer feedback from the chain drive, which is used to close the speed loop of the receiver. A stepper motor is used to drive the paper advance, and there is a paper-empty micro-switch that disables the machine if it runs out.

I don't fully understand all the circuitry, but it seems the chain speed is crystal controlled through some complex circuitry. This circuitry presumably ensures that the scan speed is well defined, and implements automatic phase control, which means that it tried to "center" the image based on some initial synchronisation pulses. The three potentiometers on the front do not appear to be in use when the crystal synchroniser is enabled, and I'm not sure exactly what they would do in any case.

Note that WEFAX does not use continuous synchronisation, the printer has to run at the right speed, and it's not uncommon to see the image "slant" due to small frequency errors. The benefit of not synchronising continuously is that no matter how poor the signal is it can't lose what it doesn't have.

The above image shows the first real-time on-air fax I received, the signal quality was not particularly amazing but the image can clearly be seen even if the text can't be easily read. This particular image was received using my 3021N receiver and the optical Mini-Whip, received from DWD at 3855 kHz. I have found that 7880 kHz is a better bet during the early evening.

Speed Detect

After receiving the start tone (or if manually set to an IOC), the fax will start looking for phasing pulses. The fax signal will stay at black for some time, sending white pulses during the blanking interval.

The fax appears to perform an automatic alignment of speed based on this signal, the circuitry is not very well explained but I think I have a story here:

• Initial search, speed is minimum (no speed control signal set)
• An operational amplifier circuit thresholds the video signal to generate an external phasing reference
• The period of these pulses is measured in a 4 bit counter circuit relative to the internal crystal oscillator
  • The output is routed to a set of digital comparators
  • When one finds a match the associated speed is set unless the found speed is inhibited
• The speed control signal bus is then valid and the process can continue
  • The counter circuitry is stopped if any speed signal is set
  • The speed control bus is used in several places around the fax, especially in the scan motor drive system
• The circuitry is shown below

The circuitry to the bottom middle generates a control signal that enables automatic phase alignment of the receiver. This circuitry is activated when the STOP signal is released, which occurs e.g. when a start tone is generated, or when manually started.

Below is a typical 2023 transmission, showing the phasing sequence lasts approximately 30 seconds. The fax seems to be configured to turn off the phasing system slightly before the 30 second mark, at this time whatever phase it locked to will be used for the remainder.

See followup article, the unit was defective at this time.

Phasing & Speed Control

The system that controls automatic phasing and crystal regulated speed is… complex. At the time of original issue, I had not yet worked out all the details of this circuitry, but I had worked out that the automatic phasing system was not functioning in my unit.

Measurements on this system will be the subject of future work to try to make the automatic phase alignment actually work reliably, since right now it seems mostly useless.

Controls

The front panel controls are limited to a set of speed and IOCs (Indices of Compliance), manual phasing, illumination control, and a manual stop button. Modern red LEDs indicate the current state. A potentiometer controls the video contrast; I can't say that I've found it particularly significant.

To manually start, select an IOC, then optionally select a speed (not required if the video input is in the initial phasing stage).

DIP Switches

The DIP switch functions are listed in tabular form below:

The disabling of modes is likely meant to be used to prevent false-detection of modes in automatic operation. I did observe it try to use 90 LPM for a 120 LPM signal in one case, and for most uses only one or two modes will actually be utilised. My unit came with 90 LPM already disabled, which suggests this was a common issue.

Bar Graph

My unit does not have the bar-graph, but this is shown in the available schematics. This was likely added in a later revision of the front panel PCB. I annotated this circuitry below, based on the hookup it appear to be intended as a tuning aid, showing the current video level.

It is shown in use in this video from 'The Fixman':

Printer Alignment

The internal test pattern generator is good for alignment of the print heads in the scan direction, run it at 60 LPM and you'll see if any heads are misaligned and note which head colour to adjust.

Above shows my alignment sequence, you can see the sequence, ending in a somewhat decent printout of of a DWD chart footer that I used as a reference test image.

The heads are coloured red, yellow, and blue. Alignment of scan direction error appears to be via bending the stylus with pliers, I couldn't find any better way of doing it. Perhaps as mentioned above, the stylus dynamic correction potentiometers are intended for this purpose? I didn't try this alignment method, but will investigate further in future.

See part 2, the potentiometers do affect the head-timing, so this is the preferred adjustment method.

Below the key components of the head are shown, the stylus is retained by a small pin and a spring, it can simply be pulled off for replacement. The azimuth adjust is done by loosening the flat head set-screw, and rotating the shaft above it.

As received my unit had extremely worn down styles (styluses?) that were basically flats instead of points. Since Nagra doesn't appear to stock spares anymore, I ended up using a diamond cut-off wheel to "sharpen" them into new points. This procedure makes them a fair bit shorter, so I had to realign in the scan direction. Since the new points weren't fully on point I also did the vertical align, which went pretty well.

Above a comparison between unaligned and aligned quality is shown; the vertical striping was later improved further with a better demodulator design.

AM Demodulator

My unit came with what appears to have been a factory fitted optional extra board, and included a sticker noting that an internal (transformer isolated) AM demodulator was included. This suggests the unit was used with something other than HF WEFAX or similar, and I'm not entirely sure what that would be. The AM input can apparently have any center frequency between 1.5 and 5 kHz.

Above is the result of using the Twente webSDR FM demodulation mode, and feeding that into the AM demodulator. It looks awful, but this was the first comprehensible image I made. Feeding the FM signal into the AM card produced unreadable results, so it's clearly made for some other format.

Below are pictures of the board, there are various test points, probing these I suspect the board implements a synchronous AM demodulator of some sort. This is mostly based on the fact that I found a recovered square wave carrier signal on one test point.

The ICs found include: CD40107 NAND gate, MC14538 monostable multivibrator (oscillators perhaps), MC14001B series logic gates, MC14053 analog switch (maybe a mixer), MC3303 quad opamps, and an MLM2901 (a LM2901 comparator?). The ICs are all dated 1980.

The two LEDs are automatic level control indicators indicating high/low AF levels, and there is a potentiometer accessible from the side which adjusts the output DC offset (i.e. image brightness).

Best guess would be it's a line type interface, it was probably connected to a phone line via some interfacing circuitry provided by the state telecom provider. As for why they would use AM instead of FSK, who knows. Probably comes down to cost.

The Nagra schematics don't mention this board at all, and from the way it was installed it looks slightly retrofitted, the board mounting is completely different from the standard cards and looks somewhat unsteady.

FSK & Video Format

The NAGRAFAX uses unusual but not entirely insensible video levels of 2 V p-p centered at 5 V DC. The video is positively modulated, so 6 V is full white.

The video is in fact analog, which surprised me. For weather charts a binary digital signal would suffice but the almost identical PRESS-FAX was used for both images and text, and I have printed PRESS-FAX recordings successfully with reasonable photography quality.

The NAGRAFAX supports analog video levels, but the video levels appear to be quantised to 8 discrete levels in the video drive circuitry.

The signal is conventionally transmitted as analog FM radio in a ~3 kHz HF channel. It is tempting to call this FSK, but it is as mentioned analog FM with some special characteristics. Current on-air stations use ±425 Hz deviation with positive modulation (and IOC 576/120 LPM).

Documentation suggests VLF fax transmission was done in the past (with ±150 Hz deviation). The only specific VLF transmitter I know of is CFH, Halifax Canada, but according to an article from MONITORING TIMES in 2011 these services have been shut down.

The bandwidth is limited to 3 kHz, and knowing the ~1 kHz deviation I figured 1 kHz of video bandwidth would be fine (following the rule of thumb ∆f+2fu=bandwidth). This certainly works, but the actual signal bandwidth is around 3 kHz or so, and the demodulator needs to support this to make finely printed text readable.

Some start/stop sine tones are normally transmitted, these are detected by the fax machine, and allow it to (in principle) operate unattended. I didn't have any false starts, but I found that when conditions were poor the machine often misses both start and stop signals, so I had to manually control this.

Lacking an application specific fax radio receiver, I did it the normal ham-radio way and use an SSB radio to offset-tune the signal. By convention the offset to the nominal center frequency is 1.9 kHz, though I went with a round 2 kHz because I'm special.

FM Demodulation in an ADAU1701

To actually demodulate the signal, I implemented an FM receiver in an ADAU1701 DSP board. This choice was driven largely by the effort needed to put a 4046 on a bread-board vs. using the ADAU1701 based board I had sitting around already.

This board has a high-level audio output that was easily modified to operate DC-coupled. This way the DSP board could plug directly into — and be powered through — the NAGRAFAX accessory port without additional interfacing circuitry.

The demodulator design is somewhat novel, at least doing it this way in this DSP. Previously I had used this one weird trick to demodulate without atan(), but I found it hard to achieve the required video bandwidth and linearity needed for good quality prints.

My alternate design is not ground-breaking, but is simply a digital implementation of a quadrature tank demodulator.

The principle is to do the usual filter + thresholding of the FM signal, then we feed one branch into a 1st order all-pass filter tuned to the center frequency, and multiply this with the non-filtered signal.

The all-pass filter will yield a phase shift proportional to frequency (leaving amplitude unchanged), and by multiplying the shifted and non-shifted signals, the D-C component of the result is the phase difference between the two signals. Two filters are used, the second filter provides a mostly fixed phase offset for convenience.

Since the phase shift shown above is proportional to and fairly linear vs. frequency, the result is that the output voltage becomes proportional to the signal frequency.

A low pass filter must be used to remove the frequency-sum term from the multiplication. I implemented this as a 10th order inverse-Chebyshev filter, which has somewhat poor pass-band linearity but extremely high stop-band attenuation. This allowed me to place the cut-off very close to the harmonic contents.

The nominal usable bandwidth of the demodulator is limited by 2⨉f_l where f_l is the lowest input frequency of the FM signal. A future improvement could be to mix the 2 kHz IF to a higher frequency before demodulation to move the sum frequency further away from the pass-band.

A modification to the basic scheme was implemented, where I placed a 2nd order low-Q (~0.5) peaking-filter tuned to the center frequency between the thresholding and the actual demodulator core. This seemed to improve the effective bandwidth of the demodulator, and I suspect that in practice this cuts out a lot of the lowest input frequencies, alleviating the frequency sum problem mentioned above.

This demodulation scheme was quite easy to set up, is relatively efficient, and with some tuning it significantly outperformed the more complex atan()-less solution linked above. It should be noted that the fixed point processing of the SigmaDSP may have played a part, and that this demodulator does not need to be particularly linear, only particularly fast.

webSDR Playback Woes

The original Web SDR (The Twente!) has some practical issues with doing real-time radio fax reception.

The real-time playback uses buffers, and I found that the sample-rate of the computer I was using was almost certainly slightly off from what the webSDR service supplies.

This lead to frequency "hunting" during playback, the audio would normally e.g. play slightly too fast. This will lead to buffer-underrun at some point, so when the browser starts running out of samples it slows down (probably down by '1' sample rate unit).

This slower unit is too coarse though, so then it starts filling up with excess samples, and it goes up '1' sample rate unit again, and now it's too fast again!

Radio fax doesn't use synchronisation pulses per line, the transmission is "phased" on startup, either automatically or manually by the operator. Once this is complete, the fax machine runs at whatever rate it's been calibrated to (under crystal control). In the case described above, this leads to very obvious steps in the horizontal alignment of the image, and this case was pretty extreme.

Ordinarily this error would simply lead to a slanted image, which is normally acceptable if annoying, and this could be calibrated in the fax machine if it were a recurring issue. An example of a slanted image is shown below, from a PRESSFAX recording.

The good news is that the recording functionality of the Twente webSDR works beautifully, supplying glorious uncompressed wave data that can be played back at a steady (if perhaps slightly incorrect) rate in e.g. Audacity or foobar 2000! The  prints shown in this article were mostly printed from files sourced this way.

Below is a segment of such a recording, showing the spectral content vs. time. The relatively high bandwidth is shown, and this bandwidth is proportional to the frequency content of the signal. This case shows mostly empty lines, with text near the middle of the recording.

Future Work

I will likely remove the internal AM demodulator, and replace it with a new custom board containing an ADAU1701 demodulator.

One neat idea is to use e.g. an ESP-32 to drive the printer with synthetic images directly, allowing it to act as an image-printer. This would require additional effort, but in principle all that's needed is to generate start & phasing tones, then scan out a bitmap at a suitable rate.

As noted above, the phasing circuitry is complex, and there are indications that it remains active for longer than the current duration of sync pulses. If this is true, then a modification will be attempted to reduce the phasing time to less than 30 seconds. Failing this, I may have to find some way to increase the phasing circuitries loop gain.

I may also look further into the dynamic stylus correction feature to determine if this is intended to correct horizontal head offsets, since I didn't initially try this method.

The two previous have been implemented in part 2!

Adding a bar-graph circuit to show the video levels would be fairly neat, the bar graph  can be fairly trivially retrofitted to show video levels in real-time.

I am also considering adding some type of phasing-aid circuit. My thinking is that adding a bi-color LED and driving one from the internal phase-reference pulse, and the other connected to the video signal (active when white) could be sufficient.