Building the Elector Nixie clock

The retro looks of Nixie tubes sure is something that many people can appreciate including myself. Browsing the internet you’ll find several popular usages of these ancient electronic relics such as clocks thermometers, VA-meters and more. The tubes itself are not always literally ancient though, they’re still build and sold brand new so when you start looking around you should still be able to grab a few for your own. But I’ll warn you: the do not come cheap!

Enter the Electro Nixie clock! Elector has been offering a kit where you can build your own Nixie clock yourselves. Given that those tubes take a high voltage I thought it would not be a bad idea to try the kit instead of doing the full electronics design and such myself. It comes with a members discount plus I got special discount which made the price more acceptable. Elector also designed a housing for it to give it that extra spark as you can see below. I went for the Elector deal but didn’t go for the acrylic housing because I wasn’t particularly found on that. So now I have to come up with something of my own… For that I take you on this little trip that shows you how ‘easily’ it is nowadays to come up with something that even your wife may appreciate!

So I started drawing…

I gave it a first try crafting all of that by hand but the end result looked really ridiculous: the wife didn’t agree! With the right tools this is going to be so much better. Then I remembered there is nowadays a python plugin that can generate a complete drawing of a box for you so that you don’t need to worry about all the details anymore. And guess what: someone made a website for that! Boxes.py is the place to be.

I went for the BasedBox design, here are my settings:

But I wanted to add a little detail myself, I wanted to have a black front. Luckily the generated files from boxes.py are in the svg format which can easily be edited on linux using with Inkscape. An hour later (I’m not a very skilled Inkscape user) I got to my final drawing:

For the front plate I came up with following design:

Next step was getting it produced using laser cutting techniques. The guys at Snijlab.nl allow you easily upload your drawing in all sorts of formats. They have a wide range of materials that you can choice from, the website works really well and by the end of the route you get a final offer so that you don’t get any surprises when you order your stuff. Few days later the goods arrived at home and we could start assembling thins…

First I had to drill some holes in the bottom and back so that I could fix the PCB, power supply connector and user switch.

To fix the front plate without visual screws I also had to cut an aluminum plate on which we can glue the front plate:

And then comes the final stage: putting the box together:

I hope you like the end result, and I hope this inspires you to get building yourself. Good luck!

Creating an IoT thermostat (part V)

UI teaser

Here is a first teaser of the UI:

Arduino and AD7410 I²C temp sensor

On request, the source code of using the Analog Devices AD7410 I²C temp sensor. (Datasheet: adt7410)

#include <Wire.h>

//ADT7410 13/16-bit digital temperature sensor
//RED (VDD): 2.7 ... 5.5V
//BROWN (GND): 0V
//Arduino uno, wires:
//PURPLE 1 (SCL): SCL (near AREF, should be equal to ANALOG5)
//PURPLE 2 (SDA): SDA (near AREF, should be equal to ANALOG4)
//Arduino due, wires:
//PURPLE 1 (SCL): SCL (pin 21)
//PURPLE 2 (SDA): SDA = (pin 20)
//Arduino IDE 1.5 compatible

#define ADT7410_I2C_ADDRESS 0x48
#define tempRegister 0x00
#define configRegister 0x03
#define selectCode16bitMode 0x80


void setup() {
  Wire.begin();        // join i2c bus (address optional for master)
  Serial.begin(9600); // serial connection
  set16bitMode();
}




void loop() {
  delay(5000);
  serieelPrint(); //print on serial port
}


//set ADT7410 in 16-bit temp value mode
void set16bitMode() 
{
  Serial.println("Setting 16-bit mode...");
  Wire.beginTransmission(ADT7410_I2C_ADDRESS);
  Wire.write(configRegister);
  Wire.write(selectCode16bitMode);
}



//gives back the temperature value
float readTemp()
{
  //set read register
  Wire.beginTransmission(ADT7410_I2C_ADDRESS);
  Wire.write(tempRegister);
  Wire.endTransmission();
  //receive data
  Wire.requestFrom(ADT7410_I2C_ADDRESS, 2);
  byte MSB = Wire.read();
  byte LSB = Wire.read();
  
  //check for positive or negative sign
  boolean sign;
  if(MSB>0xA0) {
    sign=0; //negative
  } else {
    sign=1; //positive
  }
  
  //concat MSB&LSB
  float tempValue = MSB * 256;
  tempValue+=LSB;
  
  //BIN to DEC
  if(!(sign)){
    tempValue-=65536;
  }
  tempValue/=128;
  
  return tempValue;
}

void serieelPrint()
{
  Serial.print("Unit: ");
  Serial.print(ADT7410_I2C_ADDRESS, HEX);
  Serial.print(" *** temperature: ");
  //temperature readout
  Serial.print(readTemp());
  Serial.println(" degrees Celcius");
}

UPDATE: you can find my Arduino library here: https://github.com/geoffrey-vl/Easy_ADT7410_Arduino_Library

Self Synchronizing Wifi Clock, V2

Since my last encounter with a self synchronizing wifi clock I ended up learning how to implement my own display driver. Unfortunately the display died on me when testing it on a new power supply (which appeared to be malfunctioning afterwards) and so I have been thinking of porting my code to use the Adafruit 2.8″ display. Pretty much most of the functionality remains from what I’ve made before, the most interesting thing I wanted to add this time was making use of the resistive touch screen. I could easily made a basic GUI to adjust settings and so on, but by some unknown reason I can’t get the touch positioning to work reliable on the Due board. Though it does function on Uno, Uno does not offer the needed program space (I’m at 40~50k). So, all together there is not much to it, but here is what I ended up with:

Next, I’ll check if there is the possibility to hook it up to Raspberry Pi and control it using NodeJS. Enjoy the holidays, see you in 2015!

Self Synchronizing Wifi Clock

In a previous serie of articles I showed you my progress in writing a Arduino Due driver for the Adafruit 16×32 LED matrix. Last few days I’ve focussed more on adding support for a simple font and displaying text characters, but actually during this implementation I discovered the solution behind 2 programming mistakes that were still left in the driver code. With this solved, I starting thinking about how to implement a font. After thinking of my own way of implementing this I also looked at how it was done in the original driver for Arduino Uno and actually some of the ideas matched. So I could really easy copy, adjust and implement the code for displaying characters, displaying ‘HELLO’ is now a matter of writing 6 lines of code!

After this I implemented code for reading a I2C compatible ADT7410 temperature sensor and use it for displaying the room temperature. Next I included and implemented code I’d already written before which allowed me to use the Adafruit C3300 (Wifi / SD) shield. The code connects the Arduino to the local WLAN and do NTP request to synchronize a software made clock with the internet. Furthermore it can also read and write data from/to an SD card. The SD card is used to hold the WLAN settings, it does this at boot time and it is only milliseconds later when it will use this data to configure and make the WiFi connection to you LAN. Voila, altogether there we have it: an Arduino based self synchronizing clock!

Progress: Adafruit 16×32 LED matrix on Arduino Due (5)

Past couple of days I’ve been working on abstracting and hiding the actual display driver code from the main Arduino project., this involves writing C++ code in an object oriented way. Although I’m used to work with objects in Java and C#, my experience with C++ classes, arrays and pointers is rather limited. And so it took me quite some time to get it all working in an n-tier architecture, but in the end trial and error got me through it and at this moment it is working more or less okay. The phone camera is still taking messy pictures, but you get the picture I’d guess:

The benefits from using this n-tier architecture is that now all driver code and display logic are concentrated in the same file, plus one can easily replace the driver without affecting code at other layers. While the color correctness is still not 100% working okay, my next goal is to add more logic that allows me to easily draw chars or circles or whatever. Furthermore it would also be great if I could send images over the serial bus and finally put some use to the driver I’ve been working on past few weeks. In the mean time also have a look at this guys project: http://bikerglen.com/projects/lighting/led-panel-1up/. He uses the same panel but instead uses an FPGA as hardware platform to drive the display. He clearly shows the power of FPGA’s in driving displays, to do the same in sequential microprocessor code things would get really complicated if not impossible to do.

Adafruit 16×32 LED matrix on Arduino Due (4)

I’m finally making some progress with introducing a higher color depth. Using BCM I’m now more or less on a 12-bit color depth. In the Adafruit driver I found parts of code that first were not very clear to me. There are methods like Color888(uint8_t r, uint8_t g, uint8_t b) and Color333(uint8_t r, uint8_t g, uint8_t b) but than I found that these are actually related to how colors are kept in memory bit wise. You see, with 333 colors you’re using 3 bits for the red value, 3 for green and 3 for blue. So this means there is a total bit depth of 0…7 for each RGB value resulting in a total 9-bit color depth which gives us 512 colors. 8/8/8 colors are 24-bit large in total and are the so called True Colors. They’re often used on PC’s in results in different colors. The 5/6/5 colors, also called High Colors, are 5+6+5 = 16 bits wide and result in 65536 different colors. This is also often used on computers. The awkwardness here is that the green portion has one bit extra compared to the red and blue portion. This is done because there was otherwise one bit unused (better to use it right!) and because of our perception is green is different that for red/blue one bit extra for green would be best suited (don’t ask me the exact scientifical reason, look for it on wikipedia). This 16-bit color depth is also used for storing images in the Adafruit driver. But so far it’s used only for storing, to display these images the driver falls back to a 12-bit color depth in 4/4/4 format and this because of two reasons. More colors would be kind of hard to do because it would dramatically reduce refresh rate and this you certainly don’t want. Although LEDs are used, refresh rates in between 25 and 50MHz are still not high enough for the human eye to experience the display as smooth. So it’s better to stuck at 12-bits deep. Also, in the 5/6/5 setup, if you use BCM modulation, there is one moment where you’ll be displaying only the green portion because red and blue are not equally in bit size.

But BCM, what is this exactly. BCM is a modulation technique like PWM is. With PWM you define the percentage of on and off time. Say you’re having a pulse of 70% on and 30% off during the total period, if you have a LED connected to that pulse you’ll experience it as slightly dimmed. With BCM you’re not giving any percentages, you’re using the bit value instead. Let’s say you’re using 2-bit BCM, for this the 2 bits are divided over the total period and so the more ‘1’s you have in your binary BCM value the more the LED will be pulsed on during the period, and the brighter it will look. Let’s say you’ve the value 11, the LED will be set on for the total period of time and will look very bright. 00 means it will be off all the time. But what about 01 and 10? Well, here the bit-value comes into play otherwise both codes would result in 50% on and 50% off. Using the bit-value the ‘1’ in ’10’ has a higher bit value than the ‘1’ in ’01’ and so it will stay on longer depending on the weight of the bit. There is a nice introduction to BCM found here.

And so the Adafruit driver uses 4-bit BCM, using only the 4 most significant bits of their 16-bit (5/6/5) representation in memory. I’ve gone the same direction and got it more or less functional:

This lowres picture doesn’t exactly show you a lot, I’ll have to look for better photo footage. The higher color depth is now possible using BCM but it’s still not finished yet. Resetting the timer each time kind of screws up the refresh rates so instead of using the due timer library I talked of before I’ll have to write the timer code myself and cut off an overhead. Also I noticed that I’m doing a lot of digital writes (6) to set just the RGB pins, where in the Adafruit driver they can set all 6 pins altogether. If a could do this it would also greatly reduce the timer interrupt time and allow me to bump up the refresh rate. So, more work ahead…

About Arduino’s DigitalWrite – Adafruit 16×32 LED matrix on Arduino Due (3)

In the previous article I already noticed how the display was starting to get less bright when I bumped up the refresh rate. Reading some parts of the Arduino Uno driver I noticed this one comment hinting to the slow Arduino DigitalWrite function. I never knew or red about this function not being very fast, I was expecting maybe a little impact but not as much as described in some online articles. And so I began to think of also looking for a way to faster manipulate pin outputs so that the driver works faster and better, and maybe allow us to do more than before. For Arduino Uno there is tons of information to find, however for Due you have to look a lot better. On the Arduino forums however I found this thread where faster port manipulation code has been presented:

inline void digitalWriteDirect(int pin, boolean val){
  if(val) g_APinDescription[pin].pPort -> PIO_SODR = g_APinDescription[pin].ulPin;
  else    g_APinDescription[pin].pPort -> PIO_CODR = g_APinDescription[pin].ulPin;
}

inline int digitalReadDirect(int pin){
  return !!(g_APinDescription[pin].pPort -> PIO_PDSR & g_APinDescription[pin].ulPin);
}

void setup() {                
  pinMode(13, OUTPUT);     
  pinMode(12, INPUT);     
  Serial.begin(9600);
}

void loop() {
  digitalWriteDirect(13, HIGH);   
  delay(1000);           
  digitalWriteDirect(13, LOW);    
  delay(1000);          
  Serial.println(digitalReadDirect(12));
}

In my current driver I swapped all digitalWrite methods with the digitalWriteDirect methods from above and than compared how fast writing one (double) row of LEDs goes. Time was measured by calling the micros() method before and after writing on row of data, taking the difference of both and next report back by doing a single Serial.write(). Here is a comparison:
digitalWriteDirect: 91us
digitalWrite: 661us
So as you can see the direct implementation gives us nearly 7 times better performance, or the other way around I kind nearly draw the entire display this time where before I could draw only one row. I also now noticed that in my display only the last rows of each half screen were illuminating very bright while others where nearly not illuminating at all. The reason is because now we switch so fast from one row to the next that the HIGH time of the pixels in a row is very small compared to before when using the slow Arduino implementation. The reason why the last row was however bright is because it get’s drawn as last and from here on it takes nearly 5000us before the next interrupt is being called, so it is really obvious that it was appearing really bright. In my last update I changed to drawing only one row per timer interrupt. This way rows get painted on a steady time base, and with using the faster digitalWriteDirect method we can easily bump up the refresh rate of the display so now the interrupt routine gets called 8 times more than before.
Next problem I get is that I need to call the interrupt code each 1250us in order to get a steady image. That is a 800MHz refresh rate per pixel row, and so 100Hz for the entire display, which kinds of bothers me because now interrupt code will interrupt normal program flow a lot of times, and I’m still at only 3 bit colors and I don’t have any support for dimming. I guess there is more reading ahead of me…

Adafruit 16×32 LED matrix on Arduino Due (2)

Not to much time spend so far on this display, but before I continued I wanted to make sure I can make the display illuminate asynchronously with the rest of the program flow. To do this we need to use interrupts which is launched after a certain timer expires. This way we can for example make sure that every 5ms the pixels are refreshed so that we get a clear non-flickering image. This also allows us to program our normal program code in the loop method without having to worry about the display code not being called in time (because then the display would go black for some time). For Arduino Uno the code is already there in the IDE to use, for Due a guy named Ivan Seidel already did some testing and programming and so we can also make use of interrupts on Due really easy (library on https://github.com/ivanseidel/DueTimer).

Here is a 3-bit colors version of the British flag displayed with the Adafruit 16×32 RGB LED matrix and Arduino Due.

I notice though that the LED’s do not really shine so powerful as they should, and also altering the interrupt timer to display at 50 or 100Hz intervals really ruins the picture (also this I can not explain). So more work ahead… may God save the Queen!

Adafruit 16×32 LED matrix on Arduino Due

Beginning of January I saw a video demonstrating a clock which also plays Game of Life during displaying the clock. This so called Clock of Life uses the Adafruit 16×32 LED matrix and a Arduino Uno microcontroller board. I never came across this LED matrix before but it seems like a nice and popular display to tinkle around with, so off course it was only days later that I owned my own copy of it. As far as the clock goes, I’d very much like to achieve using it as a clock too, but the Game of Life option I’d like to skip, instead I want it to be wireless connected to the internet so that NTP servers can help me keeping the time more or less correct and thrust worthy over longer periods of time, maybe even years. With this wireless connection of course come a lot more possibilities, like setting a alarm clock to wake you up by using your smart phone, set background images and let the user configure the clock remotely. Well off course there is lots of more features I could add, but let’s not start to think to wide before we can even get it working.

For the wireless connection I opted for using the Adafruit C3300 Wifi adapter. After receiving both this unit and the 16×32 LED matrix I noticed that combining both on a Arduino Uno was going to be pretty hard on pin usage. Furthermore I was also not very sure how processor intensive everything combined was going to be, and keeping in mind I might want to add even more features I opted for a more speedier and advanced solution: the Arduino Due. It’s a 84MHz processor with a lot more in- and outputs. First thing I did back in January was making sure NTP server requests indeed do work using the C3300 on Arduino Due as a standalone solution. Next: make another standalone version where I test the LED matrix, but it was then that I noticed the Adafruit 16×32 LED matrix is currently not supported for Arduino Due. Nooo!

After some googling I found out the display does take quite some processing power to display full colors. Some of the code has been really optimized for using the Arduino Uno/MEGA internal functionality. So it was more or less at this time that I started to notice this project was going to take a lot more time since I’d be writing the display driver myself. The Adafruit tutorial tells you some of the details of how the boards works, and if you read it very carefully you’ll notice it’s not so very difficult to do some basic stuff like lighting some LED in either a red, green, blue or white color, or not light it at all. However, for mixing colors and dimming the display more advanced programming is needed. But first something about the display.

Without getting to much into the details on how the display works electrically here are the available pins we should take care of:

A, B, C => row address select pins
R1, B1, G1 => red, green, blue led on/off pin of a pixel of an upper row
R2, B2, G2 => red, green, blue led on/off pin of a pixel of an lower row
CLK => clock pin
OE => output enable pin
LAT => data latch pin

For the display to work you’ll have to send data at a constant rate as the display itself does not have any memory. This implies a lot of other stuff which I’ll get into more detail later. The A, B, C row address pins (3 pins = 3 bits) allow us to select 8 different addresses. For each address not one but two rows are being selected. So setting the bits for address 000 does not only select row 1, it also select another row being it the 9th. The 9th and not the second, because it allows to have less scan rate. For each row we have 32 pixels, so with 2 rows selected each time we set an address we now have 64 pixels available to manipulate (where each pixel has 3 LEDs, for red, green and blue color). Setting the pixel color however happens in a serial way, first one has to set a appropriate signal on the R, G, B pins, but because we have 2 rows selected at the same time we also have these R, G, B pins twofold. R1, B1, G1 for pixels in the upper region, and R2, G2, B2 for pixels in the lower region. Next the CLK (clock pin), LAT (data latch pin) and OE (enable pin) should be used to send the RGB LED’s On/Off state for each of the 32 pixels per line in a serial way.

While this might not seem to complicated to understand, there is more than meets the eye. For drawing in either red, green, blue or white colors it’s as sample as setting only the correct bits at the RGB pins, though when one wants to set a yellow or purple or any other color more complex methods will be needed because we have only 3 bits per drawing cycle to our disposal. We will have to fool our user by setting a pixel first red, than blue, than red again, than back to blue, … nnd this very quickly so that for the user the different colors mix up into something that might look like purple. So let’s say with 3 bits we can have 8 colors, 2 drawing cycles would make 2 times 2 bits resulting in 6 bit color (= 64 colors), and 3 cycles would result in 9 bit color which represents 512 colors.

But it gets more complicated. What if we want to dim our display? We not only need to mix for the correct color, we also need more drawing cycles for PWM dimming the display (if the goal is to implement it). So Let’s say we mix to get to the correct color in 3 drawing cycles, we’ll probable need another 2-3 drawing cycles where all LEDs per pixel or not illuminating to get to the a 50% duty cycle. This however is a layman implementation because not all colors are evenly bright. Red for example requires only one LED, while white requires all LEDs to be illuminating and thus the white color will always be a lot brighter the full red. For this and other technical difficulties I did not yet think of I still need more time to work it out, for now I can only show you some basic code where the Arduino Due is used to show 3 bit color on the Adafruit 16×32 LED matrix:

after hours coding

post-IT-study chronicles

Smart Clock