The great promise of open source hardware is the chance to build something better as a community than just one engineer in a lab. Sites like Github have been promoting community-based software development for many years. Sites like Hackaday.io and Hackster.io started this concept for electronic DIY hardware. With that goal in mind and for this blog entry, you, the reader, can help make this project better.
This project is still not done, but is “in development” and that is a good thing. Instead of waiting until total completion, readers are seeing the content during the development phase, the work progress is highlighted, bugs are described, and comments are encouraged. The reader can even join in by building their own prototype. The goal is that by getting feedback, the project will be better and meet more reader’s needs than by keeping the project from the world and readers until completion. What would you change in the project to make it better?
This project came about because I needed a retro looking linear meter for my espresso maker water tank. I’m always running out of water in my espresso maker, and a cool display letting me know how much water is left and to let me know when to fill it up is definitely needed. In this project, I’ll create a HAT for the Raspberry Pi that can drive two IN-9 or IN-13 linear Nixie tubes. While I’m using this HAT as a single water meter display, this same linear display would be great for showing temperature, bar graphs, audio VU meters, even surf heights by days of the week. The Nixie Tube Power Supply, designed in an earlier blog will work perfectly to drive up to four of the IN-13 Nixie tubes or one IN-9 Nixie tube.
Part 1 of the blog will describe the scope of the project, show the design, initial schematics and prototype results, and elicit feedback from the reader. Do you have a suggestion to make this project better? Have I forgotten a step or feature that is needed for your use? You can build your own version of the layout by forking the project yourself from Github. Or you can just read and see how I do on my development flow and the changes I discover or get from the readers. In Part 2 of the blog, I’ll put the PCB assembly together to verify results and see how the display looks.
This project has completed 4 of 9 stages, a great stage to get feedback from readers. The specifications were written, a prototype was tested and improved, the python code library was started, a BOM was put together, and the PCB layout completed. While that may seem like a lot, there is still a lot more to do and refine and why now is a good time that the reader can help. In my world of product development, the perfectly executed project has nine stages as listed below.
- Stage 1: Project Concept and Scope
- State 2: Prototype Schematic and Code
- Stage 3: Prototype System Testing
- Stage 4: Initial Schematic, Layout, BOM Complete
- Stage 5: Initial Production and Verification
- Stage 6: Production Schematic, Layout and BOM complete
- Stage 7: Limited Production Run
- Stage 8: Final Update to schematic, layout, and BOM
- Stage 9: Full Production Run
If you look carefully at the steps above, these nine stages can be simplified into three design, test, and debug steps repeated three times. After stage 1 where the scope and concept are described, the stages are then to design, test, and debug the system during the prototype phase, the initial production run, and the limited production run. Only after these iterations do you have a system that can be ready for a full production run at stage 9.
At each of the repeated stages, there is an opportunity to change the project scope or capability. It would be great if the perfectly scoped project could be described in stage 1. Since this is virtually never the case, instead of accepting this limitation, let us exploit it by allowing input from the community. While this project is at stage 4 now, changes can be applied in Stage 5 to make it better.
While product plans can use fewer steps and you can spend more time per stage to reduce the number of design, test, and debug phases you have, my experience shows that these 9 stages are the optimum amount. A product going to full production would need all nine stages, but fun products that are the subject of www.surfncircuits.com blog normally end at stage six. For Part 1 of this blog, the project has completed stage 4. I have a complete prototype system running along with code and an initial schematic, BOM and Layout. The initial production run bring-up, verification, modification, and more will be the subject of Part 2.
Project Concept and Scope
This project develops an IN-9 and IN-13 Nixie Tube HAT for the Raspberry Pi zero and works in conjunction with the Nixie Tube Power Supply developed in an earlier blog. The HAT will have the capability to drive two linear Nixie Tubes. In addition to the HAT, a python library will interface with the HAT along with providing a tool for testing and burn-in of Nixie bar graph IN-9 and IN-13 tubes that have Cathode poisoning. Below is a list of the HAT specs :
- Two Independent Linear Tube drives
- Each tube will have a dimmer switch
- Nixie Tube Power Supply will directly power HAT
- HAT can power the Raspberry Pi
- The bandwidth of tube drivers are greater than 20kHz
- Python Library uses the pigpio library
- Use Raspberry Pi Hardware PWMs IOs
- Rpi Zero Audio can drive HAT as VU meter
- Each Drive can source 15mA current
- Common source drive circuit to accurately current drive without feedback (no base current loss)
- Low pass filter PWM to eliminate IC DAC
- Kicad 2-layer PCB dimensions are the same as Raspberry Pi Zero.
The KiCad Schematic, Layout and BOM is available for download and viewing with the link above. The two Nixie tubes are driven directly from Raspberry Pi Hardware PWM outputs (GPIO #18 and GPIO #13) using precision MOSFET (Q1 and Q3) drive current sources. There is a dimming capability using Q2 and Q4 that also are controlled by 50Hz PWM GPIO outputs from the Raspberry Pi.
The NixieBarGraph HAT is designed to power and mount on top of the Raspberry Pi Zero and has all the connections to be driven from the 5v to 170v Nixie Tube power supply designed in an earlier blog. The PCB layout is on Github but also orderable at OSHPARK.
Dimming and Linear Nixie Tube Issues
Transistors Q2 and Q4 allow both allow for dimming the Nixie Tubes and for ensuring proper Nixie ignition of the Nixie Tube from the bottom. These transistors are controlled with 50Hz PWM signals and duplicate how Nixie Tubes were often driven in the ’70s, by the AC voltage. A duty ratio of 90% will not show any dimming and ensure proper lighting of the signal. However as the duty ratio is dropped below 90%, the Nixie will start to dim.
Nixie Tube Driver Bandwidth Design
My first design attempt at the MOSFET driver circuit showed lots of oscillation in the op-amps U1 and U3 outputs. In this first attempt, I did not have the R6/C8 and R10/C9 in the feedback loops of each op-amp. I learned that care must be taken when driving MOSFETS as current sources within the feedback loop of voltage follower op-amp. Most Nixie driving circuits use high voltage NPN transistors for Q1 and Q3. This is fine, but it has the drawback of some current source inaccuracy due to the NPN base current. the feedback voltage across R12 and R4 will have some base current and does not exactly equal the Nixie current. By using MOSFETs for Q1 and Q3, this base current drops to zero, but the gate resistor and gate capacitance will introduce a high-frequency gain boost into the feedback network that will cause most op-amps to oscillate without proper compensation. For this reason, Resistor R6 and C8 were added to the left Channel and R10 and C9 were added to the right channel to reduce this high-frequency gain and maintain stability.
My plan is to fine-tune the bandwidth of the gate drive network through simulation to reach 20kHz bandwidth. I expect I may need to reduce R2 and R9. This will be in Part 2 of the blog.
The Python Library at the link above can be used so the Nixie tube bar graph HAT can be used as a linear display for the different Raspberry Pi projects. Just download the library to the Raspberry Pi using the usual git clone methodology. The library can also be run as a stand-alone program to test and burn-in IN-9 and IN-13 Nixie tubes.
Use the following commands to run the python library as a stand-alone program.
sudo pigpiod python Python-RpiIN9Nixie.py TUBE_TYPE
The pigpiod daemon is used by the library to access the hardware PWM outputs. The instructions for installing this daemon are shown at the site and the references at the end of this blog. It can also be configured to start at power-up of the Raspberry pi. The additional TUBE_TYPE parameter needed for the python library to run as a stand-alone program is either IN-13 or IN-9 and sets the default maximum current. With the IN-13 option, the maximum current is just 5mA. With the IN-9 option, the default maximum current is 13ma.
Using the Hardware PWM peripherals of the Raspberry Pi SOC provides a high accuracy PWM and frees up the processor to execute other code for the project. One particular example would be to output audio over I2S to an external high accuracy DAC, but also pipe a version through the Hardware PWM to drive the Nixie Tube VU meter. I hope to dig into the code for this feature in a later version. Is this of interest to you?
Nixie Tube Burn-in
The Code also has a burn-in feature to purposely overdrive the Nixie’s by 20%, helping to speed up the repair of cathode poisoning for older tubes. In the batch of IN-9 and IN-13 tubes I recently purchased, this feature helped to get the complete tube to light up.
Help Make this project better
What would you do to make this open source hardware project better? What have I forgotten? What do you need to use this dual Nixie Bar Graph driver system in your project? Please add a comment below so we can make this better. Or branch it and make your own modifications and project. Just let us know so we can see what improvements you have made.