Nixie clocks

Some clocks I’ve made:

Lethal Nixie Clock

Lethal Nixie Clock

Clock 1 schematic

Clock 1 schematic

Clock 1: Single tube Lethal Nixie clock — you know having all the high voltage lines exposed and un-insulated. Inspiration for this design was from this clock. Unfortunately I built mine right after having surgery. I think the painkillers had something to do with the aesthetics… Anyhow I wasn’t electrocuted while building it under the meds…That’s always a plus!

Pinout and some key components

Clock 1 Pinout and key components

ATMEGA 328 arduino with a DS1307 RTC for timekeeping. Basically the arduino pulls time from the RTC then updates IO. During this it’s got a time based ISR that: interrupts the code, measures the high voltage, then makes necessary tweaks to the boost converter duty cycle via a proportional controller. Alright let’s get to me gabbing on about it in the video. I forgot to show how to set the time in the video, here’s a quick video on that. Arduino Code here.

Main circuit schematic of the 4 tube nixie

Clock 2 main schematic

Clock 2: Four tube nixie clock. Very similar to the previous clock but uses i2c GPIO port expanders for all the tube outputs, and a GPS instead of a DS1307. This clock just needs some final tube aligning and some buttons to change the time zone! Everything’s implemented on the board/code side. Code for it is here. Just a heads up this is a ‘guide’ to making one, not instructions.

Each individual nixie tube schematic

Clock 2 individual nixie tube schematic

The individual nixie tubes have the same repetitive circuit for each cathode, here’s what one cathode


Clock 2 protoboard header layout

looks like (you’ll need to make 10 replications for a tube that needs to display 0-9, for like the tens minutes you’ll only need 0-5 cathodes to work. The gpio expander boards all connect to the same I2c bus. There’s jumpers on the MCP that select the i2c address, these jumpers are different on each tube to allow the microcontroller to control each one individually.Anyway VIDEO PART2, PART3 here. I did a lot of explanation in the video’s, so I’ll keep this post brief.

pinout mapping of nixie tube

Clock 2 Pinout mapping of nixie tube

Finally Clock 3 (Not a nixie!):

This is when I look back and think “I really make too many clocks…”, I’ll keep this one brief. This is a clock based on a ~3 inch TFT with touchscreen with Teensy3.1. It generates fractals thanks to a julia2 fractal algorithm I found online. My code randomly tweaks some of the constants that determine shapes/colors in the julia2 algorithm to keep things fresh.

As you can see it graphs temperature, humidity, barometric pressure over a 2 day period. The vertical markers represent 6 hours. The graph auto


Fractal Clock

zooms/offsets each sensor’s data to keep it looking nice with the mins/max displayed at top and bottom per graph. The 3d printed case insulates the insides, so the temperature is a bit high — i need to print one with more vents.  Time is set by the touch screen (video doesn’t show that). As you can see I actually made this clock quite some time ago. Source code here.

I did a game of life with this library too. I meant to make a clock where the game of life would randomly get organisms added that would eat away at the time. This code also demonstrates the graph algorithm that auto scales/auto offsets.

Clock 4:

Hey remember that original clock? I also made a kit I had up on ebay for a while. PCB was designed with CircuitMaker, PCB manufactured by OSHpark


Ebay kit of the ‘lethal nixie tube clock’

Xbee hive


xbee galore!

Well summer is over! I ended up doing my internship at Caterpillar and had a delightful time! I especially loved the cafe there! The D11, D7E, and 735 articulated truck were cool too.

I really hope to post some more how-to guides probably related to RF modules… I’ve been working with some ultra low cost RF modules from sparkfun and just starting to do some work with XBees after an awesome donation! I have around 60 pro/standard series 1/prototype (mostly standard) xbee modules!

wireless wii nunchuck mouse

I just haven’t had the time to write about many of my other projects. Here’s a wireless wii nunchuck mouse, and it uses a 5v limited joule theif for the power supply. This is great since it runs down to 1v. The receiver acts as a HID device with basic error detection and those low end modules are only a one way link, so it would just throw out the reading if any error was calculated.

As far as my next guide topics i’m certainly open to suggestions. Possibly a part 2 mosfet guide that goes into more detail about calculating current, power dissipation, resistive feedback, and triode regions. Maybe a BJT intro guide or something else…

Self balancing robot

Ugly! Accelerometer in wii nunchuck, Gyro in Wii motion plus (right side)

In the near future I really want to build a quadrocopter, and would possibly need to do this for two of the interns I’ve been pursuing (NASA JPL or OSF). I was trying to figure out a good place to start and actually get some tests in. After doing some thinking I assume that a quad’s control system is similar to a self balancing robot only in two axis. On a quad I would read the pulses coming from a tx/rx system to adjust the target balancing angle. So far I’ve only put in two days into this robot, yes I am aware that I may not be approaching this the best way! please leave advice! So far it’s been 1 day to get the wii motion plus working with the wii nunchuck (they have the same I2C address…), and 1 day writing the software and building the robot. Everything is very rough so far, so I’m going to wait to post the source code! If you want a copy please leave a comment and I’ll send you the three versions! Once I get more familiar, I’ll surely write a very detailed guide!

Control system:

My current control system. Edit: I calculate angle from the accelerometer right after the offset and scaling.

I’m using a complementary filter, which is used to combine a gyro (accurate but drifts over time) and an accelerometer (not so accurate but doesn’t drift). Anyway look at the control picture to see exactly how I’m doing the calculations. Everything underlined in blue I want to get rid of/move. Possibly I will want to keep the MA so that I can do a standard deviation. The standard deviation could help the platform tune the complementary filter. A high standard deviation for the accelerometer would tune the complimentary filter constants to .999(gyro)/.001(accel) where as a low standard deviation may set it to .95(gyro)/.05(accel) and make it a continuous tuning function.  I’ve also been brainstorming on methods that would allow robot calculate the balancing angle for the platform. As far as phase shift: I’m not too worried about the accelerometer’s phase shift due to the filters, but the gyro needs the phase shift to be an absolute minimum!

Talking to two I2C devices with the same address. Had to include my new tool - saleae logic analyzer

How I would improve results:

The wii motion plus is a ~20$ three axis 2000deg/sec gyro with a plastic case, sockets, PCB, and a I2C pass through chip. This really isn’t the right type of gyro for this type of robot, and I seriously question the quality of the gyros on board. I can say the same for the accelerometer on the wii nunchuck too. I’ve also thought of a few ways to calibrate the system and get the gyro/accel units to match up with each other. Regardless the results are pretty good and I may just need to tune everything. Those servos are also slow as beans! My plans are to replace the gyros with less than 500deg/sec gyros, clean up the algorithm and work on perfecting it! I also need to put the IMU on the pivoting point of the platform.


segway05 – I probably won’t get around to taking another wack at this till summer, so here’s the most recent code. Not many comments other than the blatant mistakes pointed out.

Great resources:

Complementary filter by MIT

Tilt with accelerometer

Calculating angles with accelerometer

Using wii nunchuck and Accelerometer together – Just an FYI if you disable the Wii motion plus to talk to the nunchuck via passthrough port, the wii motion plus takes about 100ms to turn back on which is SLOW. I don’t  have a wiimote/wii, so I can’t listen in on them talking with my logic analyzer. This method is good since both devices have the same I2C address…


Sorry about the terribad quality videos!