Most of you who see this post will have seen the original UNIAC post before this, and hopefully some will have seen the post detailing the hardware. For those who haven’t, UNIAC is a Raspberry Pi based Spotify playing boombox that is controlled with buttons on the front and displays status using Nixie tubes. This post will cover the software used to make UNIAC work — both tools developed by others and the software I wrote myself.
While I am writing this from the perspective of documenting UNIAC, the software could be pretty easily recycled to work with any display and buttons, you’d just have to rewrite the display and button event functions to support your hardware.
Also note that I did a major ripup of the UNIAC software after the original post, so this version does not use Mopidy, MPD, or Mopidy-Spotify. And if any of you have used those tools before, you’ll understand that’s a good thing.
I will start with a disclaimer however: I am an electrical engineer, not a software engineer, so this design will probably make software guys sick to their stomach. Sorry in advance…
Third Party Software
The first thing to understand about the architecture used in UNIAC is that control and playback of music are two separate processes. Raspotify is a software package that connects to Spotify and makes your RPi act as a Spotify endpoint. Essentially a dedicated speaker. There are a couple of similar packages that can give you a Spotify client on a RPi, but Raspotify has a trivial installation process:
curl -sL https://dtcooper.github.io/raspotify/install.sh | sh
The second part, Spotipy, is a Python library that you give permissions on your (paid) Spotify account. It allows you to see current playback status, and control playback on your Spotify devices (computers, speakers, etc). By combining these two, you can have a full Spotify instance running on your device with programmable control.
The two pieces are connected by the UNIAC Python script. UNIAC sets up a spotipy connection and then controls what device the playback occurs on. Since the name of the UNIAC Raspotify instance is constant, it simply has to tell Spotify to playback there, and music will play on the UNIAC hardware. This has the added benefit that I can ‘cast’ whatever I’m currently listening to over to UNIAC and it will just continue to play.
UNIAC / Spotify control.
The last piece worth mentioning is eSpeak, a relatively primitive speech synthesizer that takes strings from the command line and announces them. This lends UNIAC its characteristic robot voice when announcing settings information and playlist names.
Hardware Libraries
Path between the controls, the Display, and UNIAC.
The hardware interfaces are pretty straightforward, mostly. The buttons are controlled by an i2c GPIO expander, and Adafruit has the MCP230XX library to support it. For other GPIO, I use RPi.GPIO.
The last, and most unique library is the NixieDisplay library. It is a custom library that I developed to communicate with my Teensy 3.2 based multiplexing, crossfading Nixie display. In the first prototype, I used Taylor Edge SmartNixie modules instead of my custom display, so I also wrote a library supporting them on the RPi, though I’m not using it on the finished version.
These libraries are pretty straightforward. You print numbers to the tubes to display and forget about it.
The VU-Meter only has an audio input, so it doesn’t have any software control and doesn’t appear on any of these block diagrams.
UNIAC Software Architecture
The UNIAC software is essentially an interrupt driven button handler. There is a master ‘Menu’ class in Menu.py to which arbitrary ‘Modes’ are attached. An attached mode must provide a function handler for each physical button as well as a display update handler (and a few other helper functions).
When a button is pressed, the Menu object calls the current Mode’s handler for that button.
Button Press Event
The UNIAC.py script creates a Menu instance and attaches the modes defined in that script. The modes (currently) are: clock, track time, date, alarm clock, change playlist, and options.
Modes attached to Menu in UNIAC.py
For instance, when the ‘Plus’ button is pressed in the track time mode, the menu object will use Spotipy to progress to the next track, but when ‘Plus’ is pressed in the alarm mode, it will advance the alarm time by one.
The ‘Mode’ button is a special case that does not call an attached handler function but instead changes the selected mode in the Menu object.
The Menu object also requires that each mode have a display update handler. This handler is called by the master UNIAC.py script in an infinte loop to update the display every 100 ms.
Display Updater
This code was actually based off of another (unfinished) project of mine which used two buttons and a character LCD. By changing the displayUpdate function and the button handlers, this script could be used for virtually any menu interface with multiple ‘pages’.
Interfacing with Spotipy
As discussed in the preceeding section, UNIAC is controlled through a series of button handlers. To interface with Spotipy, most of the modes used in UNIAC inherit from the mpdGeneral class.
mpdGeneral class definition
This class has a few static variables and references the globally available spotipyLogin.sp object, which is an instance of the bare Spotipy API created by the spotipyLogin.py script. It includes things like track status, play, pause, loading a defined playlist from URI, listing available playlists, et cetera.
The UNIACConfig class allows settings like alarm time, current playlist, and settings to be pickled to a config file and loaded on restart. The other classes (including the option menu mode) use this class to handle i/o to the settings file, ‘UNIAC.conf’.
UNIACConfig class.
The remainder of the classes are more or less straightforward implementations of their self explanatory modes and hook the various parts and pieces together.
The last piece of secret sauce, which is not on git, because it is in m gitignore is spotipyLogin.py, a simple script which holds my Spotify login credentials and makes a logged in Spotipy object available.
The redacted version of spotipyLogin.py
UNIAC Supervisor
Finally, there is a UNIAC supervisor script. This is an independent Python process which checks if the UNIAC script is running and if not launches it. It also checks that only one instance of the script is running, and if a second copy has started somehow, kills all but the first process. It’s not strictly necessary, but is a nice-to-have feature. I ran without it for years, with only occasional failures.
UNIAC supervisor script.
Conclusion
The UNIAC software is a combination of several bits and pieces of code which allows a button driven paged menu system to control the Spotify web API and stream music for plaback locally on the RPi, as if it were a commercial product. The interface is ideally suited to a ‘Nixie Boombox’ but could be used with any oddball display you wanted with a little modification.
After sharing my last post on Reddit and Hackaday, I’ve gotten lots of kind feedback — and I deeply, deeply appreciate it all. More than anything else, it makes me regret not sharing this project with you sooner.
That said, the biggest ask has been for a detailed build guide. Unfortuantely, I didn’t document the build process in enough detail to write up a step by step guide, and I just don’t have the energy to build an entire new copy right now.
What I can do, however, is share discuss the design choices I made and share the build files. This post will focus on the hardware design of UNIAC, and I will follow it with a post detailing the software in greater detail.
Schematics
The schematic capture and layout was done in Eagle, and broken out into pages. It’s not perfect, by any means, but it’s clean enough.
Anyway, let’s go through the sections.
Raspberry Pi, Buttons, Sound Card, Amplifier
This section has:
The Raspberry Pi itself — note that the footprint says “Raspberry Pi Model B+”, but is actually sized for the Pi Zero W. I recycled an existing symbol because the header pinout is the same across both versions of the Pi, and simply forgot to rename it in Eagle. It also specifies a 7805 5V regulator to power the Pi off the input 12V bus. In practice I used a drop in switch mode replacement for the 7805 from Murata.
The button interfaces — supports two options to connect buttons. The first one, Buttons A, is for directly connecting to the motherboard. I used this option in the first two prototypes and decided to keep the option open here in case the button breakout board had problems, since I had the board space. The button connections here include a provision for +12V to illuminate the buttons, a shared switched ground line to control button illumination, resistors to pull up the buttons and caps for debounce.
Buttons B is a header for the button board, shown later. It breaks out the I2C bus connected to the RPI as well as a 3.3V rail for powering an offboard IC and a 12V rail for powering button illumination. Finally it has an interrupt pin so that the Pi can detect when the button board needs to be polled.
The next page of the schematic is a direct copy of my IN-13 VU Meter circuit. I won’t go into a full description of the theory, but it uses a quad rail to rail op-amp to save parts (I usually populate with an LMC660), and MPSA42 high voltage small signal transistors to drive the IN-13s. There is also an ATTINY85 micro running this code to make it act as a log converter. This saves parts and board area vs an analog implementation as well as allowing the VU meter to go to sleep if there’s been no audio for a couple of minutes.
Nixie display section
The third page of the schematic covers the Nixie display. This design was inspired by Dave Jones’ (of EEVBlog) Nixie tube driver design, which attempts to save transistors by using multi transistor ICs. Ultimately, I’m not very happy with that part of the design as there seems to be enough leakage that minor ghosting is visible on the tubes. I’ll definitely revisit it for my next Nixie project.
The controller for the display is a Teensy 3.2 which accepts commands to display values on the Nixies and INS-1 neon lamps via I2C and supports crossfading between digits.
Button breakout board
Finally, The button board uses an I2C GPIO expander IC to provide the same functionality as the individual button headers shown earlier, but without having nearly as many wires. The downside is that it requires an extra IC to do the job, and once the buttons are in the case, they’re soldered to the PCB and are pretty much stuck for good.
Layouts
The UNIAC mainboard layout is pretty compact. There’s not too much to talk about. Most of the size was defined by the need to have the Nixies at the top, bargraph tubes in the middle, and buttons at the bottom. Except for the routing around the Nixies themselves, there were no space constrained areas. I did choose to put the Teensy and RPi near the edges, so that their USB ports were practically accessible, however.
UNIAC Mainboard.
I went to great lengths to calculate minimum creepage distances and trace widths, which I used as design rules to ensure the Nixie display would be safe while being as small as I could make it. When routing my HV traces, I assumed 200 V DC and used a calculator like this one. I ended up using approximately 16mil or 0.4mm as my minimum trace clearance.
Closeup of the HV nets for the Nixies.
For trace width, I used 4PCB’s calculator, and found that even 600 mA would only cause a 10˚C rise for a 6 mil (0.15 mm) wide trace, way more than any of my HV traces were going to carry.vI also chose to keep the ground plane far away from the HV areas for added safety. Given that the Nixies are multiplexed and connect to ground only at a few points, it made sense and decluttered the design.
Finally, we go to the ‘Button Board’. The front panel control buttons are mounted to the front of the case and then soldered to this PCB. It’s a fairly simple design, but it has a couple of notches to clear the standoffs that mount the mainboard and speakers to the case.
Button board.
The biggest pain about this board was getting it fabricated. The buttons have wide pins that need to be fabricated as small slots. This is because the pins are so wide and closely spaced that large enough circular holes actually overlap each other.
It took three tries to get the boards fabricated. I had to make sure that the slots were on the correct layer in the footprint and had to specifically reach out to the PCB vendor in advance to ask them to send checkplots to confirm that the board would get fabbed correctly.
The first order was from AllPCB without asking in advance and they simply milled the small circular holes instead of slots. The second time, they promised that they would send me checkplots, but just fabbed the board without doing so. They also ignored my customer complaint.
It was at that point that I switched to PCBWay, who provided checkplots as requested, but they actually had the slots correct on the first try, resulting in great boards. My only regret is that their matte black soldermask is slightly shinier than AllPCB’s so the boards don’t quite match the mainboard.
The bill of materials, that is, the list of all the components used, is fairly long. It lists all the components that go on the main board, as well as the button board, and all of the off board components that I could think of. Since it’s a big, ugly table, I’m just going to attach it as a csv. The major parts themselves are detailed in the first UNIAC post.
Making the enclosure was a blast. My workflow is terrible and costs me several pieces of plastic on each new design I come up with, to be honest. I design the acrylic pieces as 2D Inkscape images and handle the ‘3D Modeling’ in my head. It’s even lower rent than DaveCAD!
Front Panel. Bent along the red horizontal lines which are not visible in finished enclosure.Rear Panel. Bent along (Faint) dotted red vertical lines, which are not visible in the final enclosure.
UNIAC. The non-portable 2015 UNIAC prototype is lurking in the background…waiting.
Introduction
What is UNIAC? It is the Ultimate Nixie Internet Alarm Clock. It’s a Nixie alarm clock / boombox.
It uses a Raspberry Pi to stream music from Spotify.
It has integral IN-13 VU meters to visualize the music.
It’s got a robot voice to relay information that the Nixies cannot.
It’s got clickety light-up buttons on the front.
It’s got a translucent clamshell case made of smoked acrylic.
It’s a piece of the future that never was. In short, it’s cool.
Motivation and Background
My First Nixie Display
I built my first Nixie Clock in 2006, which worked, but I was never satisfied with the design. I soon began fantasizing about what my dream Nixie clock would look like. It would replace my dusty old RadioShack alarm clock.
Unfortunately, life got in the way. The project got shelved, and grad school came along, but the idea hung in the back of my mind. By 2015, the technology landscape had changed and my hands on electronics skills had grown. I had new options, and came up with a new plan using a RaspberryPi. The ultimate Nixie clock would have:
The cheap LED alarm clock that motivated me.
Clock
Alarm
Calendar
Spotify as the music/alarm source
To tackle this relatively complex project, I decided to break it into parts. After tackling each subsystem individually, I had a reliable, tested circuit and was able then to integrate them into a unified system.
Two Builds
The first version was built in late 2015. It was a cube of laser cut acrylic sheets with the various subsystems mounted to an internal backplane with standoffs. The internal structure was built from square 3/8″ dowels which held the sides together. This version has served well on my electronics bench since it was put together, but it always bothered me that it was extremely cumbersome to open up and service. Additionally, the acrylic backplane was just inelegant.
UNIAC 2015: Front viewUNIAC 2015: Rear view. I never got around to fabricating the back panel.UNIAC 2015: Top view with the lid off. Inside can be seen the backplane and the rails it slides into.
In 2019, with this in mind I decided I could do better. I integrated all of the components (except the front panel buttons and speakers) onto a motherboard. With a single board, I decided on a boombox form factor. This version isn’t really a good fit for a bedside alarm clock, but it is extremely satisfying.
UNIAC 2019, in the boombox style clamshell case.
To enable this, I built an acrylic bending jig, and designed a clamshell case to hold it all. The case was made from two pieces of laser cut acrylic. The back panel is solid black to keep ambient light out. The front is smoked grey and hides the electronics but lets the Nixie goodness shine through.
Acrylic bender on the bench with a piece of test plastic (and the rev of UNIAC 2019 mobo in the background).
Getting the acrylic bent at the right spot took a few tries — the first test (using cheaper clear plastic) put the bend too close to the button cutouts. This caused the holes to deform and become teardrop shaped. I still think the clear case has a cool 90’s feel to it, but that doesn’t fit my general design tastes, so I stuck with the plan to go to a smoked front panel.
UNIAC 2019: First test enclosure.
After a couple of revisions, the final two piece enclosure came together nicely. I was worried that lifting the unit by the handle would cause the acrylic to flex, but it’s actually reasonably sturdy. I might consider some additional brackets to more firmly attack the front to the back in the future. For now, I think mounting the two haves together through motherboard standoffs is sufficient.
UNIAC 2019 showing the clamshell case open, with the motherboard and button board.
The VU-Meter
The IN-13 Vu-Meter as a standalone module.
When audio is playing from UNIAC, it really needed to show some “activity” — something like an oscilloscope would work, but in keeping with the Nixie theme, I decided to use the IN-13 bargraph tubes to display the sound levels on the left and right channels. No digital trickery here, the module takes analog line-level audio as a passthrough and displays the amplitude level of the audio channels on its IN-13 bargraph tubes. I’ve seen lots of mono IN-13 VU-meters, and I’ve seen a few standalone modules, but I’ve never seen them combined with normal Nixies before.
While I originally designed the VU-meter module intending to use it as a drop in component in UNIAC, the circuit has seen more service hours as a standalone module in my hi-fi (it’s been in near-constant use since late 2015). Nonetheless, it looks great in its intended role as a component of UNIAC.
I described the design of this component in detail in a series of previous posts, which includes some theory, design decisions, and schematics.
The Nixie Display
Because UNIAC is a media player, it needed a general purpose addressable Nixie display, not just a Nixie clock module. This part of the project was actually the first I began to tackle, back in 2009. I had nearly finished a display module using an 8051 and written in assembly, but stopped work when I went back to school. With cross-fading and all sorts of neat features, it was more or less what I wanted, but it had minor ghosting issues that I was unwilling to tolerate. Therefore, version one (2015) used Smart Nixie modules from Taylor Edge with a modified backplane.
Nixie display using a Teensy 3.2 developed for another project.
For the final version (2019), I based the design off a four tube Nixie display module using a Teensy 3.2 I had built for another project. When I finish that project, I will describe it in detail in a post. Until then, you can see the prototype at the right. The chief advantages to this design are a reduction in cost versus six Smart Nixie sockets, and the ability to integrate it onto the new motherboard without using risers. The UNIAC version of the display supports six tubes and uses IN12As, but is otherwise broadly the same design.
Input is via USB serial, TTL serial or i2c inputs and supports both dimming and crossfading.
Admittedly, multiplexing by 6x instead of 4x leads to a slightly dimmer display than the previous Smart Nixie approach, but it’s good enough. If there’s a future build, I’ll likely split it up into two banks of three tubes to increase the brightness (at the cost of board area and complexity).
The Motherboard
With the Nixie display circuit and the vu-meter circuit validated, it was time to build a full system.
Version 1, built in 2015 prototype was a ‘wired together modules’ build. Using a laser cut backplane, the various modules were mounted to both sides with standoffs. The backplane then slotted into a cube made with an internal wooden frame covered with laser cut panels. This design worked well, but the rats nest of wires made it an absolute nightmare to open up and work on.
For the final version, I decided I had to replace the backplane board with a PCB. The new motherboard would have an integrated copy of the Nixie display and vu-meter circuitry. A footprint The Raspberry Pi, audio DAC, and amplifier would be on board as well. It would take 12V in, and the only off board connections would be the speakers and to the front panel buttons. Because all my peripherals used serial interfaces, the actual board design was actually pretty sparse, and most of the work was in routing the traces for the Nixie display in a way that maintained sufficient creepage.
UNIAC 2019 motherboard front view.
Taking a look at the front side of the motherboard (above), it’s primarily the cosmetic components. We see the six IN-12A tubes, eight INS-1 neon bulbs, two IN-13 tubes. Also of note are the unpopulated pads along the bottom for connecting the buttons directly to the RaspberryPi, which are unused in this build in favor of the i2c button board (described in the next section).
A Tour of the Motherboard
On the back side of the board, we can see a ton of components.
UNIAC 2019: Motherboard back view.
Next, in green with a raspberry symbol, is the main CPU, a RaspberryPi Zero W (hereafter RPi), which is the core of the system.
To the right of that is a rainbow ribbon cable going off to the button board.
Next, at the right is a TES-1364H boost module. This provides HV for the IN-13s. It is twinned with another -1364 at the top right, which provides HV for the numbers. I chose to keep the two supplies separate not because I was sure I was out of current, but because the two sets of tubes call for different striking voltages, and I didn’t feel like adjusting the values of the two display circuits to compensate. In a future revision, I’ll absolutely address that.
The group of components just right of center are the components for the IN-13 display, which are described in more detail in the IN-13 VUMeter posts, but the two DIP ICs are a quad op-amp and an ATTINY85.
The two tiny green three-pin boards are Mu-rata OKI-78SR modules. These are more efficient drop in replacements for the classic LM7805.
Connected to the sound card is a blue Adafruit class-d amplifier board at the bottom left. It was chosen because it is relatively low-noise, has a mute pin, and can use an external pot for volume control — here you can see the wire for the pot running off to the knob on the side of the rear panel.
Finally at the top left is a Teensy 3.2, the CPU for the Nixie display module. This is gross overkill to drive a display, but it was convenient to code up quickly, and I was able to set it up as an i2c slave, simplifying communication with the RPi.
The Button Board
Clicky momentary 12V buttons, sourced from eBay
For the control panel interface I chose some clicky 12V illuminated momentary buttons that were intended for industrial applications. Very satisfying. They were about $1.30 per each, so not cheap, however. Given that the buttons are the main user interface, having something that satisfies the retro vibe satisfactorily was worth it.
The 2015 version used a single GPIO pin on the raspberry pi for each button, and used a single GPIO (through a FET, obviously) to switch the lighting on them all on together. This, again, led to a tedious amount of manual wiring, so I designed a button board using a MCP23017 GPIO expander to connect to the buttons. The board itself is very simple, although I had the first boards manufactured by AllPCB, and they failed to route the slots, despite saying they’d confirm the slots with checkplots in an email discussion beforehand. This triggered my switch to PCBWay who correctly provided checkplots and produced the right board. I have been using them since, and who have treated me well — no they aren’t sponsoring me, I’m just pissed off enough at AllPCB to mention it, since they ignored my customer complaint that I filed after the fact.
The Battery Problem
Okay, it’s time for full disclosure, I’ve been calling this project portable, but throughout the build process I treated a battery as “something I would figure out later” — It turns out the BMSs are no joke, and there wasn’t much out there that would suit my needs. The fundamental problem is that there’s a large burst of current on power up, despite the fact that the overall system only draws a few hundred mA when fully up and running. I tried a few low cost boost converters and they all browned out before the system booted. As I wanted to share the portable UNIAC with my friends at PAX 2019, I ended up punting last minute and taping a 12V battery pack from Amazon to the back of the unit.
Music Playback
To play music, I am using the command line media player Mopidy and its Spotify plugin, Mopidy-Spotify. This requires a premium Spotify account to work, and is brittle. The API Mopidy-Spotify uses is not supported anymore. I’ve found that the repo fails to load my playlists unless I use the fork mentioned in this thread.
Getting the audio itself to work was also a massive pain, as the various Linux audio subsystems like to fight as is, and the I2S audio card I was using made things more difficult. I could go into more detail here, but I think it merits its own post…
For the first version of the UNIAC with TES SmartNixie modules, I whipped up a quick python library to interface with them. It might come in handy for someone else, so I have published it here.
For the final version, I was using my own i2c display module, so I wrote a (nearly) drop-in replacement library for the SmartNixie library, so I could minimally modify the main UNIAC application to support the new display. It is published here.
It supports some fun features like dimming, cross-fading, blanking, and blinking.
The UNIAC Application
The main UNIAC application is a python script. The main loop probes the interface buttons and then calls a python god object, which maintains various states, drives the displays and voice, and sends audio commands to Mopidy. There’s a lot to this application, but that’s an entire post in and of itself. Until I get around to a full writeup for it, you can find it published here.
Conclusion
At the end of the project, UNIAC is probably the most satisfying hobby project I have yet made. Due to the brittle nature of the Mopidy-spotify, my next task is to move the Spotify interface to spotifyd, which I discovered due to reading Dino Fizotti’s excellent Diskplayer writeup. The other glaringly obvious improvement is adding a proper, internal battery system.
Longer term, I’d like to try to integrate it with a voice assistant to really supercharge interface, but that is more software work than I’m willing to take on in the immediate future.
The sad irony however, is that I’ve spent so long listening to the crappy buzzer of my Radio Shack alarm clock that I actually don’t want to give it up now. I’m conditioned to wake up to it quickly, and it takes up little space on my nightstand. Oh well. Maybe the next project will be a UNIAC Mini with an alarm buzzer feature.
I know this has been a long post. Thanks for sticking with me!
After all that work, I found that the lower “inerita” of the correctly connected tubes meant that the display itself had a twitchy response — the fix was simple, increase the capacitance at the VU-Meter node. I simply replaced the 0.1uF ceramic caps at the peak detector stage with 1uF electrolytic. Since this is a single rail design, that shouldn’t be a problem.
Additionally, since the tubes need 5mA instead of 10+ to go full scale, I replaced the 220Ω control current limiting resistors with 1kΩ resistors — the trim pots now sit most of the way to 0Ω instead of most of the way to 500Ω as well.
The final change was going back to a 10kΩ linear taper potentiometer, instead of a 50kΩ log taper part. This was done because I found that the 50kΩ part was simply too sensitive. On normal signals I’d encounter in real life, the pot stayed turned way down anyway. I had used 10kΩ on the prototype and it just worked better.
So, with all that in mind, here’s what the final schematic turned out to be:
Figure 1: Final schematic.
I like this one so much, I may put up a Tindie account and try to sell the stock of the modules that I have parts for. We’ll see if there’s any demand. It’d be kinda neat to have someone actually buy a part that I’ve designed.
Thinking on the matter, I suddenly considered the possibility that the tubes were wired backwards – that is, pins 1 and 3 were reversed. The thing is, I was sure I had tested it when I was in the breadboarding phase of the project — there were no markings on the tubes, but I found that if I connected them the other way, the neon glow did not attach to the bottom of the tube, resulting in a floating, glowing bar in the middle of the tube, instead of a nice controlled bargraph.
Figure 1: A tube with a floating glow (top) as opposed to a normally functioning tube (bottom).
Connecting them the way I had caused the tubes to strike and stick to the bottom of the tube and march upward reliably. This had to mean that the tubes were wired correctly, right? The fact that I was driving them with 10mA instead of 5 was probably just an artifact of their age.
… or so I reasoned at the time.
Facing dying tubes, I decided to re-evaluate that conclusion. Reviewing the IN-13 datasheet, I noticed that it did indicate a “pin one” mark, even if I had been unable to find it. Looking at my tubes closely, I found a tiny daub of paint that might be a “pin one” indicator, as seen in figure 2. And if it was, it meant my tubes were backwards.
Figure 2: Indicating mark.
I desoldered my tubes and flipped pins 1 and 3, careful to keep a clearance between the awkwardly bent leads, as in figure 3. Powering the tubes on, I again saw a “floating” glow on one of the two tubes, but the other one stuck. Frustrated, I power cycled the tubes. Voila! Both tubes stuck and held. Power cycling them again, I found that every time thereafter, the tubes held correctly (even a few weeks down the road, I’ve only seen the floating glow one more time on power up, and it “snapped” back of its own volition after a few seconds).
Figure 3: Bent leads on flipped tubes.
What’s more, the tubes hit full scale very easily! Measuring, I found that 5mA was enough to drive them to full scale. What’s more, I found that the tubes had less “inertia” – that is, they seemed to change length more quickly and snappily.
The lesson: Believe the datasheet, and if something is out of spec, believe that it’s out of spec, even if it seems to “work”.
Also of note, on correctly connecting the tubes, the “auxiliary” cathode will glow on its own, something that is not seen when the tubes are connected backwards. Figure 4 shows the extra “bump” at the base of the tube when lit correctly. If you see no bump on your IN-13, you’ve got it backwards!
Figure 4: Secondary cathode properly illuminated. There is no visible notch if the connection is reversed.
One more post to go, where I outline the changes to the schematic, and share a final revised version.
About a month ago, I was watching TV. As usual my IN-13 VU-Meter was dutifully bouncing away with the dialog.
Out of nowhere, one of the tubes made a “tink” sound and the current control went away — the tube stayed ignited, but the “bar” was stuck at the bottom.
I noticed that the spacer at the far end of the tube was swinging freely, unlike the other, functional tube. Clearly, something had failed — it appeared that the IN-13’s control cathode had eroded and snapped. Chalking it up to a one-off failure, I dug into my spare nixie box and swapped out the tube.
About a week later, the second tube exhibited exactly the same behavior! This was not a one off, but an early failure mode of the tubes. While a year and a half of use seems almost acceptable, I had expected much more life out of these tubes. Suffice it to say, the game was afoot.
My first stop was the best Nixie forum on the internet, Neonixie-l. Given the circuit schematic and my description, they were as baffled as I was – these tubes generally last much longer than I had experienced.
Doing a little analysis of my circuit, the conclusion was that the most current my circuit could drive through the tubes was 10mA, which matched my own measurements. Unfortunately, the datasheet translated by tubehobby indicated that the maximum current through the tubes should be about 5mA. More current would shorten the lifespan of thetubes non-linearly, so some investigation was warranted.
To the bench!
Figure 1: The setup. Multimeter, Function gen, DC power supply. Not pictured, scope, second function generator with AM input.
Investigation steps:
1. Scope HV line (HV supply is TES 1364 module)
2. Multimeter on 220Ω shunt resistor to get I_control
3. Input AC Signal — steady 10kHz, varous levels
4. Input AC Modulation signal — 10kHz AM’d 100% depth, 1Hz
5. DC Signal Input — remove Microcontroller and input DC to 100kΩ resistor LPF before the voltage follower.
Results:
1. HV Line, no input signal: Mean = 143V, V_pp = 8V
2. HV Line, full scale input signal (1.8V PP 10kHz sine wave — to front end): Mean = 143V, Vpp = 9V
3. Measure control current full system, using AC signal input:
I_shunt, no signal = 1mA (micro is still here, did not scope micro, but I suspect it was putting out a small nonzero PWM value)
I_shunt, full scale = 11.5mA
4. Measure control current, DC injection to IN-13 driver:
Vin (V)
I_shunt (mA)
Col. Length (cm)
6
13.9
11
5
11.4
11
4.5
10.9
11
4
9.4
10
2
4.9
5
1
2.41
2.5
0
0.045
0.5
I also measured the current through the cathode resistor (220k in series with the non-control cathode to ground):
Vin (V)
I_cath (mA)
0
0.04
0.5
0.26
2
0.38
4.5
0.5
Under normal operation, the tubes will never see more than ~11mA, which is substantially higher than the 5mA expected max current to get the full scale, and these tubes have seen a many of hours of burn in.
Figure 2: 5mA, should produce full scale.
Figure 3: 10mA, actually produced full scale.
Also noteworthy here was that the striking voltage is above the max. Taking a closer look at voltages, the voltage between the anode and the indicating cathode when the tube is at 0 scale is 111V. When I drive it to full scale, it rises to 139V. Reading the aforementioned datasheet correctly, the 0 scale drop across the anode to indicating cathode should be at max 99V – it was out of spec but not grossly so.
The only thing I could think to do is adjust the HVPS to be drive them at a lower voltage (120V), but my recollection from when I breadboarded this was that they did not strike reliably below about 140V.
Stay tuned for the realization, the follow up and the fix!
The IN-13 VU Meter is a ‘Nixie’ neon bargraph tube based VU-Meter. It takes stereo analog audio as an input (via a 3.5mm passthrough) and displays the audio amplitude on the tubes. It is not a true VU-meter, as it is not calibrated, but it does do proper log conversion to give a realistic representation of ‘perceived’ loudness.
Figure 1: Final VU-Meter without enclosure.
Background
Several years ago, I discovered and subsequently became fascinated with Nixie tubes, whose warm neon glow stands in rather stark contrast to the sterile feel of modern LED displays. A few years later, I was speaking to my academic advisor about such things, and he introduced me to the IN-13 bar-graph tube. This three terminal tube works on the same principles as a Nixie, but instead of individual discrete segments, it has a continuously variable single column of neon light. His suggestion was an all-analog VU-Meter. I set to the task, and breadboarded a VU-Meter circuit with the log-converter using a diode in the feedback loop of an op-amp and a few buffers. It worked, but it wasn’t as clean or adjustable as I would have liked, so while I had laid out a PCB I never went to the trouble of actually ordering it. The design did have a homebrewed 555 based high voltage power supply (HVPS) though, which was a fun build.
I shelved the project and didn’t touch it for years, although I did occasionally ruminate on the subject. When I finally came back to the topic last month, I had settled on a design that used an 8-pin microcontroller (MCU) in lieu of an op-amp based log converter. This had several advantages:
I could adjust the gain and offset of the log conversion without changing any hardware.
I could add simple moving averages or other low complexity signal processing algorithms if I so desired.
I could use the GPIO of the MCU to shut down the HVPS (conserving the tubes and energy) when no sound was detected for a few seconds.
I also opted to use a Taylor Edge HVPS as they had come down in price to under $14 and supplied more current than the cruder and larger 555-based circuit that I had built could offer. Armed with these design decisions I set off to build my VU-Meter.
Design Process
With a microcontroller system in mind, the key elements to build an IN-13 driver – the key being signal specifications for all stages were in place. To maximize the performance of my MCU, it needed a 0-5V input signal and a 0-5V output from the controller’s PWM pin. This allowed the use of a garden variety Arduino Uno for breadboard prototyping with a switch to an ATTiny85 (thanks to Sparkfun’s convenient programmer) for the final system.
Pre-Amplifier
The first stage calls for a pre-amplifier to drive a peak detector circuit before the MCU. By putting the peak detector before the MCU, the bandwidth that the MCU needs is lowered from ~20kHz to the desired time constant of the output bar graph (<10Hz). Pre-amplifying the signal also guarantees that it is substantially larger than the 0.6V drop of the peak detector diode. This means that the system only requires a simple diode rectifier as opposed to a more complex precision rectifier. Figure 2 shows the input pre-amplifier and peak detector.
Figure 2: Power supply, input amplifier, and peak detector.
Figure 3: Input protection circuitry and ATTINY85 microcontroller
Figure 4: Output drivers.
Microcontroller Signal Processor
This conditioned signal feeds into the ADC of the MCU, where the MCU count is converted to a floating point 0-5V range. That voltage is then passed through the equation:
Vout = 6.2log10(Vin+1)
This provides a 0-5V log converted output. That output is in turn converted to an 8-bit integer and used to generate a PWM signal on a GPIO pin of the MCU. Figure 3 shows the MCU circuitry.
Tube Drive
The next stage is a low pass filter to convert the PWM to a constant voltage to drive the tubes.
The final stage of the system is a simple op-amp wrapped around a high voltage tolerant NPN transistor (MPSA42 or 44 do nicely). Figure 4 shows the PWM low pass and tube driver stages.
Current drawn from the middle pin of the tube controls the IN-13’s bar graph length. By setting the emitter resistor of the MPSA42, one can set the current pushed by the transistor. Placing that node inside the feedback loop of an op-amp goes one step further and removes the diode drop of the Vbe junction of the transistor.
One surprising thing found with these tubes is that the specified striking (ignition) voltage is 140V – that is the voltage you need to apply to get the tubes to illuminate at all, but the high side voltage had to be raised to 146-150 volts to get the tubes to reliably strike on power up. Additionally, the datasheets for the IN-13 all specify a full scale control current on the order of 5mA, but I found that I had to drive them with 11-15mA to get them to reach full scale. There may a design error here, but it seems that age may have something to do with their behavior as well.
PCB Design
After finishing the breadboard prototype the board was laid out in eagle added a few simple safety features were added. Firstly, there is a high pass filter (AC coupling) with a pole around 10Hz to the input, before the pre-amplifier (Figure 3). This guarantees that any damaged parts cannot cause stray voltages and damage source device. Additionally, AC coupling guarantees that the input signal was centered on 0V, protecting the VU-Meter and preventing DC bias from causing clipping. The op-amp itself is used to clip the negative half wave and rectify the input signal. Again, this is for simplicity and increased dynamic range. A more conservative design would bias the input signal to half scale before pre-amplification.
1n4001 protection diodes were added past the AC coupling to guarantee that large input voltages would not damage the quad op-amp used for all my signal stages (Figure 3 shows this protective circuitry as well as the high-pass).
The design choice of a ground-centered input on a single supply system required that I use a rail-to-rail opamp. The schematic lists the TLV274, which I did not have on hand or test, but was conveniently in my eagle library. I grabbed the amplifier I had handy, an LMC660, which is also a rail-to-rail component.
The MCU got some ADC input protection resistors as well. In the event of an overvoltage, the ADC has protection diodes tied to the power rails (much like the input stage of the system), adding a resistor in front of the ADC doesn’t change the input impedance of the ADC much but protects these diodes from overcurrent (also shown in Figure 3).
Finally, potentiometers allow for adjustment of control currents and the HVPS (Figure 2), as the PCB can’t have resistors casually swapped out to tune the tubes the way the breadboard prototype could.
Manufacturing, Assembly, and Enclosure
After a quick search for the cheapest board manufacturer (pcbshopper), ten boards cost $40 shipped from Accutrace (PCB4U) and the results were excellent. Compared to an advanced circuits prototype run (previously the benchmark for US made low cost boards), the Accutrace boards have a shinier solder mask and appreciably sharper silkscreen – one can clearly make out the smallest reference notes on the board, unlike the smaller, more expensive batch from Advanced Circuits.
Assembly
The only caveat with the boards as they came back was a footprint mistake, which was due to user error. The board had a modified Sparkfun footprint for the Panasonic dual gang potentiometer used to control gain for the preamp (Figure 2). Fortunately, after judicious use of a Swiss Army knife, the design was salvaged and the PCB layout was modified for future runs.
Calibration
Calibration was fairly painless. The MCU enabled another handy feature – the system tests the tubes at power up by linearly progressing from zero to full scale. For actual tube adjustment, it is simple to input a test tone, using a tool like online tone generator and sweep from zero to full scale, then use the sound card to pan the balance left to right.
Additionally, testing revealed that despite using a 12V supply for breadboard testing (it was handy), the design has plenty of headroom with a 9V supply, and works just fine.
Enclosure
Using Inkscape for design and an Epilog laser cutter for fabrication, an enclosure was built. It consists of two sheets of smoked acrylic; these create a “sandwich” with the board in the middle using standoffs. The smoked acrylic transmits the orange glow of the tubes nicely, while masking the circuitry from a distance. The result is a floating vu-meter effect (Figure 5). The back panel of the enclosure also has picture hooks cut into it to allow the meter to be mounted either vertically or horizontally on a wall.
Figure 5: Board in acrylic enclosure.
Conclusion
The final project works well and looks absolutely gorgeous sitting on top of my home stereo. It works great as a standalone device but I fully intend to include a few of these into larger projects as integrated VU-Meters.
