The Printalyzer Densitometer project is my attempt at building a new budget-friendly densitometer to make available to the resurging analog photography community. My ultimate goal with this project is to eliminate the cost and convenience barriers that currently stand in the way of many, who might want to try using such a device.
Its actually a project idea I've been kicking around for a long time,
but initially sidelined due to concerns over optics and calibration.
However, I've recently become motivated to revisit the idea.
Since I wrote my original introductory blog post on this project, I've made considerable progress. The first prototype is now fully constructed, and I'm making significant headway in the development of the firmware. As such, I think its time for another project update.
Given that the project is being developed entirely as open-source hardware and software, the latest schematics and code can always be found in the project's Github repository.
Main Unit Construction
The main unit consists of a rather large PCB, with a double-sided design. The reason it is large is that all the components and most of the ports of the Printalyzer are directly mounted to the board. The way I decided to do this, the board is actually mounted in the enclosure upside-down. This puts the buttons and display on the "bottom", while everything else is on the "top". I took this approach because several of the components are rather tall, and there wouldn't be enough clearance if they had to fit within the height limits of the buttons. From my teardowns of other pieces of darkroom electronics, this construction approach is actually quite common.
For the enclosure, I designed something using Front Panel Express and their housing profile script. While rather expensive for building in quantity, at the prototype stage this gave me very nice results.
For the top of the unit, I installed a piece of Rosco Supergel #19 (Fire Red) sandwiched between some transparent material in the gap between the top of the display and the enclosure. This both protects the display and keeps its output spectrum paper-safe.
Finding a nice metal knob for the encoder, without a pesky direction-mark, took some effort. Ultimately I went with a type of knurled guitar knob (from mxuteuk), which seems to be the magic set of keywords to find these things.
For the keycaps, I ultimately went with black. This was mostly because it was the only color for which I had all the necessary parts at the time, given that these are often backordered or special order with lead time. When looking at the unit on the desk, black also seems like the nicest choice. However, in the darkroom, they are hard to see. I also have these keycaps in dark gray, and they can be special-ordered in light gray. (Having that array of LEDs around the keys really helps, of course.)
Meter Probe Construction
The meter probe is a much simpler device. It essentially consists of a light sensor, a button, and minimalist support circuitry to handle power regulation and voltage level shifting. Right now the sensor I'm using is the TCS3472, which has well-documented lux and color temperature calculation guides and might be useful for color analysis as well.
(One benefit of my design here, is that I can make future versions of this meter probe using basically any sensor I want. The only requirement is that the sensor, or really just the front-end of this circuit board, has an I2C interface.)
Since the enclosure requires a somewhat custom shape, I had to go with 3D printing for this one. For the two prototypes I've built so far, one was self-printed and the other I had printed by Shapeways. The later looks a lot nicer, so that's what I'm showing here.
The hardest part of assembling this was probably the fiddly process of connecting the cable. For the cabling, I went with a 6-pin Mini-DIN connector. In practice, that meant finding someone selling M-M black PS/2 cables and slicing one in half.
One last thing this meter probe needs, is some sort of cover for the sensor hole. My plan is to have something printed/cut for me out of something like polycarbonate, from a place that makes panel graphic overlays. Ideally this overlay will be light in color, with markings pointing to the sensor hole. Thus far I've been putting off this part, but getting it in place is going to be essential to finalizing my calibration of the sensor readings.
Firmware Development
I'm now at the stage in firmware development where I have all the hardware inside the Printalyzer working, and have a stable base from which to build up the rest of the device's functionality. My initial goal here is to fully flesh out the functionality of a mostly-full-featured f-stop enlarger timer, then to later follow on with the exposure metering functions. I'm going about it this way because metering requires a lot of testing that's hard to do "outside the darkroom," and I'll need the timing functions regardless.
(In all the screenshots below, I apologize for the "gunky" picture quality. The red gel sandwich over the display tends to reflect a fair bit of dust, which ends up looking far more distracting in pictures than it does in real life.)
Home Display
The home display shows the current time and selected contrast grade. It also has a reserved space for the tone graph. While I have figured out what that graph will look like, its not easy to show here until I do actual metering.
From this display its also possible to change the adjustment increment, and obviously to start the exposure timer.
Another feature of the home display (not shown here) is fine adjustment. Using the encoder knob you can enter an explicit stop adjustment (in 1/12th stop units), or even an explicit exposure time. I expect this capability to be useful for repeating previous exposures, in lieu of re-metering.
Test Strip Mode
The test strip mode supports both incremental and separate exposures for test strips, and making strips in both 7-patch and 5-patch layouts. The design places the current exposure time in the middle, and then makes patches above and below this time in units of the current adjustment increment.
Another nice feature, made possible by having a graphical display, is that it actually tells you what patches should be covered for the next exposure. This way its harder to lose your place during test strip creation.
Settings Menu
The settings menu is fairly rough at the moment, and probably does need some user interface improvements. That being said, it shows another benefit of using a reconfigurable graphical display. I can show nice text menus that actually tell you what each setting is, and then return to a full-screen numerical time display when done.
Enlarger Calibration
This little tidbit is the first feature I've worked on so far that actually uses the sensor in the meter probe. Its not yet complete, from a user-interface and settings point of view, but the underlying process is fully implemented now.
The basic issue is that any enlarger timer is effectively just "flipping a switch." It can control when that switch turns on, and when it turns off, but little else. Unfortunately, lamps typically do not turn on or off instantly. On both ends, there is a delay and a ramp time. While these are typically short, not accounting for them can cause consistency issues with short exposures. This problem becomes especially troubling when doing incremental short exposures, such as with test strips and burning.
The goal of the calibration process is to make sure that the "user visible exposure time" is the time the paper is exposed to the equivalent of the full light output of the enlarger, rather than simply the time between the on and off states of its "power switch."
Calibration works by first measuring reference points with both the enlarger on (full brightness) and the enlarger off (full darkness). It then runs the enlarger through a series of on/off cycles while taking frequent measurements. When complete, it generates 6 different values:
Time from "power on" until the light level starts to increase
Time it takes the enlarger to reach full brightness (rise time)
Full brightness time required for an exposure equivalent to what was sensed during the rise time
Time from "power off" until the light level starts to decrease
Time it takes the enlarger to become completely off (fall time)
Full brightness time required for an exposure equivalent to what was sensed during the fall time
These values are then fed into the exposure timer code, and used to schedule the various events (on, off, tick beeps, displayed time, etc) that occur during exposure.
Using the above numbers as a rough example of what this all means, without profiling a simple 2 second exposure would actually expose the paper to light for about 2.4 seconds but only a 1.88 second equivalent exposure.
These numbers come from a simple halogen desk lamp, which is more convenient for basic testing. I've also run the same calibration cycle on my real enlarger. It takes longer to rise to full brightness, but is faster at turning off. (Its similar case is 2.2 seconds with a 1.78 second equivalent exposure.)
Now I'll admit this doesn't seem like much, but enlargers do vary and it
can suddenly become critical if you're making <1s incremental
exposures for test strips or burning.
Blackout Mode
This feature is a little "quality of life" nicety that I haven't seen anyone else do. Every once in a while, some of us want to print on materials, such as RA-4 color paper, that has to be handled in absolute darkness. This means once your enlarger is all setup for the print, you need to turn out all of the lights in the darkroom before taking out the paper. Having to manually turn off your safelights and throw a cover over your illuminated enlarger timer, gets a bit annoying.
This is why I added the "Blackout" switch to the Printalyzer! Flipping this switch turns off the safelight and all of the light-emitting parts of the device. Of course everything still works when in this mode, so you can still make prints and test strips in complete darkness. (Eventually I'll probably add additional audio cues and lock some ancillary features to improve usability.)
Next Steps
At the outset of this project, I collected a long list of "good ideas" for things the device should do. That list is still growing, of course. Eventually I will get to them, but right now my priority is to get the standard features implemented and stable.
I have a few more things to do for the basic f-stop timer functionality, such as burn exposure programs. After that, I need to work on an actual user interface for adding/changing/managing enlarger profiles.
Once these things are done, I'll finally move on to paper profiles and print exposure metering. I expect that to be a long-tail item, because it will require a lot of work on sensor calibration and learning about sensor behaviors. However, I plan to do as much this as possible via first converting raw sensor readings into stable and standardized exposure units. This way, it will be possible to experiment with different sensors (as needed) without dramatic changes to how the metering/profiling process works.
Another thing I'll likely do interspersed with this, is start to take advantage of the USB port I put onto the device. There are a few features I want to implement with this, including:
Backup/Restore of user settings and profiles with a thumbdrive
Firmware updates with a thumbdrive (right now it requires a special programmer device, which isn't practical for "end user" use).
Keyboard entry of profile names (I'll make sure they can be entered without a keyboard, but being able to use one is a nice thing.)
Connection to densitometers to help with paper profiling (not sure how this will work, but it can't hurt to try).
I'm still not sure whether, or at what point, I'll proceed with transforming this project into an actual "product" or "kit." The biggest hangup is really that the device necessarily plugs into mains power and switches mains-powered devices. That means it may be hard to safely sell/distribute units without first forming a company and going through various painful and expensive certification processes. However, I'm not going to worry too much about that until I have something rather complete.
Regardless, all the necessary data to build one yourself will always be freely and publicly available. However, actually assembling one of these does require circuit board assembly skills and tools everyone isn't likely to have.
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.
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.
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.
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)
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.
Last year we moved into a house that had some interesting touches left by a previous owner. Most notably, there was a "play room" decorated in the style of a 50's Diner. It had a booth, table, chairs, and plenty of decoration. We joked that this room's decor was what sold us on the house!
In any case, one notable thing missing from this room was a jukebox! Or at least, taking things slightly more sensibly, the jukebox controller that such diners often have sitting at their tables. It was at this point that I started learning all about the iconic Seeburg Wall-O-Matic.
Flash forward a year, and I was finally in the process of resurrecting my electronics workbench. I started watching a few too many EEVblog videos, built a shelf/bench setup using components from Ikea, unpacked all the gear I'd kept in boxes for a few too many years, and even made a few upgrades.
The one thing I desperately needed? Projects! Given that I knew I was going to have a lot of free time coming up in the near future, I reopened my research into the Wall-O-Matic and began to scour eBay.
Background Research
One of the first things I stumbled across were these commercial "products" designed to provide a modern interface from the wallbox:
Unfortunately, these projects were less than desirable for my tastes. I was also looking for a project, not an off-the-shelf solution. These devices also seemed a bit dated, of limited availability, and quite proprietary. They also seemed to focus on playback a bit too "locally," rather than using the wallbox as an actual remote for a real stereo system. My house had in-wall speakers installed in many rooms, including the "diner" room, and I really wanted to use those. Since I had already connected many of my in-wall speakers to a Sonos rig, I kept wondering if there was a way I could just use that.
The next thing I did was dig into these hobbyist projects which seemed much closer to what I actually wanted to accomplish:
One common theme among these projects was simplicity. Minimal components to interface the wallbox to a Raspberry Pi, and minimal work to control a Sonos system based on the result. They also provided enough schematic and component details to give me a tangible starting point. Even if I decided to take a different path with my own project, at least I had a good foundation to build upon.
Project Goals
So thinking through what I wanted to accomplish with this project, I decided I wanted to build a device that could do the following:
Provide power to the wallbox
Read the signal pulses, and decode them into a song selection
Enqueue selected songs with my Sonos system, simulating the functionality of a jukebox
Electronically toggle the coin switches, so that inserting actual coins would be optional
At a lower level, I also knew I wanted to take things seriously in the design of the circuit I was going to use to accomplish all of this. That meant:
Complete and detailed schematic
Complete and detailed BOM (bill-of-materials)
Real fabricated PCB (printed circuit board) design
(The BOM and PCB being things that I'd never actually done before. Every prior circuit of mine was a hand-constructed mess of wires on a pre-drilled pad-per-hole PCB. Thankfully, in this day and age, doing it "right" is now quite accessible.)
I'll attempt to break this blog series apart based on the major progression of this project. I may not discuss things in the actual order that I did them, since there was a lot of back-and-forth between the various elements. However, it should flow in an order that makes sense. Most likely it'll be something like this:
