Saturday, January 31, 2015

My experience with Axiris IV-3 shield for Arduino

I recently bought on ebay the PCB for this open source VFD shield, designed and made by Axiris, a company in Belgium. I was attracted by the solid documentation provided on their site, which includes the schematics (even Eagle files), assembly instructions, demo software, files for laser-cutting the enclosure. I should also mention the professional photos, rivaling those of the top sites (e.g. adafruit, sparkfun).

Assembly went smoothly, as expected. I also expected it to work on the first try, like the other two VFD devices I built previously, the Ice Tube Clock and the akafugu VFD clock. I guess I ran out of luck :)
But, as my kid would say, "losing is learning". This became an opportunity for me to actually go one step further than just soldering the components mindlessly (because the instructions are too easy :)

This is how I learned what fascinating little devices VFDs are. They function similar to cathode ray tubes (CRT), used in the previous generation of TVs: the filament gets heated (by about 1V, believe it or not(*)) and frees electrons; a thin grid, supplied with higher voltage, attracts these electrons and speeds them towards the anodes, which are conductors that become fluorescent when hit by these electrons.
VFDs are also similar in functionality to triodes, and probably can even be used as amplifiers (in a MacGyver-kind situation :).

Compared to Numitron tubes or even Nixies, VFDs are more complicated to drive, since they require two voltages: a very low one (around 1V) for the filament (cathode) and a higher one (between 5V and 60V, depending on the model) for the fluorescent anodes and the grid.

IV-3 tubes used in the Axiris shield require about 30V for the anodes and 0.85V for the filament. The power source to generate these two voltages is original (when compared to those in other successful VFD devices). The documentation gives a great explanation on how it works.

In any case, it only "half-worked" for me: I got the high voltage around 32V, but the tubes were still dark.
There were 2 possible causes for this:
  • either defective tubes (with burned filament) or
  • missing low voltage
Not being able to find a "troubleshooting guide", I contacted Axiris. After a few emails, their advice was to check C2 and C3 and eventually play a bit with their values (between 5 and 15 nF). Which I did, with no success.

Needless to say that the design of this power source is out of my league. The filament voltage is high-frequency AC, impossible to measure with a regular multimeter (**). But a VFD's filament, like a light bulb's filament, works with DC as well. So I tried lighting them up with 3 AAA batteries in series (since the 4 filaments are connected in series). I was able to see them glowing (until that moment I didn't even know where the tube's filament was). That did the trick and proved that the VFDs were not defective.


As an alternate (working) solution, I chose to replace the low voltage AC from the oscillator's power supply (which did not work for me) with the PWM voltage from the available D11. I cut the trace to VFIL1 (see schematics below) and re-wired to the anode of diode D1. I took out C2 and C3 (right hand side in the photo above) and connected a wire between VFIL2 and Arduino's D11.


With analogWrite(D11, 200), the 4 in-series filaments are now powered with a measurable 3.2V (3.9V from D11 minus 0.7V voltage drop on diode D1). This is not an outrageous solution when you think of switching power sources driven by pulses from uC used in some Nixie clocks.

With the hack in place, I was then able to successfully run Axiris' demo sketch (shown in action in the photo).
As they say, "all is good when it ends well".

What I would change or improve in this kit:
  • add the ability to adjust the high voltage with a trim-pot; for two reasons:
    • eliminates the restriction to use only a 12V power adapter to generate the required 30V;
    • the tubes' luminescence diminishes over time (I read); a higher anode voltage can bring the brightness back;
  • power the filaments independently (in parallel);
    • if the filament of one tube burns out for some reason, all tubes will go dark; finding which one is defective is not obvious, and will require a multimeter;
  • replace the 8-pin "power" header with a 6-pin header, to be able to plug the shield in the original Arduino 2009 as well; the left-most 2 pins are not used, yet Arduino's capacitors are touching one of them;
  • add a troubleshooting section;
    • include measuring the resistance between VFIL1 and VFIL2 being about 32 ohms; that proves that the filaments are intact;
    • include testing of the filaments with a battery for the common folks that lack an oscilloscope (for those who have one, include some info on the AC voltage);

In conclusion, I find this kit as a great introduction to VFDs. I think it is easier to understand how it works than the Ice Tube clock, since it's all discrete components (no IC driver). It is also a lot more software-hackable, being controlled by an Arduino sketch. It is more hardware-hackable through the use of Arduino shields, which may include an RTC, Bluetooth, buzzer etc.


(*) One can also start a fire with a AA (1.5V) battery.
(**) Nick, I am just one step away from using the oscilloscope you sent me. I promise to write a review on it soon.


Saturday, January 24, 2015

Experimenting with Numitron filament tubes

A while ago I built a battery-powered single digit Numitron clock. There was nothing challenging about it. Each segment of a Numitron takes less than 20mA, like a LED, and requires between 3.5V and 4.5V to light up. So the segments can be driven directly from the processor or other TTLs (shift registers etc).

Since Numitrons behave so similar to (7-segments) LEDs, why not use one of my old LED matrix shields to multiplex 4 of them, I thought. And instead of the current limiting resistors, I would use a Schottky diodes, to bring them even closer functionally to LEDs. I would even be able to use the same interrupt-based code for multiplexing.

I started the practical experiment with just one Numitron. The 7 segments are driven by a 595 shift register and the common electrode gets grounded through a ULN2803 gate. The diodes insure the current flows in one direction only and they also guarantee a maximum voltage of 4.5V on each segment.

In practice, multiplexing does not work very well with filaments. The reason is, I think, the "switch" time, the interval between the moment the voltage is applied to the filament and the moment the filament becomes incandescent and glowing. Unlike LEDs, which are diodes and "switch" quite fast (microseconds), filaments (which are essentially resistors), are orders of magnitude slower to emit light.

The sequence of 3 photos below shows one Numitron multiplexed at a 4:1 ratio, 2:1 and 1:1 respectively.
The 4:1 ratio is too dark; 2:1 is acceptable and 1:1 is optimal.


Here is the sketch I used for the experiment. I changed the number of multiplexed tubes (in the ISR), between 1, 2 and 4.


byte digitDefinition[10] = {B11110110, B11000000, B10101110, B11101010, B11011000, B01111010, B01111110, B11100000, B11111110, B11111001};

// pins used for LED matrix rows (multiplexed);
#define SHIFT_CLOCK_PIN   4
#define STORE_CLOCK_PIN   5
#define SER_DATA_PIN      6

// pins assigned to tubes' common electrodes (in theory board can drive max 8 Numitrons);
byte pinTube[8] = {8, 9, 10, 11, 12, 13, 7, 3};

byte activeTube = 0;

void setup()
{
  // Calculation for timer 2
  // 16 MHz / 8 = 2 MHz (prescaler 8)
  // 2 MHz / 256 = 7812 Hz
  // soft_prescaler = 15 ==> 520.8 updates per second
  // 520.8 / 8 rows ==> 65.1 Hz for the complete display
  TCCR2A = 0;           // normal operation
  TCCR2B = (1<<CS21);
  TIMSK2 = (1<<TOIE2);  // enable overflow interrupt

   // outputs for ULN2803;
  for (int i=0; i<8; i++)
    pinMode(pinTube[i], OUTPUT);

  // outputs for serial shift registers;
  pinMode(SHIFT_CLOCK_PIN, OUTPUT);
  pinMode(STORE_CLOCK_PIN, OUTPUT);
  pinMode(SER_DATA_PIN,    OUTPUT);
}

/**
 * ISR TIMER2_OVF_vect; gets called 7812 times/second.
 */
ISR(TIMER2_OVF_vect)
{
    // turn off current tube;
    digitalWrite(pinTube[activeTube], LOW);

    // change the number of multiplexed tubes here;
    activeTube = (activeTube + 1) % 4;

    // activate the next tube;
    digitalWrite(pinTube[activeTube], HIGH);
}

void shiftOutRow(byte digitDefinition)
{
  digitalWrite(STORE_CLOCK_PIN, LOW);
  shiftOut(SER_DATA_PIN, SHIFT_CLOCK_PIN, LSBFIRST, digitDefinition);
  digitalWrite(STORE_CLOCK_PIN, HIGH);
}

byte getDigit(byte activeTube)
{
  return activeTube;
}

void loop()
{
  shiftOutRow(digitDefinition[getDigit(activeTube)]);
  activateNextTube();
}


In conclusion, I could build a 4-digit clock using the LED matrix shield (which has two 595 shift registers) with 2:1 multiplexing, or better, I could use the dual LED matrix shield (featuring four 595s) without multiplexing.

I'll report back when I'm done soldering.


PS Most of the Numitron schematics out there do not use multiplexing (thus confirming my finding). The few that do (like this one), use a higher voltage (>4.5V) to make them brighter. This solution may have an impact on the life of the tubes though. In addition, if for some reason (program bug, processor failure etc) the multiplexing stops working, the Numitrons will be toast, quite literally.

Sunday, January 11, 2015

Horizontal mod for the HDSP clock

Making a proper enclosure for the HDSP clock is challenging, since it was designed specifically to stand on a phone charging dock. Inspired by DaveC's lay-flat version (he didn't send photos of the inside though), I put some thinking into how to easily convert the "stand up", vertical clock, to an "encasable" horizontal one. The main requirement is to place the display perpendicular to the board. This could be done using a right-angle header of some sort, as shown in the photo below.


With this easiest solution, as you see in the next photo, the board must be upside down for the display to show properly.


With a bit of more work, basically re-wiring the connections to the display on the adapter PCB (that holds the display), the whole device looks more appropriate, as shown in the next photo.


Which brings me to the subject of "display adapters". Although the HDSP clock was designed specifically for HDSP-2534, it can be easily converted to use similar "smart displays" but with a different pin configuration, as is HDSP-2133. (I got this particular one as a gift from MarkB. Thanks once again!)

So, to recap, if you have one of these 8-character parallel-interface HDSP smart displays, you can use it with the HDSP clock through pluggable display-adapters (shown in the photo below). Note that the code works without modifications.


Now back to enclosure. The HDSP clock board seems to fit perfectly (according the the datasheet) inside a Serpac A20 box. Even the screw holes in the box match empty spaces on the PCB, so holes for the mounting screws can be drilled properly.
How about the buttons?
  • long-stem buttons could be accessed through holes in the upper side of the box (ugly though);
  • the buttons can be mounted on the back panel of the box, connected with wires to the board;
  • a Bluetooth module can be added, thus eliminating the need for buttons altogether (requires code changes);
  • add remote control.
I plan to update this post, with photos, after I try what I "preached" above.

Thursday, December 25, 2014

XBee-fy the ESP8266 WiFi module

With the new ESP8266 module, adding WiFi to any Arduino project became a lot cheaper.
This module has a serial interface; therefore it only requires connecting 4 pins: Tx, Rx, 3V3 and Ground, as shown in this image from seeedstudio.


A few peculiar facts about ESP8266:
  • default serial baud rate is 57600; since this rate is too high for SoftwareSerial library, a hardware port should be used;
  • requires 3V3 for power and level shifting for Rx signal (5V to 3V3);
  • physical interface is a 2x4 pin male header;
  • firmware can be upgraded to a version that allows 9600 baud rate;
  • can be used either as client or server.
The first two characteristics makes it a perfect candidate for a module with an XBee footprint, as is WiFly, for example.

It took me about half an hour to do it, following these steps.
  1. cut a piece of 2-mm perfboard to the XBee dimensions;
  2. solder two 10-pin the 2-mm-spaced male headers on the sides;
  3. desolder (using wick) the 2x4 header;
  4. mechanically attach the header-less ESP8266 module to the XBee perfbord, by soldering 4 pins into the corner holes, aligned with holes in the perfboard;
  5. wire the pins 1, 2, 3 and 10 of the Xbee-type module to pins Vcc, Tx, Rx and Gnd of the ESP8266 module respectively.

And now a few photos. Start with these (XBee shown for comparison purpose):


to make this:



Then plug it any Xbee socket, like one on Wise Clock 4:


or Adafruit XBee adapter:


Hopefully now more people can try adding new WiFi features to their Wise Clocks without breaking the bank (paying $35 for WiFly).

Sunday, December 14, 2014

M4 receiver backpack for reliable wireless remote control

My investigation into the failure of the M4 receiver remote controlling my Wise Clock 4 concluded with the need to add a step-up converter. The Sure 1632 display makes the input voltage drop sometimes below the absolute minimum of 4.5V required for the M4 module to work properly. It's not the noise (spikes) in the 5V power, nor the interference on 315MHz.

I designed a simple "M4 receiver backpack" that uses a DC-DC step-up converter to ensure a 5V power for the M4 receiver module. The board supports 2 different kinds of converters, one from ebay (red in the photo below), the other from tindie (made by BBtech, black in the photo).


The backpack can be used, by default, without the step-up converter if the voltage is steady at around 5V. (A trace-jumper must be cut when a converter is added.)

The wireless remote pair of 4-key fob transmitter and receiver module is sold by Adafruit or vendors on ebay.

The assembled board wired to Wise Clock 4 is shown in the photos below. Note that only 3 out of 4 buttons on the remote have a function on the clock. Each button press could light up a (optional) LED on the receiver board for visual confirmation.


A new design of the Wise Clock 4 board should probably feature a header for plugging in the receiver module, otherwise the back of the board will show a bunch of ugly wires.


This M4 receiver backpack could be used for adding remote control to other devices with buttons, especially when these buttons are hard to access (due to enclosure design constraints), or hidden (for aesthetic purpose). One example that comes to mind is an oscilloscope clock fully enclosed in transparent acrylic; drilling holes for the buttons would require some design stretches.

Schematic and board layout are shown below.



The M4 receiver backpack would be also suitable for hacking old commercial alarm clocks. Please let me know if anyone is interested :)