Introducing the Printalyzer!

The Printalyzer is a new project I've been working on for several weeks now. It aims to become a modern full-featured darkroom enlarger timer and exposure meter.

 

What is it?

At its core, this is a timer for a darkroom enlarger. That means it has a switchable outlet on the back, and can turn an enlarger on and off for a set amount of time. However, it is going to be far more sophisticated than a simple clock. Its going to allow the adjustment of exposure time in "stops," making it what is known as an "f-stop timer." That means you adjust time in logarithmic units of exposure, rather than linear increments. Here's an article that attempts to explain the concept.

Of course it'll also include features to help with making test strips, and calculating dodge/burn exposures in stop units as well.

In addition to all this, the device is going to include an exposure metering probe. This probe will let you measure and visualize the contrast range of a negative before printing it. The idea is that you can figure out a fairly decent choice of both contrast grade and exposure time, without even making a single test strip.  Of course you still can make the strip, but it becomes more about fine-tuning than making your initial decisions.

Why are you doing it?

Why have I chosen to take on this project? Don't similar devices already exist? Well, technically they do. Several, in fact. You can find everything from polished commercial products to crowdfunding campaigns to homebrew hobbyist projects.

Okay then, why am I bothering?

Well, in short, I've found myself growing increasingly frustrated with what is currently out there.

Most of the commercial products in this space are quite expensive, and were designed and built in the mid-to-late 1990's. While they do work, they tend to suffer from all the limitations of "built to cost" embedded devices from that era. This often means a limited user interface that can be difficult to use without constantly referencing a manual, firmware that is difficult or impossible to update, features that are constrained by the capabilities of an 8-bit microcontroller, fixed peripheral choices, and a general lack of new development work.

Many of the more modern projects tend to forget things that made those old devices great, like a sturdy case, real buttons, and a no-nonsense primary interface. They also sometimes try to do too much, such as attempting to be a general purpose darkroom timer. Finally, its rare that they tackle the exposure metering problem.

 

What are your project goals?

Basically, to take what I like from those older products and to bring it up to date with more modern embedded technology.

Fundamentally, I like to think of this project as building a platform, rather than a static appliance.  Sure, its going to have all the necessary hardware to be an enlarger time and meter. However, its also going to have enough excess capacity so that it can be continuously updated to increase its functionality.

My goals for the Printalyzer include:

• Use real buttons for the user interface, and have enough of them that the need for awkward combinations is minimized. A rotary encoder knob may be used where it makes sense, but not as a catch-all.
• Use a graphical display whose layout can be changed depending on the device mode. It can emulate the look of 7-segment and bar-graph LEDs when that makes sense, but it can also display nice menus for setting things up.
• Use a flexible interface for connecting the metering probe, such that the choice of light sensor isn't baked into the device. It should be possible to use different sensors as desired, simply by plugging in a different probe. While I'll initially focus on B&W metering, being able to function as a color analyzer is absolutely a stretch goal.
  
• Have enough program memory that all desired features can be implemented. There should never be a reason to need different versions of the device to offer different feature sets.
  
• Have enough user memory that settings and calibration profiles are not arbitrarily limited, and can even be accompanied with meaningful descriptions.
• Include a USB port, so that settings can be saved/loaded from thumbdrives. It should also be possible to use this port to connect to other peripherals. This could include keyboards, for typing profile names, or even densitometers to automate the process of creating profiles.
• Include a "Blackout" switch that turns off all illumination on the device, enabling the user to perform basic functions by relying entirely on audio cues. This will be of great benefit when doing color printing, where paper must be handled in total darkness.
• Able to run off all common mains voltages, without modification (except maybe a different fuse).
  
• All hardware and software for the device will be completely open source, so that anyone can build or modify it.
  

 

My anti-goals, or things I explicitly do not plan to include:

• It will not be a multipurpose darkroom process timer. That means no timing of film development. This timer is meant to sit next to the enlarger, not to be carried around and used for everything.
• It will not require any sort of smartphone app or computer interface to set this thing up. It should be possible to use the device as a completely standalone unit, where all of its capabilities should be locally configurable.
  

 

How will it work?

The device will consist of a main unit that looks somewhat like every other enlarger timer, and a connected metering probe.

 

 

Here's a basic block diagram that shows the main components:

The main unit has buttons, a display, illumination LEDs, a buzzer, and relays to control both the enlarger and the safelights. The metering probe has a button, to trigger readings, and a light sensor.

 

How far along is the development?

The first revision of all the schematics and PCB layouts are finished. I've constructed the first prototypes of the metering probe, and am in the process of constructing the first prototype of the main unit. Once that is done, I'll have to do a lot of testing and begin to write the software. Since this is all open-source, you can see the nitty-gritty of this work on Github.

As far as the theory and process of print exposure adjustment and metering, I've also done a lot of research to prepare for the project. In addition to what I can figure out on my own, it also helps that there are a lot of long-expired patents that go into a good amount of relevant detail on the subject. Additionally, I'm hoping I can make the calibration profiles for this device compatible with other existing devices, to make initial setup as easy as possible.

Will I be able to get one?

That is the hope. While the first prototypes are mostly for me to be able to tinker around with an enlarger timer/meter that I can reprogram myself, I would eventually like to make this into a real product. I'm not yet sure if it'll be a DIY thing or a complete constructed unit. Its also likely that there will be non-trival legal, regulatory, and manufacturing hurdles to make this happen. I'll also need to get the cost down, as nice-looking prototype enclosures can be quite expensive.

Nestronic Input Board (Part 4)

Introduction

When I designed the main board of the Nestronic, I was busy enough that I didn't want to hold up progress on account of other areas of the project. I basically just figured out what interface pins I might need for an input board, brought them out to a connector, and set that part aside.

I figured I'd need an I2C bus to interface with some sort of I/O expansion chip, and a few support GPIO pins. I also thought it might be neat to try experimenting with the ESP32's touch sensor capabilities, so I made sure at least one of the GPIO pins could be used for that.

(For more project background, please read the [Introduction], [Architecture], and [Prototype Assembly] blog posts.)

Building the Nestronic Prototype (Part 3)

(For background, please read the [Introduction] and [Architecture] blog posts.

Introduction

I eventually got to the point where the schematic was mostly finalized and the whole thing was working on a breadboard. While a big achievement in and of itself, it was far from a finished product.

First, breadboards usually look kinda messy. After all, they tend to evolve as you tinker with the circuit design. Also, breadboard wires are never the exact right length for any given connection. While you can make a clean-looking breadboard, it often requires far more time and effort than one is willing to put in for a simple prototype.

Second, breadboard connections are a little flaky. Breathing on your circuit the wrong way can cause this wire or that resistor to have just enough of a contact issue that something starts or stops working reliably.

Third, breadboards are noisy and full of stray capacitance. I could detect clock signals from one end to the other. Digital connections sometimes had just enough noise to make the difference between a high and a low. And to quote Dave Jones, you sometimes have to "hold your tongue at the right angle" to get things to even start up correctly.

Breadboard Nestronic

At this point I exported the netlist for my schematic, pulled it into KiCad's PCB tool, and began the layout and routing process. After a lot of work, I eventually ended up with a complete board design. The core of this layout was the NES CPU section, with all its parallel bus traces. The rest was kinda squeezed in around it. Perhaps not the most optimal of layouts, but good for the general size and shape of the enclosure I wanted to put it in.

PCB Layout

Nestronic System Architecture (Part 2)

(For an introduction to this project, please read the previous blog post.)

System Design

Now that the design of the system is mostly complete, I'd like to present it in a little more of a top-down fashion. First, I'll present a block diagram of the complete system. Then I'll go in-depth on how I arrived at all the relevant elements of the system. Finally, I'll show the detailed circuit schematics this all represents.

The design of the Nestronic consists of two major subsystems. First, there's the NES CPU Section, which builds around the RP2A03 CPU and contains everything necessary to actually synthesize video game music. Second, there's the ESP32 Microcontroller Section, which provided the front-end and completes the project.

Block Diagram

Building a Seeburg Wall-O-Matic Interface (Part 5)

Designing and Building the Circuit

This is where everything from Part 3 [Decoding the Pulses] and Part 4 [Inserting Coins] finally comes together into a complete circuit board design. Most of the work here actually took place simultaneously with what I've already described in those posts, so I won't rehash their respective elements. Basically, I did the overall design, then tested and proved out the individual elements on a breadboard, then put it all together into a final schematic and printed circuit board (PCB) layout.

Completing the Schematic

Early Iterations

It all began with a piece of scrap paper and a pencil... Starting with what I had seen on another blog posts about a similar projects, and adding in some of my own ideas about coin switch triggering, a rough schematic started to take shape:

The Pencil Sketch

At this point there were a lot of uncertainties and omissions. I hadn't yet figured out how I was going to filter the signal pulses, wasn't sure which relays I was going to use to toggle the coin switches, and apparently forgot that the relays would actually need a regulated DC voltage to trigger them. Interfacing a microcontroller was also something still far off in the future.

Not long after, I whipped out KiCad and started to layout a real schematic. I selected and tested components for filtering the signal pulses and driving relays to toggle the coin switches. As I proved things out on the breadboard in my lab, I tweaked the schematic until it ended up like this:

Early KiCad Schematic

Most of the components came straight from KiCad's libraries, but a few required some level of customization. KiCad didn't have any diode-protected relay symbols, so I had to make them. KiCad did have a ton of similar-looking rectifier bridge symbols, though, but it took a while to figure out which one best matched what I was using.

Of course, because of the constant changes, the wire routing quickly became a disorganized mess. At this point I decided to pull the various sections apart, and clean up the schematic.

I was also somewhat annoyed that the component for the 74HC14 (Schmitt trigger) didn't expose the power rails in any obvious way. This posed two problems for me: First, unlike many schematics, I had multiple power rails that needed to be distinct and separate. Second, I wanted an obvious place to put a bypass capacitor. Thankfully the newer KiCad libraries (via their Git repos) had redesigned the schematic symbols for this part, and now include a separate "unit" just for connecting power. So I kludged that library into my project, and forged ahead.

The microcontroller was still a bit of an unknown on the design, but I knew I was likely to need an isolated 3.3V supply for it. After some searching, I went ahead and threw in a DC-DC converter (NCS1S2403SC). It also required a custom symbol, albeit a rather easy one to create. The part was a tad pricey, and probably overkill, but it would do the job.

Design More Complete

(At the time I captured this iteration of the schematic, I had obviously forgotten to place a rectifier or any capacitors on the input of the DC-DC converter. I did remember to add those in later.)

Selecting a Microcontroller

Up until this point, I wasn't really sure what kind of microcontroller I wanted to use for this project. Other people have used Raspberry Pi boards, but I was fairly sure I didn't want to do that if it could be avoided. I really wanted something I could more tightly integrate, and that would be more purpose-built. Having a whole Linux system, complete with OS maintenance and startup/shutdown concerns seemed like overkill.

After watching a few too many EEVblog videos about a Nixie Tube Display Project, I became aware of this wonderful little Wi-Fi enabled microcontroller module known as the ESP8266. These modules are typically packaged onto surface mount carrier modules (which package the antenna, memory, and FCC certifications, etc). In Dave's project, he used a WEMOS D1 mini carrier board. This board packaged an ESP-12S module with a few necessary support components (USB port, reset button, etc) and a place to put pin headers.

Since I was unable to directly order that specific module when I was at this stage of design, I went ahead and instead ordered an Adafruit Feather HUZZAH. Its slightly larger, and has a few more support components I didn't really need, but is essentially the same thing. My intent was to use this module as a breadboard-friendly option for development and testing of the software, which I'll go into detail on in a future blog post.

For the actual board, however, I decided to just use an ESP-12S module directly.

Finalizing Revision A

The final step in getting the design ready was to include the ESP-12S into my schematic. Thankfully I found an existing KiCad part library that included the ESP-12E, which I could trivially edit into the part I needed. For the rest of it, I just looked at a variety of "getting started with the ESP8266" blog posts and various schematics for existing carrier boards. All I really needed was a few pull-up resistors, a reset button, a jumper for putting the thing into the flash download startup mode, and a pin header for connecting to the UART.

I didn't bother including a USB controller directly on my board, since it wasn't something I was going to need at runtime. Instead, I opted to just buy an external CP2102 adapter that I could plug in whenever I wanted to download updated firmware.

Eventually I ended up with this schematic:

Ready For Layout

Laying out the PCB

Finding all the Footprints

The first step towards laying out a PCB is making sure you have accurate footprints assigned to all of your components. Depending on what you're building, this is often a mixture of trivial and frustrating.

For the resistors, I knew I was going to use standard-sized "jellybean" 1/4 watt parts from my collection, so I selected reasonable footprints that made sense. (Of course KiCad calls this footprint "R_Axial_DIN0207_L6.3mm_D2.5mm_P10.16mm_Horizontal", so it did take a little bit of work to decide that was the best choice from the library.)

For the capacitors, it was a little bit more of a challenge. I had a collection of usable parts for many of them, but not necessarily of known dimensions. Just to play it safe here, I decided to source all of my capacitors from fresh Digi-Key orders using quality brands. That way I would actually know the specific dimensions of the footprints for each one.

The rectifier bridge used an unusual package type (WOG) that wasn't in the KiCad library. I managed to track down someone's library that contained the right footprint. Making sure the pins all matched the schematic symbol still took some effort, as this part doesn't actually have numbered pins.

The relays were the first fully "custom" footprint that I had to create myself. Fortunately, they were just trivial modification of a common package. I took a DIP-14, deleted the 3 middle pins on either side, and made sure the pin numbering matched up with my schematic symbol.

The DC-DC converter was also a custom footprint, and one that required a bit more work. I found an existing footprint for a similar component from the same manufacturer, and tweaked its footprint based on the datasheet for my component.

Thankfully the component library I based my ESP-12S off of also contained a footprint. I just had to make a few minor modifications to remove certain pins, and I was all set.

Getting it all routed

Now that I had all of my component footprint data sorted out, it was time to actually layout and route the printed circuit board (PCB). I soon discovered that KiCad's PCB designer is actually pretty bare in its choices for things like trace sizes, drill sizes, via sizes, design rules, and the like. Thankfully, I found a few excellent resources that helped me configure it for this project:

• PCB Design Tutorial put together by Dave Jones (likely before he started EEVblog)
• KiCad Design Rules from OSH Park (who I was planning to use for fabrication)
• Standard PCB Drill Size Chart (just so I wasn't pulling numbers out of thin air)

After spending an afternoon laying out all of my components, and routing all the traces between them, I finally had a PCB design!

PCB Layout (Revision A)

KiCad's 3D view was also pretty cool, and helped with keeping the actual look of the board in mind. I didn't bother creating or fixing any missing/incorrect 3D models, but its still worth showing off:

PCB 3D View

Fabrication Time!

Sending off to OSH Park

I had decided to use OSH Park for making my PCB, mostly because of how easy they make the whole process. I basically just had to upload my ".kicad_pcb" file on their website, and they did the rest.

OSH Park PCB Preview

Finding Design Issues

While I was waiting for the PCB to come back from OSH Park, I decided to spend some more time testing and analyzing my design. During this process, a few initial issues jumped out at me:

• The Zener diode I was considering as a voltage clamp on the output of the signal rectifier was a bad idea. It was based on a misunderstanding of a suggestion I saw on a website, and didn't actually work for my use case. This is the one element of the schematic I did not test before doing the PCB layout, and I really should have.
• The relays were connecting the coin switches to the Common terminal, rather than to 25VAC. This mistake can apparently be traced all the way back through every one of my schematics, even though my bench test breadboard was doing it right.
• The ESP-12S could use another button so I'd have a way of causing my software to start in a "setup" mode. Without doing this, reflashing would be the only way to recover from a broken Wi-Fi configuration.

The first two issues thankfully could be "patched" as part of the board assembly process. The third issue was something I could live with, but would address in a future revision.

Building the Board

After an uncomfortably long (but not really that long) wait, I got the manufactured board back from OSH Park:

Actual PCB (Revision A)

While assembling the board, I took copious notes. There were many things I wanted to verify due to upfront uncertainty, and many other things I discovered during the assembly process. If I was going to do another revision, I wanted to make sure I got all the kinks out.

Fully Assembled PCB (Revision A)

Issues discovered during assembly:

• Diode bridge (WOG) footprints had holes and pads that were almost too small. (I managed to make the parts fit, but it was extremely tight.)
• DC-DC converter's silkscreen was all wrong. (I expected this when I first figured out the footprint. Thankfully this one was just cosmetic.)
• DC-DC converter probably should have filter capacitors on its output. (Just in case.)
• Opto-isolator pins were a bit too wide, and took extra bending to fit. (It turned out I had ordered "DIP-4M" parts, whereas I used "DIP-4" footprints.)
• UART pin header (J3) had the +V and Gnd silkscreen labels backwards (Big problem if I hadn't caught it, trivial to work around now that I know about it.
• The board had tons of dead space, and was way larger than it needed to be.

After assembly, once I got the board working, I made another discovery. Apparently, my ESP-12S (ordered from Electrodragon) had only 1MB of flash. I had been led to believe that the ESP-12S comes with 4MB of flash, so this was quite annoying. Just to be safe, I decided that any future ESP-12S parts would come from another supplier that actually said 4MB on their product page (e.g. Adafruit).

Revision B

Okay, I'll admit that a second PCB revision is kinda silly for a hobby project like this. However, I was taking the design process for this project far more seriously than your average one-off hobby build. So what the heck...

Small Schematic Changes

I fed all the design changes from the previous sections back into the schematic, and arrived at a more "final" revision B:

Schematic (Revision B)

Compacting the Layout

I then spent some more time moving components around, and got the layout quite a bit more compact:

PCB Layout (Revision B)

Running the numbers, this turned out to be more than 8.5 square inches smaller than the Revision A layout!

Back to OSH Park

This time it was simply a matter of uploading and ordering. Since I has gotten the kinks out, I also felt confident enough to actually share the design:
OSH Park ~ wallbox.kicad_pcb

OSH Park PCB Preview (Revision B)

Building the Board

This time assembly was very straightforward. All the issues I had discovered in the last revision were resolved, so it was simply a matter of soldering in components.

Assembled PCB (Revision B)

Well, it was mostly simple. At least until I got to the ESP-12S module itself. This time I had the bright idea to attempt "proper" SMD soldering with solder paste. Everything seemed to go fine until I was actually ready to switch the power on... And it didn't work...

During the painful troubleshooting process, I discovered that all the pins on one side of the module were apparently shorted to ground. I tried reheating them with my soldering iron, using solder wick to clean things up, and even using a desoldering gun to suck away excess solder. Nothing seemed to fix the shorts.

I then had this crazy idea to point my ridiculously oversized hot air gun at the thing, in an attempt to reflow the solder. For a long time, nothing seemed to be happening. Then, out of nowhere, the whole ESP-12S module popped right off the PCB!

At this point I tested both the PCB and the module, and couldn't find any evidence of shorts. So I resoldered it the "old fashioned way," and it started working. Phew!

Since the ESP-12S module is not a "real" SMD part, but rather a surface-mountable carrier PCB, I suspect the PCB "sandwich" prevented the solder paste from correctly reflowing around some of the pins.

Bill-Of-Materials

One thing I made sure to do throughout this entire process, was to keep a detailed and accurate bill-of-materials (BOM) for the project. Initially I did this with a plain text file, but eventually I did the grunt work to move all the data into the KiCad schematic itself. The BOM included part descriptions, datasheet links, part numbers, and vendor information. This made it easy to use various companion tools to generate HTML or CSV versions for easy sharing and part ordering, and provided a handy reference during assembly and testing.

Bill-Of-Materials Snippet

Project Resources

• Complete KiCad project (Schematic, PCB Layout, etc.)
• Bill-Of-Materials (Generated from the KiCad project)