Nixie Pipe is my interpretation of a modern day Nixie Tube – the cold-cathode vacuum gas-filled tubes from the 1960s.
The project came about when I decided to make a clock for my kitchen, with specific requirement for an egg timer function! I’ve always wanted to make a Nixie Tube clock but having completed a Nixie Tube project recently and one pipe failing after around 6,000 hours, I wanted to come up this something better. Something that didn’t require high voltages, special driving circuitry, could be easily interfaced and was modular, but which maintained the unique visual depth of a Nixie Tube. Continue reading Nixie Pipe – Modern Day LED Nixie Tube
A need popped up at work for a data logger for various lab tasks. Quickly looking at the market, I failed to identify a lab tool for data logging (cheap, easy but powerful setup, remote access); something for researchers and scientists. I decided a Raspberry Pi with some input buffering would be ideal for the task. This is my roll your own data logger, put together on Saturday – showing what is possible quickly and potential with more development time.
My dad was impressed by my nixie tube energy meter project and expressed interest in his own. Unfortunately, the power inlet for his house was under the stairs and out of view, unlike mine in the corridor. Undeterred and with his birthday coming, I revised the design to be stand-alone with a remote sensor unit.
Having recently bought a house, project time has been a bit thin on the ground. As a standard terrace house, the consumer unit and electricity meter were in the entrance hallway, exposed and looking a bit naff. I liked the look of the meter so I quickly created a box that allowed the meter to poke through and leave access to the fuses.
The box covering did the job but felt a bit cumbersome with all that spare space; it needed something else to give it more purpose. An energy meter was the obvious thing but I didn’t want a garish LCD or 7 segment display, it need to match the blown glass electricity meter… …nixie tubes!
Following on from adding support to wiringPi for the MCP4725 DAC, I wanted to add driver blocks to Simulink such that one could use them to create graphical models for the Raspberry Pi that could interface with the real-world – a workable alternative to expensive real-time targets.
My laser cut binary clock, Wooden Bits, originally had no means to set the clock, other than at compile time. I later added a tactile button and ISR to provide this function (increment the time until the correct time is shown) but I wanted a way to tap into the extra features of the DS3231 (alarm, temperature) and also to experiment in wireless control.
The Raspberry Pi lacks a DAC but using the I2C bus, one can easily add a device like the 12bit MCP4725. The GPIO library wiringPi provides support for I2C devices, however, getting the MCP4725 working with it isn’t a simple as one might hope. The device is 12bit but the I2C protocol works on bytes (8bits). To send 12bit data, the Microchip designed the message transfer like this:
Continuing on from my Ambient Noise Level Indicator, I wanted to create an enclosure and make it stand-alone – not requiring a computer to do the processing. I ended up with a little device that converts noise amplitude to the light spectrum: Noise Crayon.
The Ambient Noise Level Indicator used the MCU serial host Processing to perform a FFT and various averaging routines to create an indicator for ambient noise. The idea being that it would change colour when background levels rise above a threshold. Moving to an ATMEGA328, performing this processing – especially the FFT – is asking a little too much of it. There are libraries but I’ve heard of limited successes.
Simulink Embedded Coder offers an ARM Cortex-M support toolbox, which includes code optimisation for the MCU and QEMU emulation but lacks any S-Block drivers for the device. The lack of drivers limits the Simulink development to merely number crunching. You can create cevel blocks that execute external C functions but this requires separate source files with a shared header and pre-defined initialisation, leaving the model without full control of the hardware. In this post, I go over the process of creating hardware driver S-Blocks.
The Atmel Studio IDE is a useful tool thanks to the comprehensive debugging support and management of project drivers via the Atmel Software Framework (ASF) – coming from a hardcore Vim advocate. One thing I dislike about IDEs is the fact they hide the make process from the user making it difficult to break a project away from the software. On wishing to develop code on different operating systems (being Visual Studio based, Atmel Studio is limited to Windows), and outside the IDE, I set about creating a Makefile for an Atmel Studio project built around the ASF.