I have been using a (DIY) integrator for a while to get consistent exposures on my alt process prints. Recently, I grew unhappy with the buggy nature of the device I had built, so I made a new version using stuff from the parts box.
The overall arrangement is simple and also not fundamentally changed compared to the previous version. There’s a control box that switches relays connected to incoming 230V, and thus can toggle a 230V-powered light source. The switching can either be done based on time setting (x seconds) or on the basis of input from a UV sensor. When using the UV sensor, the device continuously monitors the UV irradiation of the print frame surface and cuts out the exposure when the set amount of total irradiation is reached. There’s some buttons, a rotary encoder and a simple display by means of a user interface.
There were several things I wasn’t happy with in the old device:
- The display was crap. I used a dual display setup with a 7-segment display for the seconds or UV units (this was fine) augmented with a Nokia 5110 dot matrix display for system settings. The latter suffered from inconsistent contrast due to minute power supply fluctuations, and it was suffering from the ‘too much info’ syndrome. More simple = more better.
- There was a pesky little bug I never bothered to fix in the 7-segment display driver, which resulted in a number ‘1’ remaining in a certain position when it shouldn’t be there. No biggie, but minor annoyances are annoyances all the same.
- The rotary encoder sucked, which was in a large part due to the device itself. This particular unit too easily skipped beats. Just annoying.
- Most importantly, the sensor interface was absolute crap. I opted to interface with the ML8511 UV sensor through an I2C analog-digital converter (ADC), using a flexible UTP network cable to connect the sensor to the control box. Looks nice on paper, but an absolute nightmare in reality as I2C really isn’t intended to be run over such a hardware interface. So the sensor would disconnect and reconnect all the time, sometimes even interrupting exposures as they were in progress.
- The hardware platform was too complex for what it did; I made a contraption involving 3 or 4 separate PCB’s arranged in a modified housing. The net result was that in order to reprogram the device, I’d have to do too much work with the screwdriver, and as a result, I never fixed the minor software bugs that made use of the device an overall miserable experience.
So one day about 2 weeks ago I decided it was time to destructively decommission the device, while salvaging some of its parts for future reuse. Which, of course, also meant that I had to build a new one. And a better one, at that, preferably.
I chose to simplify matters in some regards, and expand functionality in another. As to the latter: the previous device was a single-channel unit that controlled a single light source. For DAS carbon transfer, I’m presently using two separate light sources with different wavelengths to optimize highlights resp. shadows. I wanted to get rid of some of the manual switching between these light sources, which resulted in mishaps once in a while. So I made the new integrator device capable of controlling up to 4 separate channels without having to physically flip any switches.
To tackle the display issue, I dug out a generic 24×2 HD44780 compatible display I had bought for a different project. I turned out to have automatic contrast control (which I only realized after finishing the hardware) and a quite pretty red backlight with excellent readability even in daylight conditions. Nice!
The old device was built around a Microchip ATMega328PB microcontroller, which I programmed in Arduino. For the new version, I went for a still quite low-end, but much more capable STM32F030C6T6 – again, a parts-box find. I realized later on that this device has no EEPROM that can store variables between power cycles. If needed, I can always use program flash for that, but for now, I opted to just keep it simple and have the device start up with its default parameters every time.
I reused the ML8511-based sensor unit and its flexible network cable, since I was actually quite happy with that arrangement – apart from the communication problems. I worked around those by forgetting about the I2C ADC and instead just pass the analog output of the ML8511 over the network cable and use the internal ADC on the STM32 microcontroller instead for data acquisition. I played with the thought of making this a 4-20mA current loop, but decided against it just to keep things simple. I did end up enhancing the analog frontend on the controller side a little with a basic R/C filter and a series pass resistor, which I stupidly forgot to include on the PCB design.
I kept a rotary encoder for data input (but used a different part) and added 4 push buttons for quick & intuitive channel selection. There’s a couple of LEDs to make the whole thing look nice; I can blink those during exposure and use them to show which channel is selected. There’s a buzzer to make noise – and
The power supply consists of the scavenged 230V-5V tiny SMPS and a simple linear regulator to make the 3.3V logic supply. I had all sorts of arrangements to have the LCD run on 4.5V to compromise between good contrast and meeting input logic levels on the unit, but the thing turned out to work just fine with 5V and 3.3V logic levels, so I bypassed that part – and as mentioned, the LCD apparently had automatic contrast control anyway, so I didn’t have to bother about that, either.
Since I only needed to build a single device and I hate waiting for something to arrive in the mail, I chose to DIY the PCB, so I could have the finished hardware in my hand a day after finishing the engineering. Ironically, I had to expose the UV resist on the new PCB manually, since I no longer had my working timer. Ah well, timing isn’t that critical and I can count to 20 alright.
I could have programmed the thing in Arduino, but really…let’s not. The “STM32duino” core is really an abstraction layer on top of STM32’s own Hardware Abstraction Layer, which in itself is already a rather high-overhead, memory-hogging piece of bloatware for a simple application like this. I once tried the Arduino approach on this microcontroller for the densitometer project, but ended up embracing STM’s low-level libraries and the STM32Cube IDE with a passion. It’s efficient, fast and proper debugging (instead of clunky/kludgy ‘serial prints’) makes life so much easier.
Most of the time I spent on writing the software for the device, in particular the low-level stuff. I wrote a simple library to control a HD44780 display (gleaning some ideas from existing libraries on GitHub). As usual, I went for a buffered display driver that I can just output data to in the main program without having to worry about actual display updates, excessive communications overhead etc. I just have the display driver refresh the display periodically and only whatever has changed. This keeps things fast and fluid.
The buttons and particularly the rotary encoder are interrupt driven routines that feature software debounce (on top of R/C hardware debounce circuitry). And I’m happy to say that this works exactly the way it should – the encoder doesn’t miss a beat and just feels right. Rapid turns of the knob are interpreted as large steps, so it’s easy to go from, say, a setting of 100 to 1000 units while making it just as easy to go from 100 to 110.
As for a pretty housing – I just, well, didn’t. After having thought about 3D printing bezels and mounts, I ended up just bolting the damn thing to the wooden frame of the existing exposure unit alright. It’s not like this needs to hit the market, and this way, I can easily access the programming header if I want to fix some software bugs (which so far I’ve not yet found – knock on wood!)
The final result won’t win any beauty contests. The previous version actually looked a whole lot better – but the present one is so much nicer to work with that I frankly couldn’t care less. It also takes up less space as it’s now integrated into the actual exposure unit. I’m only using two out of four channels, but I’m thinking about adding at least one small LED-based light source for pre-flashing carbon prints (a very effective way to preserve delicate highlights).
Well, does it work? Sure does! Here are two prints I made just now – a classic cyanotype using the 365nm light source only, and a ‘variable contrast’ 395+365nm DAS carbon transfer. Both 4×5″ negatives of the same scene, but processed differently:
I might actually transfer the carbon print to paper (it’s on its transparent temporary support, hence the low contrast) – it came out quite nice for a test with guessed-at exposure.