VFD

Roger Cheng

Death Clock Code Organization

When we established our set of display states for the Death Clock project, we knew there would need to be a state machine somewhere in its logic to manage those display states. And when we designated different zones that can be composited together for a single frame in our display animation, we knew there would need to be some kind of animation engine in charge of corresponding work. These requirements formed our starting point for designing and organizing code for Death Clock.

The state machine was implemented as an infinite loop running an if/elif/else loop checking for our state value. Each clause corresponds to a display state and has (1) calls to code handling that display and (2) conditions to transition to another state. The state machine resides in a single class deathclock which also owns the reference to Pi GPIO library for display. It may make sense to split the I2C communication to another class but there’s no need to do so just yet.

Different display states require different operations to assemble their animation frame. An attempt to create a master animation engine capable of all operations became unnecessarily complex and was eventually abandoned. Instead, we’ll have multiple classes (nyancat, thinkingface, and deathtime) each of which will stay focused on the type of operations required for a single display state. This keeps the simple animations simple, and allows us to experiment with more complex animations without fear of damaging unrelated display states. This will result in some code duplication that we can come back to refactor later, but keeping each display state animation code separate lets us iterate ideas faster.

Code discussed in this blog post is available on Github.

Roger Cheng

Raspberry Pi GPIO Library Gracefully Degrades When Not On Pi

Our custom drive board for our vacuum fluorescent display (VFD) is built around a PIC which accepts commands via I2C. We tested this setup using a Raspberry Pi and we plan to continue doing so in the Death Clock project. An easy way to perform I2C communication on Raspberry Pi is the pigpio library which was what our test programs have used so far.

While Emily continues working on hardware work items, I wanted to get started on Death Clock software. But it does mean I’d have to work on software in absence of the actual hardware. This isn’t a big problem, because the pigpio library degrades gracefully when not running on a Pi. So it’ll be easy for my program to switch between two modes: one when running on the Pi with the driver board, and one without.

The key is the pigpio library’s feature to remotely communicate with a Pi. The module that actually interfaces with Pi hardware is called the pigpio daemon, and it can be configured to accept commands from the local network, which may or may not be generated by another Pi. Which is why the pigpio library could be installed and imported on a non-Pi like my desktop.

pigpiod fallback

For development purposes, then, I could act as if my desktop wants to communicate with a pigpio daemon over the network and, when it fails to connect, fall back to the mode without a Pi. In practice this means trying to open a Pi’s GPIO pins by calling pigpio.pi() and then checking its connected property. If true, we are running on a Pi. And if not, we go with the fallback path.

This is a very straightforward and graceful fallback to make it simple for me to develop Death Clock code on my desktop machine without our actual VFD hardware. I can get the basic logic up and running, though I won’t know how it will actually look. I might be able to rig up something to visualize my results, but basic logic comes first.

Code discussed in this blog post are visible on Github.

Roger Cheng

Display Zones of Vacuum Fluorescent Display

Now that we have a set of states for what to display on our vacuum fluorescent display (VFD) we’ll need to start dividing up the zones we’ll composite together to create the display at any given point in time.

The easiest part are digits at the center: core functionality is to display a time of day on four digits and the colon at their center. We might do something non-digital with them in other animated states, but we know we’ll show numbers appropriate for a time of day at some point.

To the left of those digits are the AM/PM elements, which will be part of time display. And as long as we’re display a time of day, we know only one of those two will be illuminated. They will never be both illuminated, nor both dark.

Above them are the days of week, and we know we’ll illuminate one and only one when showing our death prediction. Not more than one, and not zero.

Beyond these known zones, things get a little fuzzier. The ON/OFF elements are tentatively marked into their own zone, and the two rectangles above them in their own zone. The numbers 1 through 7 at the bottom will probably be their own zone, and finally off to the far right we have the “miscellaneous” section with OTR, CH, W, a clock face, and a dot. We have no plans to use any of them at the moment, but that could change.

Roger Cheng

Bit Operations For Death Clock Display

The way we’ve wired up our VFD (vacuum fluorescent display) control board, each segment on a VFD is a bit we can manipulate from the driver program. It can be anything that communicates via I2C and right now that is a Python script running on a Raspberry Pi. VFD pattern data in Python will be represented in the form of byte literals as outlined in PEP #3112. This is something we’ve already started using in existing Python test scripts. The ‘b‘ in front is how we designate this string as a byte literal. Each byte within is described with a leading backslash ‘\‘ and two hexadecimal digits. Each digit represents half (4 bits) of a byte.

Our VFD hardware board is wired so setting a bit high will ground the corresponding element, turning it dark. Setting a bit low will allow pull-up resistors to raise voltage of the element, illuminating it. This particular VFD unit has 8 pins for grids and 11 pins for elements. However, not all combinations are valid for illuminating a specific segment. There’s room blocked out for bits in our control pattern corresponding to these combinations, but they will have no effect on VFD output. For more details, see the VFD pattern spreadsheet where bits without a corresponding physical segment had their checkboxes deleted.

So far so good, and for Death Clock we will take the next step beyond showing a fixed set of static patterns. We’ll have to start changing bits around during runtime to do things like displaying the day of week and time of day. Manipulating our VFD pattern byte literals with Python bitwise operators allow us to take multiple bit patterns, each representing one subset of what we want to show, and combine them together into the pattern we send to the PIC for display. This is conceptually similar to compositing in video production, but at a much simpler scale.

Roger Cheng

Death Clock Display States

At this point we have decided on what the Death Clock project will do, established priorities of how we’ll go about it, and the hardware we’ll use for our first iteration. Now it is time to sit down and get into the details of what code we’ll write. This will be more sophisticated than just looping a single list of animation frames. Here are the candidate states in the sequence they are likely to run:

  • Initial power-on: As soon as the Python script starts running, we want to send a VFD pattern to establish the Pi is communicating with the PIC. This pattern doesn’t have to be fancy, its main purpose is to visually show our Python code has at least started running. So all it really needs to be is to be different from the PIC’s power-on default pattern.
  • Waiting to start: We might want a pattern to be displayed after the Python script has started running, but before we can act like a Death Clock. At the moment we don’t know of anything that require such a delay, so we’ll skip over this one for now.
  • Attraction loop: An animation sequence inviting people to touch the capacitive sensor button. Any text will have to be shown as a scrolling marquee of text using the four 7-segment digit displays. Might want to superimpose animations using remaining segments. This can start simple and get fancier as we go.
  • Thinking and processing loop: Once touched, we might want to do a little show for the sake of presentation. There’s no practical reason to need this as a Pi can generate a random time effectively instantaneously. But where’s the suspense in that? We don’t have to do this in the first test run, this can be added later.
  • Oracle speaks: Present the randomly chosen day of week and time of day. May or may not do anything with the remaining segments. This is the core functionality so we’ll need to look at this one first.
  • Thank you come again: Animation sequence transitioning from “Oracle speaks” display to “attraction loop”. This is again for presentation and can be skipped for the first test run and added later.
Roger Cheng

Raspberry Pi Drives Death Clock

Since this was the first time Emily and I built something to light up a VFD (vacuum fluorescent display) we expected things to go wrong. Given this expectation, I wanted to be able to easily and rapidly iterate through different VFD patterns to pin down problems. I didn’t want to reflash the PIC every time I wanted to change a pattern, so the PIC driver code was written to accept new patterns over I2C. Almost anything can send the byte sequences necessary — Arduino, ESP32, Pi, etc — but what was handy that day was a Raspberry Pi 3 previously configured as backup Sawppy brain.

The ability to write short Python scripts to send different bit patterns turned out to be very helpful when tracking down an errant pin shorted to ground. It was much faster to edit a Python file over SSH and rerun it than it was to reflash the PIC every time. And since we’ve got it working this far, we’ll continue with this system for the following reasons:

  • The established project priority is to stay with what we’ve already got working, not get sidetracked by potential improvements.
  • Emily already had a Raspberry Pi Zero that could be deployed for the task. Underpowered for many tasks, a Pi Zero would have no problem with something this simple.
  • A Raspberry Pi Zero is a very limited platform and a bit of a pain to develop on, but fortunately the common architecture across all Raspberry Pi implies we can do all our work on a Raspberry Pi 3 like we’ve been doing. Once done, we can transfer the microSD into a Raspberry Pi Zero and everything will work. Does that theory translate to practice? We’ll find out!
  • We’ve all read of Raspberry Pi corrupting their microSD storage in fixed installations like this, where it’s impossible to guarantee the Pi will be gracefully shut down before power is disconnected. But how bad is this problem, really? At Maker Faire we talked to a few people who claimed the risk is overblown. What better way to find out than to test it ourselves?

On paper it seems like a Death Clock could be completely implemented in a PIC. But that requires extensive modification of our PIC code for doubious gain. Yeah, a Raspberry Pi is overkill, but it’s what we already have working, and there are some interesting things to learn by doing so. Stay the course and full steam ahead!

Roger Cheng

Death Clock Project Priorities

A project that started with exploration of VFD (vacuum fluorescent display) has evolved into a fun little project the Death Clock. Emily has an aesthetic in mind for its external enclosure and I’m fully on board with it. What’s inside the box will be dictated by the priorities we’ve agreed on. The overriding theme is focus: we’ve spent a lot of time and effort getting this far, let’s focus on putting it in use and not get distracted.

For the power system, we will use parts from the original device as we’ve done in our experiments so far. This means the original transformer, rectifier module, and several capacitors. There was the temptation to turn this into a battery-powered contraption for better portability and easier show-and-telling, but that’s a distraction today. We can tackle battery power for a future VFD project.

For the control system, we will use the exploratory control board we’ve rigged up. It is a simple circuit with an 8-bit PIC driving three ULN2003A Darlington arrays. Plus a 3-to-8 bit decoder to help with grid control. We started looking at the Microchip HV5812, a control chip designed specifically for driving VFDs, but that’s a distraction today. We can consider that chip for a future VFD project.

And finally, staying with the theme meant the simple software running on the PIC will remain as-is. I had considered adding the capability to control brightness of individual segments: fade effects are rarely seen in old VFD screens and I thought it would be a fun differentiator between old and new. But again that would be a distraction now and I can pursue it later. Potentially in conjunction with Microchip HV5812 above.

Keeping it simple and avoid feature creep. That’s the key to finishing projects instead of letting them drag on forever.

Roger Cheng

VFD Project: The Death Clock

Emily and I have been working with a VFD (vacuum fluorescent display) salvaged from a piece of old electronics. The primary objective was to demystify this now-obsolete class of technology, and with the screen lighting up to our commands, that part has been a success. But we’re not content to just leave it be… we want to do something with it. Hence the secondary objective: using this old and left-for-dead piece of technology in a “Death Clock”

What is a “Death “Clock” in this context? It’s a clock, but not a timepiece. If someone wanted a VFD clock which tells the time of day, go to a thrift store and rummage around. We didn’t go through all this work just to duplicate that! No, what we’re going to do is a quirky fun electronics project off the beaten path.

The core functionality is fairly basic, we will put a random value on this display’s time-of-day and day-of-week capability. It will do so when commanded by a touch sensor. The gag is that the clock has touched your body and sensed the time and day you will die. Completely unscientific, it’s just a fun gag. And since it’s random: if you don’t like the answer, just touch it again for another prediction on your death.

If anyone is still unsure why Emily has named her YouTube channel “Emily’s Electric Oddities“, this project should serve as prime example. Emily has done most of the electrical work and has started building prototype enclosures. My responsibility will be producing code to run this display.

Here’s Emily describing the project during episode 5 of Hackaweek Coast2Coast. (This URL should already be cued to the correct time, but if YouTube is uncooperative, skip ahead to 54:10.)

Roger Cheng

New MP1584 Regulator Consolidates VFD Project Power Supply

Driving a vacuum fluorescent display (VFD) requires multiple power planes: we needed 2.5V AC for the filament, 30V DC for grids and segments, and 5V DC for a voltage bias between filament and grid/segment as well as driving all electronic logic. In our first test, these three power planes came from three different sources, for an unwieldy mess of three power plugs going to three transformers feeding into our circuit.

While we were working on debugging our control system logic, we also worked on consolidating the power supplies. From the start our 2.5V AC came from a AC transformer that was extracted from the same device we salvaged our VFD from, so we knew it was capable of supplying all the other power planes as well.

Using the same transformer to provide our 30V DC was relatively straightforward, but we had trouble with our 5V DC plane that took some head-scratching. We eventually determined the 5V DC plane couldn’t supply enough power to all the components on the plane because we had our priorities backwards: the highest amperage draw device (the Raspberry Pi 3) was furthest from our 5V voltage regulator when it should have been the closest. Our 5V power sagged to a little over 4V when our Pi was desperately trying to suck enough power through our convoluted nest of wires.

Unfortunately, while trying to move our 5V supply closer to the Pi, we made a wiring error and destroyed the regulator. Oops! Fortunately, these MP1584 modules were very inexpensive and it wasn’t a big deal to bring in a replacement. We just had to wait for a follow-up SGVHAK work session. [Emily] found enough room on our prototype PCB to fasten the regulator with a few soldered header pins so the module doesn’t have to dangle on wires. In hindsight we would have rearranged our layout to make sure there’s room for this regulator, but this is why we build prototypes.

Now our regulated 5V DC supply is first connected to the header pins that supply power to our Raspberry Pi, and from there to the PIC, before finally putting a voltage bias on our filament. This makes far more sense than the other way around, and gave us an electrically reliable system all fed from a single transformer.

Roger Cheng

Evaluating Microchip HV5812 For VFD Projects

[Emily] and I started our vacuum fluorescent display (VFD) project because there was an interesting unit available, with a look distinctly different from modern LED. We just had to salvage it out of an obsolete piece of electronics and figure out how to make it work. We now have a prototype VFD driver circuit up and running, and we can command it to light up arbitrary combinations of segments at arbitrary times from a Python program running on an attached Raspberry Pi. This is a satisfying milestone marking completion of our first generation hardware allowing us to transition to focusing on what to actually put on that display.

The first few experiments with VFD patterns confirmed that we really like how a VFD looks! As people who love to take things apart to see how they work, we enjoy all the components of a VFD visible through its glass case. Their intricate internals qualify them as desktop sculpture just sitting there, making them light up is just icing on the cake.

With this early success and desire for more, chances are good that we’ll embark on additional VFD projects in the future. For our first VFD project we chose to stick with generic chips for the sake of learning the basic principles, but if we’re going to start building more we should look at using chips designed for the purpose.

According to Digi-Key’s online catalog, there are dedicated vacuum fluorescent drivers available from Maxim and Microchip. None of Maxim’s chips are available in hobbyist-friendly through-hole designs, but two of Microchip’s three lines are. HV5812P-G is the 20-channel model in 28-pin DIP format, and HV518P-G is the 32-channel counterpart in 40-pin DIP format. Curiously, for ~50% more pins, the HV518P-G costs over double the price. So it made sense to start with the HV5812.

With data and clock pins for straightforward serial data input, it was designed to be easy to drive from pretty much any microcontroller. The only thing that caught my attention is that logic input lines are expected to be 5V input with a minimum of 3.5V required to be interpreted as logic high. This meant we couldn’t drive it directly from 3.3V hosts like a Raspberry Pi or an ESP32. We’d need level shifters or a 5V capable part like a PIC to act an intermediary.

It looks promising enough — and priced cheaply enough — to be a consideration for potential follow-on VFD projects. So we’ll add that to the Digi-Key shopping cart and see where things go from there.

Roger Cheng

Casualty In Debugging 5V Supply for Prototype VFD Driver

Once we had functionality of our prototype VFD driver figured out, we turned our attention to the other problem that cropped up earlier in our initial integration with the original power supply transformer: our 5V rail could support the PIC microcontroller and associated chips, plus putting a voltage bias on the filament. But when put a Raspberry Pi on the circuit, our 5V sagged low enough to put our Pi into a power brown-out reset loop.

Since the MP1584 voltage regulator we used has proven capable of powering a Pi in the past, this was puzzling. So we started quantifying our system starting with measuring the amperage draw of our 5V circuit. It was well within the 3A maximum draw supported by the regulator, so our next thought was a dirty output wave. Putting the output on an oscilloscope, the 5V line looked pretty clean so that was not the explanation.

The next experiment was to isolate the 5V supply chain. Instead of supplying the MP1584 voltage regulator with power from the rectified output of a transformer rail, we’re going to use a two-cell lithium polymer battery. If this worked, we’ll know the problem is upstream in the transformer or rectifier. If it doesn’t, we’ll know the problem is the regulator or further downstream.

Unfortunately the experiment failed due to a wiring error, which destroyed the MP1584 voltage regulator. The title picture shows the entire regulator module with a U.S. quarter dollar coin for scale.

And here’s a close-up of the dead MP1584 chip. The glossy blob in the upper left is plastic that has melted and resolidified. The bump in the middle was a tiny volcano where smoke pushed up through the casing and escaped.

MP1584EN chip with melted hole

Looking on the bright side, we are no longer suspicious of the MP1584 chip’s functionality. We now know for sure it doesn’t work!

Debugging continued with help of a benchtop power supply delivering 5V. Probing with a volt meter through the circuit, and seeing voltage drop along the supply path, we decided our problem wasn’t any single wiring errors in the circuit. We just had too many thin wires and connectors involved in the 5V supply path. We had put our Raspberry Pi at the end of the chain of 5V parts, and it couldn’t draw enough power to run. Not because of any single large obstacle but because of the cumulative effect of lots of little obstacles.

To test this hypothesis, we reversed the chain so our 5V supply entered the system at the Pi then propagated to the rest of the circuit. With this change — and no other change in the circuit — everything started working. This is a valuable lesson to a software person who is used to thinking in terms of digital logic: It’s easy to think 5V rail is 5V as long as there are wires connecting them. This simplification creates a blind spot: the real world is analog and our 5V rail will degrade to a 4V rail when too-thin wires are used!

With that problem solved, we can now start playing with VFD patterns. See what works and see what doesn’t.

 

Roger Cheng

Prototype VFD Driver PCB Debugged

We now pick up where we left off narrowing down a problem with our prototype vacuum fluorescent display (VFD) driver board. We had determined that segment H was the key. When segment H was illuminated, everything else works as expected. But when segment H was dark, segments A-G all became dark as well.

ULN2003Since segments A-G were all controlled by a single ULN2003 chip, we started looking closely at every solder joint on that chip. We were looking for an undesirable solder bridge or other electrical connection to any wire relating to segment H, which was managed by another ULN2003 chip.

The two ULN2003 chips were immediately adjacent to each other, meaning A-G were pins 1-7 on one chip, and segment H was pin 1 on the next chip. The densely packed nature of these chips meant pin 1 of segment H was immediately adjacent to the emitter (E) and common (COM) pins of the ULN2003 controlling A-G.

When describing the symptoms, [David] correctly diagnosed the problem must be an electrical connection between segment H pin 1 of one ULN2003, and pin COM of the adjacent ULN2003. Using a probe we verified this was indeed the case – those two pins should have no connection but they are electrically connected. However, we could not find where this connection was taking place. No solder bridges were found and no accidentally soldered wires were found.

Eventually [Emily] devised a hack: because a VFD is not an inductive load, we didn’t really need the COM pin at all. It was only soldered to the board for physical mounting, that solder joint has proven to be more trouble than it was worth. To bypass the undesired connection, wherever it might be, it is easiest to clip off the COM pin from that ULN2003. Maneuvering a cutter within the packed space, [Emily] snipped off the leg.

After that, every aspect of our prototype VFD driver was fully functional as planned. [Emily]’s hack was totally unconventional, but very effective!

Roger Cheng

A Close-Up Look At VFD Internals

When we first pulled the vacuum fluorescent display (VFD) from an old Canon tuner timer unit, we can see a lot of intricate details inside the sealed glass. We had work to do that day – probing the pinout and such, but part of its overall allure comes from the beauty of details visible within. It is still something of interest, I just had to remember to bring my camera with a close up macro lens to take a few photos.

VFD under macro lens off

One of the reasons a VFD is so interesting to look at is the fact the actual illuminating elements sits under other parts which contribute to the process. Closest to the camera are the heating filaments, visible as four horizontal wires. This is where electrons begin their journey to trigger fluorescence.

Between these filaments and individual illuminating segments are our control grids, visible literally as a very fine mesh grid mostly – but not entirely – built on a pattern of hexagons.

And beyond the control grids, our individual phosphor coated segments that we control to illuminate at our command using our prototype driver board. (Once it is fully debugged, at least.) These phosphor elements are what actually emits light and become visible to the user. The grid and filament are thin which helps them block as little of this light as possible.

Fortunately an illuminated VFD segment emits plenty of light to make it through the fine mesh of grids and fine wires of filament. From a distance those fine elements aren’t even visible, but up close they provide a sophisticated look that can’t be matched by the simplicity of a modern segmented LED unit.

VFD under macro lens on

Roger Cheng

Salvaged VFD Power Supply And Debugging

Our first system integration test of a salvaged vacuum fluorescent display (VFD) and our prototype driver PCB was a success. At least going by our initial target of having our VFD segments illuminated and cycling through a test pattern to verify things are not stuck always on or off.

Once we had that basic level of functionality, [Emily] started working on the power supply side of the system. We have an original transformer salvaged from the same device which outputs multiple AC voltages. The first is a 2.5V AC line we could use directly on VFD filament. After that, Emily salvaged a few more components to deliver the ~30V DC we need for control grid and segments, and the ~24V DC we fed into a MP1584 buck converter to get 5V DC for filament bias and micro controller logic power.

VFD on transformer

We’re very close to a complete power solution for a VFD project, but not quite there yet. When we added a Raspberry Pi 3 to the mix, its power demand was too high for this system to handle. Power sagged to 4.2V and the Pi entered a power brown-out reset loop. We’re not sure what’s wrong with this setup yet, but in the meantime we connected an alternate 5V DC power source to look at how the rest of the system behaves.

This allowed us to see a problem in our prototype driver board. I had a new test pattern generated with the help of my tool created in Google Sheets, but the test program did not display as I expected. After some time sending various diagnostic patterns to the VFD, we figured out the key to the situation is segment H.

NEC VSL0010-A VFD Annotated

Whenever segment H is illuminated, everything else functioned as expected. But if segment H is dark, segments A-G are all dark regardless of commanded pattern. Segment I and J are unaffected.

Once this was determined, we ran a test pattern where H is commanded to be dark and everything else should illuminate. The test pattern is the same for every segment, so the circuit would be at a steady state for us to probe with a meter as the PIC cycled through segments.

Using segment A as an example, we probed to verify its output pin from PIC (RC0) is low as expected. We then traced that signal to the ULN2003, whose corresponding input pin is low as expected. With input low, the corresponding ULN2003 output pin should not be tied to ground. Which means we expect VFD pin for segment A to be sitting at near 30V DC due to a pull-up resistor.

This is where we went off script, for VFD pin A has been pulled low. Unplugging the wire between ULN2003 and VFD allowed the segment to illuminate. This narrows down the scope of our problem: it has something to do with that ULN2003 chip, but we ran out of time for tonight’s SGVHAK session before we could narrow it down any further.

To be continued!

Roger Cheng

Create VFD Bit Pattern With Help Of Google Sheets

With a successful integration test of our salvaged vacuum fluorescent display (VFD) we proceed to a few other tasks. On the hardware side, we’ll need to simplify our power supply situation. Our test had three separate AC plugs, we only really need one. We’ll also need to transfer what’s on the breadboard to a prototype circuit board.

On the software side, things are less clear because we’re still coming up with ideas on what to do with a salvaged VFD. Our very simple PIC driver code merely controls a pattern of bits, each bit representing a segment to be illuminated. This gives us a lot of flexibility but so far these bit patterns have been created using pencil and paper and quite time consuming. Once we have a project in mind we can write code specific to a theme, but until then it’s wide-open bits.

Well, at least we can streamline the pencil and paper system somewhat. The logic is not difficult, just time consume, and should be easy to automate. I started by creating a HTML form and laying out checkbox controls. I got as far as designing a JavaScript structure for checkbox click events when I realized everything is on a grid and looks a lot like a spreadsheet.

That realization led me to put my basic HTML and JavaScript on hold and switch to investigate what I can do in Google Sheets. The key that made it all possible is the BINTOHEX() function that reads a number, interpret it as binary, and translate to hexadecimal. This is the core functionality for my pattern generation and I was able to build everything else around it.

Here’s the initial build, with a fully populated grid of checkboxes and a test pattern for me to verify things were working.

VFD Pattern tool - full checkboxes

Once verified, I deleted the checkboxes that didn’t have a corresponding segment. This array now properly corresponds to our specific VFD.

VFD Pattern tool - customized checkboxes

Now creating a bit pattern is as simple as checking on the segments I wish to have illuminated. Here’s the pattern for “12:00”, the canonical Hello World for a time-based VFD display.

VFD Pattern tool - 12.00

I thought it would be fun to make this available for anyone to play with, but that requires keeping the sheet and its formulas fixed while allowing people to check and uncheck boxes. Unfortunately “view only” sharing does not allow checkbox manipulation, and “editable” sharing also allows modifying the sheet formula. Until I figure out how to do what I want, it was shared as “View Only” to the general public.

 

Roger Cheng

Integration of Salvaged VFD and Prototype Driver PCB

The time has finally come to put our salvaged vacuum fluorescent display (VFD) together with the prototype driver printed circuit board (PCB) we built for it. First we gave our VFD a little layer of protection. The individual pins of the VFD are small and seemed rather fragile. And as they went into a vacuum sealed chamber we had no means to repair, if one pin should break that would mark the end of our fun.

Fortunately, when we salvaged it from its previous home we noticed that those pins were quite strong in union. A single pin is fragile, but all twenty pins together was pretty strong. So we’ll solder up one of our cheap prototype boards to these pins just for the sake of holding them together. It was a bit tedious getting all the pins to line up. Two more boards were used as spacers to give us the desired distance.

VFD pin alignment

Once lined up, the VFD was soldered in place.

VFD pins in perf board

As anticipated, the assembly is now much more robust. Now we can work with this module with a lot less trepidation: if we should break a pin now, the break should stop at this PCB where we could still recover, not break all the way to VFD glass where we couldn’t.

We still had a lot of usable pin length remaining, so we left this unionizing PCB alone and soldered another one where we’ll actually attach wires and headers.

VFD second PCB

While this soldering work was underway, a breadboard was populated to test our design for interfacing our driver PCB and the VFD. Each VFD grid and segment wire received a 10 kilo-ohm pull-up resistor to the 30V line, and path cords were installed to map pins from our generic driver board to this specific VFD as per the pinout diagram we drew up earlier. Now the VFD, with its new more robust pins, should plug right in.

VFD interface breadboard

Finally, power delivery which is far more complex than what a LED project requires. This initial integration test had three different power sources. The power transformer we salvaged alongside this VFD delivers (among other voltages) the ~2.5V AC we need for our filament. With a few rectifier circuits, it should be able to deliver the other DC voltages we need as well, but we weren’t going to worry about it until we got this test working. In the meantime, a HP inkjet printer power supply delivered the 30V DC for grids and segments, and a Raspberry Pi delivers the 5V logic power as well as I²C control signals.

VFD integration test rig

We plugged everything in and… it lives again under our control!

Roger Cheng

Prototype VFD Driver Tested With Placeholder LED

PIC16F18345 VFD driver PCB

Once I had assembled our first prototype vacuum fluorescent display (VFD) driver circuit board, it’s tempting to connect it right up to our salvaged VFD and bask in its glow. But that would have been premature: there were bugs still to be ironed out with potential for fatal errors to damage or destroy our one and only salvaged VFD.

The first tests were what we used to test our bread board prototype: drive a 4-digit 7-segment LED, a Lite-On LTC4627-JR from my earlier PIC display driver project. From there I could verify 8 of 11 segments on this driver board functioned as expected by a demo program that constantly flips between two patterns, one spells “Hello” and the other “Ahoy”.

I then tested the I²C capability with a small update, changing the second pattern from “Anoy” to a very mutilated “MLE”. (It’s hard to do “M” on 7 segments.)

These experiments exposed a few minor bugs, just as tests were supposed to. After they were fixed I expanded my test with a second LTC4627-JR for eight total segments. I also expanded my use of I²C by continuously updating all digits from Raspberry Pi to create a text marquee. This experiment exposed some timing issues that is visible as a slight lag just as the “u” in “thank you” came up on screen.

That lag was diagnosed to my code inside a timer interrupt service routine (ISR). On a simple chip like this PIC, a hardware interrupt signal could not interrupt another ISR already in progress. So when my code inside a timer ISR grew beyond a certain point, it started interfering with timely response to hardware interrupts necessary for I²C communication. The solution is to put my timer ISR on a severe diet, moving almost all of its bulk elsewhere so that I²C handlers could run with minimal interference.

Once the software problems were sorted out, I started experimenting with the flexibility given by this project’s design decision to keep PIC code simple. It meant I could play with patterns that have nothing to do with displaying letters or text. I decided to try a pattern that keeps a single lighted segment running through the display in a figure 8. When cycled through all digits like a text marquee, it gave us a neat looking wave. I look forward to more experiments in driving a multi-segmented display in unusual ways.

Roger Cheng

Assembling Prototype VFD Driver PCB

PIC16F18345 VFD driver PCBIn addition to exploring the idea of aggressively packing chips densely, there were a few other design considerations in building our prototype driver PCB.

Why I²C?

When I was tearing my hair out trying to figure out why a tried-and-true piece of template code has stopped working, I was sorely tempted to move to some communication protocol other than I²C… good old TTL Serial always looks good whenever I run into a problem.

The answer is voltage compatibility: I want my driver board to be capable of running at either 3.3V or 5V, which is easy to do with an old 8-bit chip like the PIC16F18345 I’m using: give it power anywhere in its specified range (and probably a bit beyond that range) and it’ll happy run. But this doesn’t necessarily apply to whatever my driver board will accept commands from. Fortunately, I²C was designed from the start to accommodate devices that work off different VCC levels. So something like a Raspberry Pi (3.3V) can communicate with my PIC. (5V).

Pin Assignments

In addition to moving the decoder output pins so it could be placed immediately adjacent to my PIC, I also took advantage of my particular PIC’s feature of Peripheral Pin Select (PPS) by moving the I²C pins (handled by Master Synchronous Serial Peripheral – MSSP) from their default to RA4 & RA5 for easier routing on the PCB and easier data writes in my code.

Pin Isolation

This is the first time I planned to use pins RA0 and RA1 on a PIC16F18345 project. I usually avoid them because they are used as in-circuit system programming data (ICSPDAT) and clock (ICSPCLK) pins. They’re perfectly usable outside of this scenario, but they must be disconnected from the rest of the circuit during programming. In this case, it meant I had to put in two jumpers that are removed during programming. The jumpers are installed exactly where my PICkit 3 programmer would attach, so there’s no way for me to forget to remove them when reprogramming this chip.

Wires From CAT-5E Network Cable

Even with all these concessions to easier routing on a prototype PCB, there will still be an unavoidable nest of wires. In order to keep things tamed, I harvest my spool of CAT-5E network cable for wires that are thin and rigid. Thin wires help me fit more wires in a small volume, and rigid wires stay where I’ve put them. In addition to being affordable and easily available, the four twisted pairs of wires give me eight different insulation colors to help me keep track of which wire goes where.

Roger Cheng

Chip Packing Experiment On Prototype VFD Driver PCB

While we were building a breadboard prototype for our VFD driver, we weren’t terribly concerned with chip layout as it was largely constrained by the practicalities of a bread board anyway. Once we start thinking about transferring it to a PCB, however, we had more flexibility to be creative. The prototype printed circuit board is a grid of through-holes that we can use in any way we like. How shall we abuse this power?

While looking at how wires were run on our bread board, I noticed that there were a few pins that were perfectly aligned from one chip to the next. Placing the decoder output on PIC pins RB4, RB5, and RB6 lines them up perfectly with the input pins of 74138 decoder. As for the decoder output, six out of eight pins were directly lined up with a ULN2003.

Chip pin alignment

This allows some fairly straightforward wiring solder as these wires will not cross over each other and won’t tangle up and make a big mess. By itself that is valuable, but we were tempted to go one step further: how about we eliminate the wires entirely and jam those chips together? If they share the same PCB through-hole, that would eliminate wire soldering entirely.

It sounded good in theory, but in practice the chips are just a little too large for us to fit them three-abreast. I could push my decoder up against my PIC, but couldn’t push the Darlington array alongside the decoder as well. This is probably for the best – there’s value in having the ULN2003 lined up with its siblings.

Chips tightly packed on PCB

We may learn in the near future why this is a bad idea, but it’s all part of the fun: trying things and seeing how they work. (Or not, as the case may be.)

Roger Cheng

Breadboard Prototype of VFD Driver Project

Once we had some idea of what we wanted to do, it’s time to start wiring things up on a breadboard to see if it actually does anything interesting. Dealing with actual chips meant reading their data sheets and figure out where the rubber meets the road and how well theory meets practice.

Not having a lot of first-hand experience with such modules, it was a great way to learn by doing. The first surprise was behavior of the 74HC138 decoder module: Conceptually it takes a three-bit input and decodes it to one of eight pins. Conceptually we thought that meant raising one of eight pins high, but it actually lowers one of eight pins low.

We thought this was going to be a problem and started looking into inverters… before we realized it is a perfect pairing with ULN2003 to do what we actually wanted: The ULN2003 line inverts its input in the sense that when an input pin is high it connects the output pin to ground. So the output of a 74HC138 decoder (seven pins high, one pin low) driving ULN2003 results in seven pins connected to ground and one floating. We can work with this.

A 4-digit, 7-segment LED module stood in for the vacuum fluorescent display while all the logic got worked out. This flexibility is exactly where a breadboard is strong, letting us experiment and verify pieces of our circuit piecemeal. But it is not great for looking respectable or for long-term reliability, so once it successfully ran the LED module, we start planning to commit the design to soldering parts on a prototype PCB.

PIC16F18345 VFD breadboard and PCB