Wyolum 3rd annual Innovation Grant - 2013

Are you working on a cool project? Do you want to make $2,000? Share it with the world by open sourcing it and you may win the Wyolum Innovation Grant! Now in its 3rd year!

This is the place to submit your project, find out the rules and deadline, and generally learn more about this generous team of innovators!

Eulogy for my Chumby

My beloved Chumby One died today. I first thought to be a software glitch, since the booting seemed to take a long time, then it seemed to re-boot itself after a little while. After a few cold resets, the screen started to literally flash, like the flash of a camera, once every 2 or 3 seconds. Not a good sign. I opened it up, for the first time. Beautiful on the inside too. Regretfully, it does not look like something I could repair.

My Chumby served me faithfully and inspired me (I am not kidding) for the last 4 years or so, mainly as a desk clock . It had all the features I wanted in such a device: fairly sized touch screen, good WiFi, great speaker (bass reflex nonetheless), reasonable radio, rotary encoder for volume (or menu scrolling), backup battery, USB socket, internal SD card for the operating system. In the beginning, the OS allowed for various apps to be downloaded and installed (support was cut after the company went bankrupt). The app-installation process was seamless, comparable with today's Google Play, just earlier. The alarm clock app I used was perfect, with snooze, night dimming, always displaying accurate time (acquired from ntp time server). Other apps I installed showed photos from flickr, displayed RSS streams, played mp3s from USB stick; there was even a piano app that used the touch screen capabilities. Chumby was really a much cheaper alternative to a tablet, with a similarly great potential. Compared to a smart phone, Chumby's only missing feature was the GSM/GPRS, which I bet was considered to be added (since it has a microphone too). I also liked its stable shape, simple design and ease of use (great way to re-connect to the WiFi network too).

I never understood why it did not have a greater success.

My first impression on Cogwheel Nixie clock

Many months ago I bought, attracted by the clearance price, the PCB for the "Nixie Driver Board Rev A" from "Cogwheel circuit works" store. I was hoping that, with all documentation in place, I would be able to build it on my own, considering it's controlled by an ATmega328 and the software was available, though not the source code.

First thing to note is that the board uses mostly SMDs. If anything went wrong (and there was a high chance, since the PCB was already described as a "mistake the board house made"), the board would become a coaster.

The schematic includes some exotic components, like the HV513 Nixie driver, not offered by digikey. Others are the DS1302 RTC and the optional DS32KHZ oscillator for RTC, which I heard of for the first time. But thanks to the detailed BOM, gathering the components was relatively (some of them are already discontinued, for example) easy.

High voltage for the Nixie tubes is generated by a hardware PWM under software control. So, like the Ice Tube Clock, in order to measure the high voltage and make sure the HV circuitry works, some software must be uploaded onto the processor. I expected the released software to do that. Unfortunately, the highest voltage I saw was under 9V.

After some digging (and learning in the process), I ended up with this simple sketch, adapted from Satashnik Nixie clock, which generates a stable 190V. I know, I was surprised too :)

#include "Arduino.h"

#define DDRHVPUMP  DDRB
#define BV2(a,b) (_BV(a)|_BV(b))
#define BV6(a,b,c,d,e,f) (_BV(a)|_BV(b)|_BV(c)|_BV(d)|_BV(e)|_BV(f))
#define VOLTAGE_WASTE   370                     //!< ~180V
#define VOLTAGE_SAVE    355                     //!< ~170V

volatile uint16_t voltage; 
static volatile uint16_t voltage_setpoint = VOLTAGE_WASTE;
static const uint16_t ocr1a_reload = 60;

void pump_init()
{
    // set fast pwm mode
    // COM1A1:0 = 10, clear oc1a on compare match, set at top
    // COM1B1:0 = 00, normal port operation
    // no FOC
    // WGM11:10 (WGM = Fast PWM, TOP=ICR1: 1110) = 11
    TCCR1A = BV2(COM1A1, WGM11);
    TCCR1B = BV2(WGM13,  WGM12);
    OCR1A = ocr1a_reload; 
    ICR1 = 170;
    TCCR1B |= _BV(CS10); // clk/1 (16MHz)
    DDRHVPUMP |= BV2(1,2);
}

void adc_init()
{
    voltage = 0;
    // PORTA.6 is the feedback input, AREF = AREF pin
    ADMUX = 6;  
    // ADC enable, autotrigger, interrupt enable, prescaler = 111 (divide by 32)
    ADCSRA = BV6(ADEN, ADATE, ADIE, ADPS2, ADPS1, ADPS0); 
    ADCSRA |= _BV(ADSC); 
}

/// Start voltage booster
void voltage_start()
{
    adc_init();
    pump_init();
}

ISR(ADC_vect)
{
    voltage = (voltage + ADC) / 2;
    if (voltage < voltage_setpoint) {
        OCR1A = ocr1a_reload;
    } else {
        OCR1A = 0;
    }
}

void setup()
{
    sei();
    voltage_start();        // start HV generation    
}

void loop()
{
  // clock functionality in here;
}

The next big step is to write the software to drive the tubes and actually show the time, which is essentially re-writing the Cogwheel Nixie clock code (or at least the basic functionality) from scratch. Then open source it. Any help would be appreciated :)

Black Friday (and beyond) sale

I was going to have a Black Friday sale anyway, but now I have one more reason for it, and it's an embarrassing one: the latest batch of PCBs have a little flaw, but they can be easily fixed. So, until I run out of them, both the Wise Clock 4 kit and the Complete Wise Clock 4 kit will be $10 less, for $57 and $115 respectively. (As always, I also offer discounts for multiple units, just ask.)

The photos below show a few ways to fix it. Basically, the GND terminal of the USB connector is disconnected from the board's ground. The short wire re-connects them again.

The sleekest way would be on the bottom, using a resistor terminal inserted together with the 2x8-pin female header, as shown in the photo below.

Solder the other end together with the 6-pin FTDI connector.

Here is the story of how this happened. The PCB used to be 101.2 mm in length. That was 1.2 mm longer than the 10 cm limit imposed when using Seeedstudio's PCB prototyping service. I never had a problem before, I always got them manufactured like they were 10 cm in length. Now, Seeedstudio decided to enforce the 10 cm limit (or pay up like they were in the next size bracket). I reacted by shrinking the board, cutting 1.2 mm from the right side. It seems that the 1.2 mm side was very important.

There is more, unfortunately: in the process of generating the Gerber files, I even forgot to select the "Top names" for the silkscreen, so now the resistors are not named at all.

When you install the resistors, keep in mind that 3 of them, with values of 4k7, must be positioned in the correct places, as shown in the assembling instructions. (The other resistors are all 10k, soldered stress-free in the remaining resistor places.)

And that's why the board is now essentially free with the kit. If you don't feel confident that you can do it, please ask me to fix it for you. I will solder the little bridge wire and also solder the three 4k7 resistors correctly. You do the rest.

Note: The photo shows the board bare, but the PCB in the kit comes with the SMD components (SD card socket, the DS3231 and the 3V3 regulator) soldered already.

And here is the (latest) schematic, for those interested in details.

The ugliest project I've built so far

Based on this photo from BroHogan's gallery of Geiger counters, it was supposed to be a simple encasing using Adafruit's Arduino enclosure. Everything looked neat and clean inside, even with room to spare.
I wanted to use LiPo instead of AAA batteries, to avoid opening and closing the device every so often. This required the use of a LiPo charger, for which I picked the one I already had, the seeedstudio's LiPo Rider.

I spent countless hours trying to put this puzzle together:

• only 4 places for screws;
• small(ish) charger board must to be solidly anchored to the case (since an USB cable will be plugged in frequently), yet it does not have any hole for screws;
• 6 wires (battery, V out, switch) must be soldered to the charger SMD board;
• 12 wires need to connect the Geiger board to the LCD, on the other half of the case;
• trim pot suspended somewhere (since there is no room for it on the PCB);
• power switch to fit in the rectangular opening of the bottom ;

When I thought I figured it out, the two halves of the case wouldn't close because things inside were too tall/thick. Back to the "drawing board". Took out the ATmega328 from the Geiger board (it was touching the LCD connectors, which were already minimized for space), and replaced it with a cheap ($4) "Arduino Nano" (or is it "Mini") from ebay. This also helped immensely with the wiring: instead of connecting 12 wires between the case halves (Atmega328 to LCD), I had to solder only 3 (Vcc, Gnd, Int).

After a few more kludges (e.g. re-positioned the inductor on its side, removed the (over)power(ing) LED on Arduino Nano), I ended up with something , as the saying goes, "only a mother can love".

The lesson I learned from this experience is that, if one wants a seamless, solid, beautiful, project, one needs to either design the board for an enclosure, or the enclosure for a board. Trying to mix and match the board with the enclosure leads, at best, to something ugly.

Did I mention that I worked on it on and off for about 3 months?

The red light in the bottom left corner is the "charging" LED. (And then there is the somehow annoying LCD's backlight, visible through the translucent enclosure.)

The power switch is advertised as being the smallest rocker power switch out there. I only had to file off about 1mm on the upper side of the original rectangular opening to make it fit.

Another lesson I learned: use a transparent enclosure only when the inside looks perfect and you want to show it, and by "perfect" I mean even no visible wires.

Stay tuned for the next version of this Geiger device. (You did not think I would stop here, did you ? :)

Nixie tube clock miscellany

Honestly, one of the reasons behind my latest infatuation with Nixie tube clocks is trying to understand why so many people got so fascinated so quickly and so suddenly with them, although they are not cheap, and although they simply show the time with 4, sometimes 6, digits.

In any case, I'm in the bandwagon now. I designed an Arduinix(TM) variant, based on my previous observations. One of the main differences is that the components sit low on the board, so that a "tube shield" can be plugged on top, similar to akafugu's VFD modular clock. The top "tube shield" can host (at least in theory) up to six IN-2 or four IN-17 (four IN-12 would not fit).

For the "IN-2 tube shield", I downloaded and used the eagle library called "russian-nixies.lbr". Guess what? For the digits to be shown vertically, the IN-2 part needs to be rotated about 45 degrees clockwise. I did not know that until I got my IN-2 tubes. Essentially, the IN-2 tube shield I have is kind-of useless now, unless one uses it for an "artist project" (to quote Pete of PV Electronics, seller of Nixie kits on ebay). That means that the tubes are connected to the PCB with wires, so that they can be placed at artist's fancy. I know Nick is an artist :)

Lesson learned: don't design the PCB until you have all parts in hand.

PS Getting the high voltage (180V) on the new board was just a matter of adjusting the trim pot. No surprises this time.

PS2 Although I did not try it yet, the "Open source Nixie tube shield" sketch should work, with minor modifications, with Arduinix, I reckon.

PS3 Please contact me if you have a need for this PCB or want to buy one.

Alarm clock app for iPhone

My young friend Rami left his comfortable and safe permanent job with a solid consulting company to start his own business, mainly writing apps for mobile devices. His first app is "Deep Sleep Alarm" for iPhone, available for download in the App Store.

The app is free, with nice graphics and useful functionality, basically making sure you are not "cheating" when  waking up :)  Please give it a try.

He is currently working on the Android version.
Rami, keep up the great work!

Another Nixie clock

For "unknown" reasons, these days things don't move as fast as they used to. I have a dozen or so unfinished projects on my desk, most of them waiting for parts to arrive. And usually and unfortunately, when I get the long awaited part, something else is missing... or not fitting,... or not working.
Today I was finally able to finish the "Open Source Nixie Tube Shield", for which I pledged $15 on kickstarter in return for the PCB.
Without paying attention to the schematic (was it even published before the campaign ended?), I thought it was just another variation of the same Nixie theme, which it really was. I expected to have all parts on hand already, including the Nixie K155ID1 driver Russian IC. Surprise! Instead, the circuit uses CD4028 decoder plus HV transistors. And that's where the 4 week wait is coming from.

I liked the compactness of the board even before I soldered the almost 100 components. But I was a bit disappointed when I realized the shield had a (minor) flaw: the area above Arduino's USB A connector is as highly populated as the rest, if not more. Not only the metal encasing of the USB connector will short the high voltage components on the shield above, but the shield cannot be even pushed all the way in.
A workaround (which I ended up using) is to have an intermediary shield between Arduino and the Nixie tube shield. Another solution is to use an Arduino variant with the mini B USB, like Seeeduino or Leonardo.

But all's well that ends well. To cut the story short, the sample sketch provided worked just fine without interventions. Hardware-wise, I added a DS1307 RTC (since I was going to build a clock), a buzzer (for alarm and chime) and a Bluetooth module (to set up the time without buttons). The only kludge required was a change in the core file Tone.cpp, where I replaced Timer2 with Timer1.

Below are a few photos. For enclosure, I (again) went for the the poor-man's solution, this time hand-cut (as opposed to laser-cut) transparent acrylic plates. (The long standoffs are 60mm, in case one wants to reproduce the experiment.)

I was happy to "upcycle" my Arduino Duemilanove, with the nice bottom exposed and visible :)

The prototype shield was something that I thought I will never use again, but it came in handy.

I also borrowed an idea from akafugu, with the bigger front plate creating a nice slope.

One thing I skipped (because I don't like the combination) is the blue (or any other color, for that matter) LEDs under the tubes.

A working version of the code is available here. It is based on Tyler's code (timer-based multiplexing of the digits, anti-cathode poisoning etc), with added support for RTC (DS1307) and functionality for setting up the time, alarm time, enabling/disabling alarm etc through Bluetooth (using an Android phone or tablet, for example).
The clock can execute the following commands, sent from BlueTerm (after pairing with the device):

• TIME=hh:mm - sets the current time (second is set to 0);
• ALARM TIME=hh:mm - sets the alarm time; the alarm hour and minute are also saved to eeprom (and retrieved from there whenever the clock is powered back on);
• SHOW ALARM - sends back to BlueTerm the alarm hour and minute
• ALARM ON - enables the alarm; this is also saved to eeprom; the Alarm On/Off status can be shown with a LED connected to A0;
• ALARM OFF - disables the alarm;
• STOP ALARM - turn off the sound after the alarm starts beeping;

Note that all commands must be upper case.

The "Stop alarm" feature is reminiscent of Rami's "Deep Sleep iPhone app" and also of Ramos alarm clock (coincidentally, another Nixie clock, close source though), where both of them are asking for user interaction to stop the sounding alarm. Well, in order to stop this Nixie clock from beeping, one needs to open BlueTerm, pair the devices, then type in "STOP ALARM", a sequence of actions that requires anyone to be pretty much awake.

My experience with the Arduinix Nixie tube shield

This was not an easy project to finish. Anything that could go wrong, it did, due to a rare combination of ambiguous hardware kit design (that's what started it all), and bad luck (software bugs in Arduino IDE 1.0 nevertheless). In the end, I learned a few things, which made me a better person :) :) :)

Please don't take this as a rant, nor as a (negative) review. As usual, the main purpose of the post is to document the experience and eventually help others troubleshoot similar problems they may have with the Arduinix shield kit.

The first issue I had was not getting the high voltage (180V) required by the Nixie tubes. For some reason, the provided schematic and assembly instructions are ambiguous on the exact value of the C3. This made me look at other HV power supplies, with the conclusions captured in this post. Anyone taking a closer look at the Arduinix HV schematic will notice at least 3 differences compared to others using the same 555-based design:

- the very important capacitor C3 has unusually small value (only 47pF, compared to 2.2nF, a much better value, according to the calculations);
- pins 6 and 7 are connected;
- transistor Q5 is shown as PNP (though correctly marked as MPSA42, an NPN transistor).

The assembly instructions, showing 2.2nF for C3, say that the value of this capacitor varies "the most", "as we make slight modifications and improvements to the kit". What improvements in a standard, proven and tested schematic?

What else was there for me to try? Most of the components around the oscillator, of course: the inductance, the resistors, the capacitors. The highest voltage I got was about 80V. So I decided to revert to "the standard". I cut (top side) and re-routed (bottom side, see photo) the PCB traces around pin 6, 7 and R14/16, I replaced C3 with a 2.2nF, and, unsurprisingly, I got the long desired 180V.

Next step was the software. After I uploaded the sample sketch using Arduino 1.0, only 2 digits were lit.
Three hours and a lot of effort and frustration later (even wondering how everybody else got this sketch working), I realized that Arduino 1.0 itself was the problem. Even the simplest test sketch, tried on multiple Arduinos, failed, incredibly, to work!!! (And you can try it and confirm this too.) Here it is:

void setup() 
{
  Serial.begin(9600);
  Serial.println("in setup");
}

void loop()     
{
  Serial.println("in loop");
  delay(1000);
}

Switching to Arduino 1.0.4 solved it. My Arduinix shield is now functional. Making it into a clock is going to take a few more steps though, including hardware (adding RTC, probably by resurrecting Wiseduino+), writing the software (with functionality to set up the time from buttons), and of course, the most challenging of them all, making a proper enclosure.

A few more observations:

- the INS-1 neon lamps are too tall to be used as dots between the IN-17 Nixie tubes;

- it seemed that the little Nixie PCB could be placed at the same level as the Arduino board (and under the shield, as opposed to on top, as it is currently, see the photo above); it has holes that align with those in the original Arduino 2009, but the ICSP connector is in the way though;

- all photos on arduinix gallery show the Nixie board attached to the shield by ribbon cables; I wondered a bit if my solution, using regular headers, was proper;

- this is the cheapest open source Nixie-kit out there.

High voltage power sources for tubes (Nixie, VFD, Geiger)

Updated June 2, 2017 - added VFD power supply with automatic dimming (#4 in the list below), contributed by Ken

This is a superficial review of the few schematics I encountered while building Nixie clocks, VFD clocks and Geiger counters (no tube amplifier just yet). Although the schematics seemed basic at a glance, they usually ended up being a challenge (that is, they rarely worked right away) for me. That's another reason I am trying to cover them here, so I can use this post as consolidated reference any time I need it.

Tubes require high voltage to work. Some (Vacuum Fluorescent Display) need 40V, others (Nixie) 180-200V, and some others (Geiger) even higher, 400-1000V. The high voltages are generated these days by switching-mode power supplies. Essentially, there is only a handful of popular solutions, and each DIY tube kit picks one of these, based on size, power requirements, cost.

In principle, a switching mode power supply, also known as "boost converter", uses a square wave oscillator ("switch") to create magnetic energy in an inductor, then releasing it as high voltage.
Some scientific explanation (with formulas) can be found here, some practical advice (with schematics and photos) here. Adafruit has a very useful online boost calculator.

1. One of the most popular solution for the square wave oscillator is by using the ubiquitous 555. This is inexpensive, but requires some tweaking and adjusting (values of resistors and capacitors). The schematic is standard, but there seem to be a few variations.
The one below is from Ronald Dekker.

Frank clock (from Pete's Nixie kits) uses an almost identical schematic, but a different set of values for R2-R3- C4 (used for setting the frequency). In the end, the oscillator frequency is about the same at approx 30kHz, calculated with formula  f = 1/0.693/C4/(R3+2R2)  (in the schematic below).

Same 555 is used in Arduinix, but in a different configuration, although still as astable oscillator. This one has an extra HV capacitor (C4) in series with a resistor (R15), whose exact purpose I don't understand. The oscillation frequency is also weird, according to the above formula, with C3 at 47pF, should be 1.5kHz. No wonder this did not work for me.

Another almost identical HV power supply for Nixie tubes is used in the recently-kickstarted "Nixie tube shield" (for which I pledged $15 for the PCB, and yet to receive it).

And finally, 555 is also used to generate the higher voltages required by Geiger tubes, as used by BroHogan (and MightyOhm). The frequency of oscillation is 4.5kHz (f = 1/R1/C2). (I built several Geiger kits from BroHogan and they were all trouble-free.)

2. Other solutions use specialized chips like MAX1771 and MC34063.
Shown below is the high-efficiency boost converter from Nick de Smith (sold by ogiLumen), based on MAX1771.

Akafugu's VFD Version 1 clock uses the same MAX1771, to generate a lower 50V (for VFD tubes) MC34063 to generate 38V for the tubes (thanks Ken for the  correction - see his comment at the end of the post).

For MK2, Akafugu uses the same MC34063 chip (schematic not published yet).
The same chip is also used in their Nixie clock (schematic shown below), to generate 180V. This HV circuit has its own (all SMD) board, which I assembled it myself and worked without a glitch.

3. Yet others use a PWM pin of a microcontroller. This method requires the processor to be connected and programmed in order to generate the high voltage. The solution is cheap (saves an extra chip), smaller in size (again, one less chip), and also seems to be highly efficient.

Below is the HV schematic used by Adafruit's IceTube clock.

Some of the microcontroller-based boost converters have feedback (close loop, with PWM adjusting to the voltage output, if I am not mistaken), as are those from Cogwheel and Satashnik (shown below, respectively).

As with any analog electronics circuit, troubleshooting a HV supply is not easy. A suitable tool would be an oscilloscope, allowing for the measurement and adjustment of the frequency and pulse width. Once these are cleared, the high voltage could be adjusted usually from the trim pot. To modify the voltage range, try different values for the inductor.

4. A very useful addition is Ken's VFD power supply with automatic dimming, schematic shown below. Detailed info can be found here.

Play Tetris on Wise Clock 4

No kidding.
I was looking for a suitable application to demo with Wise Clock 4 placed vertically (that is, standing on its shortest side), when I found this hackaday post about Tetris on a LED matrix. The code, already written for Arduino, clean and easy to understand (kudos to Jianan), was a breeze to port. I only had to change a few functions (display, user buttons), comment out a few more (sound, text etc) and downsize from 7 colors to just 3.
Commands come from Bluetooth terminal ("BlueTerm" app on Android), basically replacing the buttons with letters (U, R, L, D; you got the idea).

The Wise Clock 4 vertical stand is possible thanks to the enclosure-mounted power jack, wired to the display's screw terminals, as shown in the photo below (that also captures a part of my messy desk).

(This is a typical example of how one thing leads to another. I don't usually play games, but when I do, I use my implementations. "Time well wasted", as the saying goes.)

New release of Wise Clock 4 software

Some of the latest software features have already been introduced (see this post). Since then, a few bugs have been fixed (again, thanks Mike!), the code was streamlined even more, and some apps (Countdown, Score, Stopwatch, Quote) have been expanded and improved.

Below is a list of the most recent code changes:

• added PWRON setup option to select app to run when the clock starts up;

• compilations options (add/remove features) moved to file "UserConf.h". That is:

- Instead of editing WiseClock.cpp to select applications to build, edit "UserConf.h".
- Instead of editing WiseClockVer.h to select WiseClock 3 or 4, edit "UserConf.h".
- Instead of editing HT1632.h to select the number of displays, edit "UserConf.h".

• on dual display, Countdown includes days as well, in the format DD:HH:MM:SS;

• Countdown shows the correct amount of time left even if power was down for a while (this is done by saving the end time in eeprom); for this feature, the PWRON must be set to "CNTDWN";

• similar to Countdown, app Score has been extended to "remember" the numbers even after the power was out for a while; in either case, the respective app must be selected in PWRON;

• ability to display quotes randomly, if the user selects "RND" in app Quote;

• on dual display, Stopwatch is now using regular-size font (still using tiny font on single display);

• Stopwatch has a new mode, "Conventional", in addition to the previous one (called "Rattrapante"); the conventional mode accumulates the time passed between consecutive presses of the start/stop button, as a mechanical chronometer would do; "rattrapante" mode shows the amount of time passed from the moment it was first started, regardless of how many times the chronometer was stopped;

• on dual display, with "Font+" selected, Score and Stopwatch are using big font and no longer show the current time on the bottom line (they show as before with "Font-" selected); 

One of the challenges in writing complex code for embedded systems is the compromise between following an Object Oriented approach and trying to minimize the amount of RAM at runtime. Let me elaborate a bit. Each C++ object, once created (at runtime), used or not, takes some RAM, storing data members and the vtable (when using virtual functions). Wise Clock software is trying to follow an OO design. Each App class is derived from an abstract base class. The base class defines 2 pure virtual functions (init and run), which must be implemented by every App class.

At runtime, each app is created as a static object. Therefore, if 12 apps are declared (through the use of ifdefs in UserConf.h), 12 objects will be created in RAM, each one storing its own data and its own vtable. That's a pretty big price to pay in the world of embedded systems with little RAM space (just a guess, based on my very limited experience).

A non OO approach would create and use variables only for the app that is in current use, as the code is being executed. Although this solution would use less RAM, the current complexity would make the code unmanageable.

So back to the compromise, how does one solve it? (This is not a rhetorical question.)

Mechanical Design and Engineering

I was having a conversation with my friend JohnW, a Mechanical Engineer by education and trade, about his latest "small" project. I suggested he should publish and document aspects of his interesting work. But he mentioned he does not have a blog just yet, so I "volunteered" to do it for him right here, as a quick (and hopefully useful) example.

John designed a portable agitator, a device used for mixing low-viscosity liquids or liquids with small-size solids.
Mixing is performed by a propeller driven by an internal pneumatic system, and not using an electrical motor, as shown in the diagram below.

The whole contraption is made of plastic, calculated for a maximum internal pressure of 80 psi.
The liquids are poured in manually, through PRV-07 (features a screw-in lid). The mixed liquid is released through the pinch-valve PRV-06. The lid PRV-01 can be removed (8 screws) for inside cleaning.

The mixing capacity is 1 gallon, but it can be easily scaled, in both dimensions and power.

This agitator was designed to be safely used in the food, pharmaceutical, chemical industries.

Here is a photo of the agitator built to specs.

If anyone is interested in this kind of engineering work, I will be glad to re-direct them to him. John is versatile, works on tight budgets and schedules, and very proficient in Autocad, Inventor etc.

More open source VFD clocks

I just finished assembling the latest version of akafugu VFD clock, the "MK2". Per, from akafugu, generously sent me the board for testing/review. It comes will all SMD components pre-soldered, and the processor pre-programmed. The rest of the components, all through-hole, I sourced on my own.
Here is a photo of the kit as I put it together (I forgot to include the through-hole resistors though).

Assembling was straightforward thanks to the combination of good board design and easy-to-follow instructions. The result is shown in the photo below.

MK2 has some improvements over version 1:
- newer processor (Atmega32U4, as the one used in Leonardo);
- 5V power source (vs 9V previously);
- direct sketch upload from Arduino IDE (no hacking required);
- integrated support (on-board 24LC256 eeprom) for four-letter-word feature;
- all SMD parts (quite a few actually) come pre-soldered;
- directly compatible with the existing (version 1) VFD display shields;
- better clearance with the VFD display shield (because parts are shorter in height).

In conclusion, MK2 is another winner for akafugu.


I also recently assembled the Ice Tube clock from adafruit. I bought the PCB(s) a while ago (when they were still available for sale on adafruit site) and I sourced the parts on my own. I followed the legendary assembly instructions, but things did not go without a glitch for me. Here is what I learned in the process:

• The Ice Tube clock is not Arduino-compatible as I initially thought (see here). It cannot be programmed from the Arduino IDE and it does not have an FTDI interface/connector. The processor (I used Atmega328, but ATmega168 should work with the base software too) uses the internal 8MHz oscillator and an external 32kHz crystal. This crystal, in conjunction with TIMER2 (see file iv.c), is the heart of the clock "mechanism". (More details on the design can be found here.)

• The high voltage for the tube is produced with impulses generated from an output pin of the processor (instead of using an external chip, like may other designs). Therefore, high voltage is not there until the chip is correctly programmed.

• Programming the chip was a bit of a challenge; I used the makefile to build the hex file from the source, but programmed the chip with avrdude directly, as shown in this screenshot (click for bigger picture).

• IV-18 tubes bought on ebay, even when they are new (with the wire terminals intact) can be defective. Out of the 5 tubes I got, 4 had a blackened spot on the back and one had a white spot, as shown in the photo below. Guess which one did not work.

• Inserting all 24 wire terminals of the IV-18 tube in their holes is a challenge. I would much rather prefer the solution adopted by akafugu in their VFD clock, with half terminal holes, opening in a big empty circle (as shown below, photo from akafugu).

• IC sockets, particularly PLCC28, although bought from digikey, can be "defective". Unlike the DIP IC sockets which press each IC pin on two sides, the PLCC28 sockets actually press against the IC pins on one (external) side only. It took me many minutes to figure out that the tube was not lighting up because one socket pin was loose and did not make contact with the IC's pin.

• MAX6921 VFD driver used in the Ice Tube clock is more than twice as expensive as HV5812 VFD driver used in MK2. Yet, adafruit's Ice Tube Clock is still the cheapest complete (including enclosure) VFD clock kit out there.

Overall, building the Ice Tube clock was a pleasant and rewarding experience, which I recommend to kit-builders at any level. This clock looks compact, sleek, stylish, and stands out in my clock collection.

"Close enough" Wise Clock display mode

Inspired by this article, MikeM added the "Close enough" mode to the functionality of Wise Clock 4.
This new "face" is accessed by pressing the "Set" (middle) button inside the application "BIG".
The time is shown as an approximation, with the hours as an explicit number, the minutes filling the circle of  a 60-minutes clock and the passing seconds represented by a moving red dot on the bottom line. Thus, one can tell time with a 5-minutes "precision" at a very quick glance.

I will soon publish a new software release that will include this mode. It will also include some other changes I've done recently:

• moved some "app" functionality out of the main class (WiseClock.cpp) into their own separate classes (AppDemo, AppPacman); will probably need to re-organize WiseClock.cpp, since it almost grew beyond a manageable size (currently at 103KB);

• in dual-display mode (64x16 resolution), extended AppCountdown to include days in addition to hours: minutes:seconds;

Below is a clip of the countdown in action. The bottom line can show (subject to code change) either the current time (HH:MM::SS) or a static line as in the photo above.

For comparison, this is how the countdown looks on the single-display Wise Clock 4.

• used (long overdue) proper C++ polymorphism (created CAppBase class with pure virtual functions) to simplify the calls to run() functions of each app class (which are now derived from the base class); essentially, most of the case branches in the switch statement are gone and replaced by a simple pCrtApp->run(), as shown in the code snippet below:

switch (crtApp)
{
case APP_TMP:
ms = runappTmp();
break;
case APP_NEWSD:
ms = runappNewSD();
break;
case APP_STATS:
ms = runappStats();
break;
case APP_SET_POWER_ON:
ms = runappSetPowerOn();
break;
default:// for all other apps;
ms = pCrtApp->run();
}

Arduino-compatible VFD modular clock from Akafugu

There aren't many VFD clock kits out there that are software-compatible with Arduino (and by that I mean the "Arduino sketch" being compilable in Arduino IDE and uploadable through USB-FTDI).
Most of these kits come with the microcontroller pre-programmed, so they can be built quickly and easily, with minimal effort (totally understandable instant gratification; nobody wants to end up with an expensive dud). Upgrading the software usually requires familiarity with the microcontroller toolchain (compile-build-flash), plus an ISP programmer. (Note: The only processor I am familiar with is AVR/Atmega.)

I was going to build myself an Arduino-based VFD clock, one that can take a sketch through the FTDI cable. Instead of starting from scratch (choosing a schematic, making the board etc), I decided to try one of the only 2 open-source VFD clock kits I found that are based on Atmega processor and :

• Adafruit's Ice Clock
• Akafugu VFD modular clock

I settled for the VFD modular clock because the Akafugu people offered me the pair of PCBs in their kit (for a very reasonable $19, shipping included) and also because I already had most of the parts, including the two SMDs (that come pre-soldered in the kit: ATmega328 and HV5812) and the IV-17 VFD tubes.

I built the clock following their great assembling instructions, but, as you will see, not without hitting a few stumbling blocks on the way.

I should clarify that this post is not a review of the VFD modular clock kit (since I did not have the kit), but just a record of my observations. It was my choice to not use the kit, thus forcing myself to try to understand the schematic and the software.

Since my goal was to make the VFD modular clock Arduino-compatible, I was aware of the challenges awaiting me:
- burning the bootloader for ATmega328 with internal 8MHz oscillator;
- connecting a makeshift FTDI header;
- adapting the software to work in Arduino IDE;

Once I figured out the fuses, burning the bootloader was straightforward. For this purpose I created this section in boards.txt:

intclock328.name= ATmega328 Internal clock 8MHz
intclock328.upload.protocol=stk500
intclock328.upload.maximum_size=30720
intclock328.upload.speed=57600
intclock328.bootloader.low_fuses=0xE2
intclock328.bootloader.high_fuses=0xDA
intclock328.bootloader.extended_fuses=0x05
intclock328.bootloader.path=atmega
intclock328.bootloader.file=ATmegaBOOT_168_atmega328_pro_8MHz.hex
intclock328.bootloader.unlock_bits=0x3F
intclock328.bootloader.lock_bits=0x0F
intclock328.build.mcu=atmega328p
intclock328.build.f_cpu=8000000L
intclock328.build.core=arduino

Then I checked that the bootloader works, by uploading a simple sketch that outputs on D9 (which is connected to the buzzer). Before doing this, I had to connect the FTDI breakout to the board. Luckily (more probably intentionally), all of the required pins (Rx, Tx, Vcc, Gnd, Rst) are broken out on the female header, so just using wires worked, as shown in the next photo. This is not a nice solution though, since the top board (with the VFDs) needs to be removed before every sketch upload. (Hopefully the Akafugu team will also include an FTDI header in the next revision.)

After I soldered all the parts on the base board, I realized the biggest problem of them all: some parts (sourced by me, and obviously of different size than those in the kit) stuck well above the two lateral headers, so the display shield (upper board) could not be plugged in the base board. Almost a showstopper at this point. The solution was to replace the tall 330uF/16V capacitor, bend both 47uF capacitors sideways, replace the 330uF/50V with a pair of thinner 100uF, push both inductors as much into the PCB as possible, then cut the top plastic wrapping on one of them. These, combined with the male headers not being flush to the display board when I soldered them, did the trick. I managed to have the clock looking as intended by its creators (if you don't look too closely), as shown in the next photo.

The Akafugu designers tried to minimize the size of the clock, leaving little room for flexibility (that is, ability to use a broader range of components, of different sizes eventually). The sizes for the chosen components (especially the capacitors and the inductors) are really unique, any deviation would lead to the boards not fitting together.
Using (smaller) SMD components would not be a good solution, since these would also need to be pre-soldered (or otherwise potential non-SMD-soldering clients would be excluded). The only compromise I can think of is enlarging the base board a little bit, keeping in mind that this 4-tube version is the smallest of the display boards, all others extending laterally beyond both sides of the base board.

And finally, the last challenge: the software. I started from the original C code published here. This was written for the avr-gcc compiler and produces a hex file, which is then flashed onto the processor (no bootloader needed, nor provided) using an ISP programmer.

I changed the code (available here), mostly cosmetically, to compile with Arduino 1.0. It does not require any other external libraries and it includes its own I2C/Wire functions (does not use Arduino's Wire library).

In the end, I have an Arduino-compatible Akafugu VFD modular clock that looks just like the original one (I need to add the spacers though).

Unifont on Wise Clock 3/4

This was a quick experiment inspired by WyoLum's EReader library: displaying Unicode characters on the 3216 display from Sure Electronics (as used in Wise Clock 3/4).

The fonts (developed by Roman Czyborra a very long time ago (1998!) and documented here) are defined in the file unifont.wff on the SD card. Before a character is displayed, its 32-byte definition is loaded from the file, starting from the calculated address.

The simple sketch used in the above video can be found here. It was tested with Arduino 1.0.4 and does not require the EReader library (but requires the unifont.wff file on the SD card).

PS  For the non-Chinese speakers/readers, the displayed symbol is "nihao" ("hello"), Unicode 0x6829.

Play WAV files from SD card with Wise Clock 3/4 board

The video below shows another hack for Wise Clock 3/4, playing a WAV file directly (not using extra hardware) from SD card, with the help of the TMRpcm library.



The TMRpcm software uses the standard SD library (coming with Arduino IDE 1.0 and later) to read WAV files from SD card. To output the audio while buffering the content of the SD file, TMRpcm uses ISR triggered by internal timer. The buzzer/speaker can be connected only to certain pins of the processor. For ATmega1284/ATmega644 (used in Wise Clock 3/4), these pins are D3, D4, D12, D13, D14 and D15, as shown in the definition below (from sanguino core file pins_arduino.c).

From the perspective of TMRpcm library, the buzzer in Wise Clock 4 is connected to the "wrong" pins, D22 and D23, which are not eligible for this trick. I chose to connect another speaker to pin D13, but that's already taken by the display (CS, pin 1). So I had to cut the trace from D13 to the display, and connect pin 1 of the display to D18 (another choice was D19, the only other available I/O left).

From now on it's only software.

• modify this line in HT1632.cpp:

    #define HT1632_CS 18 //  Chip Select (pin 1 of display connector)

• add line

     #define SPEAKER_PIN1  13

Then follow from step 4 of this previous post.

Unfortunately, this will not work with Wise Clock 4 software as is, and the main reason is the timer interrupts used by TMRpcm library, which disrupt the "SPI-like" commands for the display.

The video above may seem like another Wise Clock "app", but it is just a "cheating" sketch running standalone, shown below.


#include "Arduino.h"
#include "Wire.h"
#include "DS3231.h"
#include "HT1632.h"
#include "AlarmClock.h"
#include "WiseClock.h"
#include "SD.h"
#include "TMRpcm.h"
#define SD_ChipSelectPin   4
#define AudioPin          13  // must be PWM pin

TMRpcm tmrpcm;

//**********************
void setup()
{
  Serial.begin(9600);

  // disable JTAG (to use pin D18);
  uint8_t tmp = 1<
  MCUCR = tmp;
  MCUCR = tmp;

  ht1632_setup();

  SD.begin(SD_ChipSelectPin);
  tmrpcm.speakerPin = AudioPin;
}

//*********************
void loop()
{
  alarmClock.isAlarmEnabled = true;
  alarmClock.getTimeFromRTC();

  Serial.print("Time is: ");
  Serial.print(alarmClock.hour, DEC);
  Serial.print(":");
  Serial.print(alarmClock.minute, DEC);
  Serial.print(":");
  Serial.println(alarmClock.second, DEC);
  
  if (!tmrpcm.isPlaying())
  {
    ht1632_putTinyString(0, 0, "Playing", RED);
    wiseClock.displayTime(8, false);
    tmrpcm.play("dancing.wav");
  }
  delay(2000);
}

The display is statically updated once, before the WAV file starts playing.

It would probably be possible to update the display between playing short WAV files (with interrupts disabled right after each file is played). But that may open a door to other set of problems, since the display is practically frozen for the duration of the file playing. On the other hand, the I2C (through Wire library) works just fine (that's because I2C is hardware driven), so getting the current time from RTC while playing music is not an issue.

Conclusion
Although in theory would be possible to integrate TMRpcm library in the Wise Clock software (to play WAV files from SD card while the clock functionality is not affected), in practice that would take a lot of programming effort. A much easier and cheaper way to include audio into Wise Clock 4 (hardware and software) would be through the use of serially controlled audio-playback specialized modules, like this one (or maybe even the radio/MP3 module I reviewed here, if I ever find it in my pile of stuff).