Some Thoughts on the Next Version

Its great as it is, but here are what I would put in the next version:

A LiPo battery

I want to be able to carry this thing around from one place to another. It would be optional and just plugin in underneath the main board. I would need to add a boost converter from 3.7V - I need 5V for some of the logic. The power supply itself could run straight from the 3.7V. It would need to charge when plugged into a USB port.

So I guess I won't be dismantling my testbed just yet.

Fifteen HV Pins

I pull 12 HV pins out currently (plus another two for the little neon indicators). This is so I can drive tubes that have one or two decimal points. However there is a tube called the B7971 that is a 15 segment neon display. It is big. I can't drive it using this clock :-(. On the current connector I have one unused pin, so I would just need to add another two. In other words, instead of a 2x8, I would use a 2x9. That is a small change.

Real Time Clock

Currently it just syncs with the internet. But if I want to use it somewhere were I can't connect it to the internet, like my office, I need some other way of keeping the time. Actually I could add this now via the I²C expansion header, so maybe I don't need to add special support after all.

A Button

If I don't have access to the internet, I need some way of setting the time. Again, I could add this via the I²C expansion header. So maybe, I need to design a little add-on module for use away from the internet.

Hardware Notes

There are some not-so-obvious but important points about the PCB layout:

1. The layout of the copper layer here (on both sides of the board) is defined by the manufacturer of the specific chip antenna. 
2. This is a 50 Ohm trace that leads from the ESP8285 to the antenna. The width is chosen specifically to match the copper depth and the characteristics of the substrate. KiCAD has tools that help to calculate this width given this information. OSHPark has the information needed to make this calculation. If you use a different fabricator, or a different spec board from OSHPark, you should re-do this trace. Though I am not sure how important it really is. On the flip side of this trace is an unbroken ground plane. No other traces can cross this trace underneath it.
3. This +5V plane is kept as wide as possible to minimize resistance and hence minimize voltage drop when we start to pull more power.

You'll note that there are also many through-vias around the antenna traces with ground planes both top and bottom. This is to minimize stray EM radiation.

This pair of traces are the USB data lines. They should really be a differential pair. Like the antenna trace, the impedance is important, but here layout is also important. I kept them parallel, but that was about it. The CP2102N is a full speed device. We shouldn't really need to worry until the traces get up to about six inches in length.

Software Notes

I'm pushing it with the ESPxxxx devices. I was careful to test out my code before I committed to using them. The problem is that the WiFi gets priority over everything else, so anything that is sensitive to timing can get thrown out. This is particularly important for the NeoPixels, which use a clockless protocol. In fact at one point I updated my ESP8266 Arduino libraries to v2.4.0, and the NeoPixels started glitching on me. Down-graded back to v2.3.0, and all is well - there is still a chance they will glitch, but I haven't noticed it in all the months I have been using it.

Allegedly the ESP32 would be better in this regard - it has a separate core for the networking.

I finally had time to get around to building one of my clocks. I spent an hour or so labelling all the component bags so I wouldn't be searching for components once I had the solder paste applied. Then I taped the board to my bench and used the stencil I had made at OSHStencils.com to apply solder paste. Once done I started adding the components to the board and finally wandered over to my reflow soldering station:

Yes. Its an electric griddle. About $40 from Target. As this board was bigger than all the others I had made, I needed a special tool to load it into the griddle:

I knew that over-sized spatula would come in handy one day.

Anyway, this is what I ended up with:

Testing went surprisingly smoothly (at first):

• My PC recognized the board when I plugged it in
• I could configure the CP2102N USB-UART chip using Silicon Labs config tool
• I uploaded the clock program and assets to the ESP8285 (U3 in the picture above)
• My phone saw the access point presented by the ESP8285
• I could run the web GUI

Then I plugged a tube in and things weren't as I expected: All of the digits were lit up and the LED backlight wasn't! There followed about 2 hours of debugging. First, I hooked up the Clk and MOSI pins to my oscilloscope - they showed that the ESP8285 was producing the right signals for the HV5523. However, the signals are level-shifted through a TXS0104 - I very carefully managed to stick the probe on the output side, and there was nothing. So that was it. I spent an hour or so trying to touch up the contacts with my soldering iron and eventually I succeeded! One or other of the +5V or 3V3 connections had been bad (note to self: Don't put vias on really small pads!). Now I could see the clock displaying digits, except that it was displaying all but one of the digits - in other words it was inverting the outputs. I took a look at the schematic and for some reason I had tied the HV5523 polarity pin to ground rather than +5V. Fortunately, this was easy to fix in software, and finally I had a functioning clock:

If you're wondering, the dangling thing on the wires sticking out the front is a LDR - at some point I will be putting this in a case, so I didn't want to trim the wires until then.

There is one other problem with the hardware: I should have cut a notch in the PCB where USB connector is, without it it is pushed up at an angle by a lip on the connector, however it still works.

I like these things so much that I can't wait to assemble my other two boards and scatter them around the house. Unlike a full 6-digit clock, they easily fit anywhere.

When I get a bit more time, I will add upload all the CAD files and source code to GitHub and add links to everything.

The boards have arrived! Unfortunately it is going to be a couple of weeks before I get to do anything with them. While I was waiting, I was honing the software, which is pretty much ready to go.

Here are some screen-shots from the web GUI. The Clock screen lets you configure all of the actual time display features.

The Time Server URL is used to synchronize the time with NTP and adjust for timezone and DST - I blanked it out in this image:

The LEDs screen allows you to control the backlight and reflects the current state of the backlight in real time using web sockets push from the clock.

The Extra screen allows you to change the purpose of the hardware:

• You can use it as a clock.
• You can also use it as a tube-tester by getting it to just cycle through all of the digits.
• Finally you can use it to de-poison the cathodes by increasing the voltage and having it cycle through all of the digits slowly enough for the over-current to burn off the deposits from the cathodes. Or, I have some tubes in my collection that just need to be run at a higher voltage.

There are so many options that it comes with five presets that you can just jump between. If you make changes to a preset, they are saved automatically, and you can rename the presets.

Finally, there is an info screen:

Well, my prototype is being fabbed by OSHPark, along with a stencil from OSHStencils!

I also designed a couple of adapter boards. One for an IN-12, because I test everything with these tubes. This is a vertically mounted board. One for an IN-18, because I wanted to make a horizontal adapter and I also need an adapter for those tubes.

So, fingers crossed that I didn't make any mistakes in the design and layout, and that I can actually build it without messing it up!

I uploaded the OSHPark render and the schematics for the design.

I am waiting for some parts to arrive before I can start laying out the board. The design is basically done, except for some tweaking I have been doing for things such as power sources, connector layouts, pin breakouts etc.

In the meantime I have been polishing the software using my breadboard prototype. Here are some of the things I think are worth sharing:

Development Framework

As you probably know, I am using an ESP8285 - this is an ESP8266 with 1M of on-board flash - so it reduces component count and frees up a couple of extra GPIOs. I use the ESP8266 arduino development framework. A good resource on this framework is the ESP8266 Arduino Core docs. The arduino development framework is kind of like the Java of the hardware world. It has many, many libraries that a developer can leverage, rather than having to roll their own for every different processor out there. Developing for this framework also means that my own code is more portable.

The ESP8266 boards are fully supported in the Arduino IDE, however I use Sloeber- an Arduino Eclipse plugin. It makes me way more productive.

Key Libraries

From the outset my aim was to leverage the WiFi connectivity of the ESP boards. I have developed a web interface for Nixie clocks before, and I used the ESPAsyncTCP library, rather than the libraries from the ESP8266 core for Arduino. In particular ESPAsyncWebServer. I wrote a small ESPAsyncHttpClient to go with it. Asynchronous communication places less load on the ESP8266 - it allows it to get on with other tasks, while the communication is happening in the background. I came across this library via fauxmoESP - a library that allows you to mimic WeMo devices, so you can control things using Alexa - it uses the ESPAsyncTCP library!

One problem that needs to be solved when using WiFi is the initial connection to a router. I had previously rolled my own solution to this before, but it is a finicky business and after I had implemented it I came across WiFiManager, which displays a captive portal when a device tries to connect to the ESP, and allows you to choose which router you want to connect to. However, it uses the synchronous web server and I wanted to use the asynchronous web server. Fotunately someone had already implemented that too: AsyncWiFiManager. 

Interrupt Handling

I implement various fading effects by turning power on and off rapidly to selected digits. I do this using interrupts to guarantee the timing - the ESP8285 has many other things to do, so the loop() method isn't called at consistent enough intervals to rely on that for timing. I had implemented this a long time ago using timer0 - the handler issued SPI calls (using the Arduino SPI library) to set the state of the HV5523, telling it which digits should be on and which should be off.

It all worked fine until I integrated the ASyncWifiManager and started serving up web pages. Then it started crashing randomly. When the ESP does that it spits out a stack dump as a bunch of numbers, so the first thing to do was to convert these to symbols. If you're using the Arduino IDE there is the EspExceptionDecoder for doing that. For me, I needed to use the EspStackTraceDecoder command line tool.

What it told me was that I was always crashing with an illegal instruction error. WTH? After some googling I found that various system calls can cause flash to be unmapped from the address space. If an interrupt happens at that time, you will get an illegal instruction error. The solution is to move your interrupt handler to RAM using the ICACHE_RAM_ATTR tag. For example:

void ICACHE_RAM_ATTR myHandler() {
// Do some stuff
}

However:

1. Everything that is called from that interrupt handler also has to be in RAM.
2. There isn't much RAM.
3. SPI methods are not declared with that tag, so they are all in flash.
4. There isn't much RAM (see 3).

So. I created my own copy of the SPI library and added ICACHE_RAM_ATTR to every method I called, and every method those methods called, etc, etc. All was well. At least until I ran out of space in my IRAM segement during a compilation because my interrupt handler had grown too big. Then I went back and figured out which methods I really needed to call and just tagged those. So far so good.

I guess you should also watch out for FStrings - strings stored in flash. This wasn't a problem for me.

Memory

The ESP8266 memory is split up into several chunks. At least:

1. Flash
2. Instruction RAM (aka IRAM).
3. Data RAM (aka DRAM).

You likely know how much flash you have. However, you will also have 32K IRAM and a separate 80K of DRAM. Of that 32K of IRAM, plenty is already taken up by various libraries, so you might only have a couple of K to play with.

SPIFFS

The ESP Arduino core comes with a SPIFFS library - a flash-based filing system. This is where I store the files I serve from my web server. This saves on me declaring a whole bunch of string literals and also means that I can develop my web pages as separate files. In fact I wrote a quick node.js server to serve them up locally so I could test them.

Using SPIFFS also helps (dramatically) to cut down on strings being stored in DRAM.

One drawback of doing this is that I can't serve dynamic web pages - i.e. I can't fold variables into the document as it is being served. Enter, websockets.

Web Sockets

Web Sockets is a fairly recent protocol that is now supported by every major browser. You can use it to do AJAX, but it also has the advantage of being able to push data from the server to the client. To get around the problem of not being able to serve dynamic pages, I serve static pages that then open a web socket back to the server and request initialization data. The server then just formats that all up as a JSON string and squirts it back down to the web page.

Because the server can push data from the server to the browser (or all browsers) I also use it to dynamically update the browser with values that are changing on the ESP8266.

JQuery Mobile

I use JQuery Mobile to render my pages - my intention is that I use my smart phone to control and configure my clock. I might as well use a toolkit that is designed for that platform.

One possible issue with this is that my web pages reference external libraries - i.e. libraries stored on servers in the internet. This might cease to work if the specific versions I reference go away, or if there is no internet connection at the time I want to use it (and for this last reason, I can't use it in my captive portal). I could look at storing minimized versions on the ESP8285 itself. I'm not sure how big they are.

Another possible issue is if JQuery Mobile ceases to be developed and it becomes incompatible with current versions of browsers. It is showing every sign of not being developed any more. The last stable release was in 2014. The last alpha was in Jan 2017.

Some Tooling

As part of my everyday development with my ESP8285 board I needed to be able to do a few things repetitively:

• Build spiffs
• Upload spiffs
• Erase flash
• Decode stack traces

Sloeber doesn't perform these functions for you (the Arduino IDE does). The key to getting this to happen cleanly with Sloeber is being able to access the configuration for the board you are developing for and find where the necessary tools are. This information is all stored in .settings/org.eclipse.cdt.core.prefs, so I wrote an ant script to parse it and implement the tasks above. You can find it in my Git repo.

Theoretically the ESP8285 has 17 GPIO pins and one ADC pin. The bad news is that many of these are already assigned to specific functions. Some of them are still usable, with restrictions, some aren't usable at all.

First here are GPIO states for various boot modes:

Because these pins have to be in a specific state at startup, they can't be used as inputs. We also need to be aware that GPIO0 might change state if we are using it as an output - i.e., whatever hardware is connected to that pin needs to be able to handle that.

After startup, we can do whatever we want with these pins.

GPIO6, GPIO7, GPIO8 and GPIO11 are completely unuseable.

GPIO16 is used by 'wake from deep sleep', and I would like to play with that.

So, that leaves nine completely unused GPIO pins. We want the following pins:

• MOSI
• SCK
• Latch Enable
• Neopixel data
• HV enable
• HV adjust

In addition, I want to play with USB charge detect, so I also want:

• Charge enable
• Charge 0 enable
• Charge 1 enable

That is all nine free pins. However I would also like, if possible to give access to I2C for expansion - that is an additional two pins.

Fortunately, if we are careful, we can also use the three boot pins (GPIO0, GPIO2 and GPIO15).

So, this is the plan:

By leaving two pins for I2C, I have an easy way to add more GPIO (including ADC) plus a whole host of peripherals like a little OLED screen for debug.

All control of the clock will be via WiFi, including setting the time, so there is no immediate need to add buttons and switches, but I2C GPIO expansion could be used if more are needed.

Define Some Libraries

Time to start putting some footprints and symbols together. My workflow for this is to define the device (symbol and footprint) in Eagle and then convert it to KiCAD using Eagle to KiCAD libs, to which I have contributed quite a few modifications. My main reason for this is that I use KiCAD for my circuit designs, but there are way more libraries for Eagle.

I have two new parts I need libraries for (I already have libraries for everything else):

• The HV5523
• The TXS0104

I couldn't find any existing Eagle libraries for these, so it was time to create my own.

The first is a 7mm QFN-44 chip. I need to get that size right! In one of my earlier iterations of a USB-UART adapter, I didn't release that QFN-28 came in a couple of sizes and I fabricated some boards with the wrong size. Fortunately I found a footprint in an ST-Microelectronics library that I already had. I imported it into my own library and modified the size of the center tab to match the Microchip datasheet. Then I duplicated a symbol for the HV9808 that I had already defined, modified it a little for the HV5523 and hooked everything together.

The second is a VQFN-14 - at least that is the version I will be using. I couldn't find this in any library I already had, but a quick search turned one up in SnapEDA. I downloaded it and imported it then checked the dimensions against the TXS1040 datasheet. It was a match, so then I quickly defined a symbol and hooked them up.

Then I double-checked the dimensions, the connections and the pin directions. OK. Good to go, so convert it using Eagle to KiCAD libs and it is ready to use in KiCAD.

Start the Board Design

My board will use sub-circuits from other experimental boards I have already built (with a few modifications). Namely:

• High voltage power supply
• USB-UART
• MCU

I have never used hierarchical sheets in KiCAD before, but it seems like a good time to start. Coincidentally, it also seems like this is the only way to copy those sub-circuits into a new project with the version of KiCAD I have (4.0.6). Copy and paste just don't work. I followed the procedure outlined on this post by padu1000. I'll reproduce the text here, but it I have modified it slightly:

• Copy "yourSchematic".sch from the original project to the new one. (At this point it will not show up in your kicad project)
• In new project create a new hierarchical sheet with the same name as the one you just copied. You will see a popup that says this:
• (A file named 'yourSchematic.sch' already exists. Do you want to create a sheet with the contents of this file?)
• Click yes
• Link up your libraries

So now, just add the new symbols and wire them up to the sub-circuits :-)

MCU

Pretty early on, I had decided to try using an ESP8266 to drive all the functions of my clock designs. I had already used an ESP01 to provide network connectivity for an Arduino-based clock, and that had always seemed a bit like the tail wagging the dog. That is to say, the Arduino was a 16MHz, 32K device, while the ESP01 was a 64MHz, 1M device with built-in WiFi, yet the Arduino was doing all the work. One worry was that the ESP8266 would give priority to the WiFi functionality, which would mean that user code could be interrupted at any time to service possibly lengthy network tasks. The only way to find out was to actually try it, so I set about trying to find suitable dev boards. While I was doing that, I discovered the ESP8285 - a chip that combined the ESP8266 with 1M of on-board flash, meaning it was essentially a one-chip MCU solution.

Dev Boards

It was clear that this would be what I would aim to use, but in the meantime I needed some dev boards. I ended up with this shortlist:

• Wemos D1 mini pro - this is an ESP8266 based board.
• ESP8285 dev board - as the name suggests, this is an ESP828 based board
• PSF-B85 - this is not a complete board, but is aimed at being soldered directly on to a main PCB.

And more recently:

• Seeed ESP-01M - this is a bit like the PSF-B85 in concept, except it is vertically oriented. This makes a lot of sense, because this puts the antenna in a better position.

All boards have an on-board antenna, except the ESP8285 dev board.

I bought them all, but I have several Wemos D1 mini pros that I use wherever I would normally use an Arduino. Again, in a finished PCB, I would aim to use an ESP8285 directly. Getting hold of these isn't straightforward, but you can get them on ebay.

Proof-of-Concept

Designing a board to directly use an ESP8285 (rather than one of the options presented above) is an interesting excercise, because you have to lay down tracks with specific RF properties, and pay attention to the placement of ground planes and through-vias. I had a couple of attempts at doing this, but wound up with this one on OSHPark.

USB-UART

Another important component is the USB port. If you are familiar with programming an ESP01, you'll know that you need a USB-UART board. Something like the Wemos D1 mini pro has one of these on board, so you can just plug it straight into a USB port for both power and programming. The Wemos also uses the NodeMCU mechanism to put the ESP8266 into program mode, so there is no fiddly holding down of buttons in some weird sequence.

In addition to doing the USB to serial conversion, I wanted something that could detect the power mode of the USB port it was plugged in to. i.e. I wanted to know how much power I could get out of it, before I start to try and draw more. This is more of a requirement for another clock I want to build, but I might as well use the same part everywhere. The only IC I could find was the CP2102N QFN28 part from Silicon Labs.

To prove that I could this to work, I built a USB-UART board that uses it. You can get it on OSHPark here. It breaks out the USB power detection pins, plus it has an adapter to directly plug into an ESP01 (or my own dev board). It implements the NodeMCU reset style, so there is no button pressing needed to program the ESP01. The voltage regulator can provide enough power to power the ESP01 too.

I like my experiments to be useful in their own right.

Nixie Controller

And by this, I mean the part that switches the HV under control from the MCU. I have attached a spreadsheet to the project that lists several contenders. They fall into a few groups:

• A transistor array.
• An HV shift register. I'll include old nixie ICs such as the 74141 in this category.

I have a couple of aims here:

1. Control at least the 10 digits, but preferably 10 digits + 2 dots. Some tubes have periods, or decimal points, or thousands separators. I would like to be able to control those too.
2. Take up the smallest amount of board space possible
3. Work with 3.3V control signals

That last point does not necessarily mean that their Vin has to be 3.3V. For example the 74141 needs +5V in, but the control lines will work fine at 3.3V.

At first glance, the MAX6920 is ideal. However it can sink at most 4mA. That isn't enough for some of the larger tubes like the IN-18 and the NL7037.

Then there is the HV5812. I have used others in this series from Microchip, so I know I can rely on them. However I was poking around and came across this post at tubeclockdb. The HV5812 can only sink 3.2mA! So that's out.

The MX877 is also very small, but I would need two of them and I don't know what the current sinking capability of these chips is. IXYS also have the CPC7701 chip but it is $20.

The 74141 might be next. I have a whole bunch of them, but it only has 10 outputs. I can't use two of them, because that would require either a shift register, or 8 GPIOs or more control hardware.

Then there is the option of just going discrete with the BF820 transistor, one for each cathode, plus a bunch of resistors and a shift register. At first I couldn't find a shift register with enough outputs, but I wasn't realizing that you can chain some of these together, so then I found the SN74HC595. I could also use an I/O expander such as the MCP23017. Both of these come in surface mount packages.

In the end I am going to go with the HV5523. It is a little expensive, has too many outputs and needs a level shifter. My reasoning here is that, electrically, it is exactly what is needed, plus I know that I am going to be using this in clocks with a greater number of tubes. However, I am going to need a level shifter...

SPI and Level Shifting

Ah. Ignorance is bliss. My testbed has used a variety of Microchip HV devices, which I have apparently been driving out of spec sometimes, in terms of sink current rating. What they all have in common is that they are 5V devices, and the ESP8266 is a 3.3V device, so I have been a good boy and used a level shifter. After I destroyed one (remember kiddies, always turn the device off before you start re-wiring it!), I ended up using the CD40109B, which has worked great. The datasheet for this on the TI site is clearly scanned from some print copy. I guess this has been around so long that they somehow misplaced the original electronic version? Who knows?

Anyway, not pausing to find out how SPI works electrically, I just used it and it all worked fine. Now, when I am faced with trying to find an SMD part, I started reading the datasheets for the candidate level shifters and they all start talking about how applicable it is for open drain busses, open collector busses, I2C, SPI, whether you should have pullups, etc. etc. etc. So there followed several days of trying to understand how SPI works v. I2C.

To summarize, SPI is push-pull. All the signals are either high or low, they are never Hi-Z, aka disconnected, aka floating, aka tri-state. Except for MISO (Master In, Slave Out: Used when the slave wants to send data back to the master). MISO is set to floating when the slave isn't sending data. This is important if:

1. You have a slave that wants to send data, and...
2. You have more than one slave.

What does a level shifter do with a floating signal? Who knows? It could float the other side, if it could figure out that it was floating in the first place.

The upshot is that some level shifters have internal pullups and some don't. We don't use MISO and we only have one slave anyway so we don't care about floating signals. So for us, a level shifter with internal pullups will be fine, and I'll leave concerns about how a level shifter might cope with floating signals for another day.

At least I think that is the case, so I am ordering both a QFN version and a SOIC version of the TXS0104. I will solder the SOIC version to a breadboard adapter and check that it works on my breadboard.

SPI and The ESP8266

While I am at it, figuring out how SPI actually works, I thought I would double check what the ESP8266 is doing with the pins I am using. This is complicated:

1. The ESP8266 has internal pullups on all of its GPIOs except for GPIO16, which has a pulldown.
2. Most boards add external pullup and pulldown resistors to certain pins so that the semantics of programming and serial communications actually work. So there are additional pullups on:
   1. GPIO0
   2. GPIO2
3. And a pulldown resistor on:
   1. GPIO15

This only matters if we are going to float a line. We aren't, so we don't care. However my code does use the pins that are earmarked for SPI - i.e. the pins that the arduino SPI library for the ESP8266 expects them to be on. Namely:

• CLK is GPIO14
• MOSI (aka data out) is GPIO13

In addition the HV chips use something variously called Latch Enable or Strobe and Blanking.

• LE is GPIO12, which would normally be MISO. Perhaps I should use GPIO15, which would normally Slave Select?
• BL is GPIO15. If we PWM this we can dim the nixie. However, I can do way better in software because I can implement various forms of fading, like cross-fading, so in reality I probably won't use this. Plus, this is supposed to be Slave Select.

For a while I have been putting together some reference hardware for a Nixies clock, and using it to test out some assumptions - basically, can I program it to do everything I want? So some basic requirements were:

1. Can be re-programmed without dismantling it!
2. Has a WiFi connection
3. Can drive six Nixie tubes
4. Can drive tube backlights
5. Has a light sensor.
6. Can dim the Nixies.
7. Can turn off the HV side of the circuit
8. Can be driven from USB and optionally LiPo
9. Can take up to three button inputs.
10. Can include an accelerometer.

What you see below is basically that.

A. Is a Wemos D1 mini pro. It is basically an ESP8266 with all of the GPIOs broken out and it has a USB input. So this satisfies requirements 1, 2 and 8 in one go. What you can actually see is an OLED shield on which I am displaying some debug information.

B. Is a test colon-separator, an IN-3. I needed to develop the circuitry to drive it.

C, D and F are different implementations of a constant current source. I could use one of these instead of a current-limiting resistor.

E. Is one of my HV power supplies that I documented in another project log here on hackaday.io.

G. Is a connection to a NeoPixel on my adapter board. By using neopixels rather than RGB LEDs, I only have to dedicate one GPIO pin, and I can make each of them do something different if I want.

H. Is an HV9808. This is a high voltage shift register. It has 32 outputs, so it can drive three nixies plus change. It uses four GPIOs and is easily controlled using the SPI library. This particular chip uses 5V control levels and they can be daisy-chained together so I can control as many nixies as I like, with just the four GPIO pins.

I. Is a level shifter. The ESP8266 is a 3.3V chip, the HV9808 is a 5V chip. Sigh.

J. Is an accelerometer. It has an I2C interface, so it takes two GPIO pins, which it shares with any other I2C chips. It also happens to have an analog input, so I connected a light sensitive resistor to it.

K. Is an IO expander - it adds a bunch more digital out and analog in ports. Is also uses an I2C interface.

L. Is a test button connected to the IO expander.

M. Is the light sensitive resistor.

N. Is an actual nixie tube (an IN-12B) plugged in to one of my adapter boards.

The aim here was to test that everything I though I might need could actually be made to play nicely together. So far it does. My clock  code does dimming, cross fading, HSV LED cycling, network time synchronization, reads the accelerometer, displays debug on the OLED, reads the button, controls an LED on the IO expander, presents a web page and I can program it over the air.

One thing noticeable by its absence is an RTC chip. With network time synchronization that automatically adjusts for timezone and DST, why would I need one? The ESP8266 clock is enough to keep time in between synchronizations. Still, I should probably add one just for completeness.

Here are some videos of it in action. The first is a little blurry, but it shows off the backlighting too. The nixie is a GR10J numicator (swoon):

This one is of CD-12 and shows the clock display a little better:

Anyway, we won't need all of this in my one-tube clock, and we'll change up some of the components while we're at it.