Friday, May 10, 2019

Clock super-display

Today was a good day. In typical fashion, I started a few new "projects" almost in the same time. First one, it's assembling of a new kind of clock, from a kit sent by Nick S. I got stuck pretty early though, so I "parked" it for now. Details to come soon, in a special post.

Second one, an "Adler 121PD" vintage calculator with a VFD display, that I found "in the dumpster" (well, not really, but the idea is the same, I got it for free). I was going to break it apart, for the display and the circuitry, but I gave up when I powered it up (with an improvised cable; the original, proprietary one, was missing) and it actually worked! I may still go ahead with dis-assembling it, since it is not a great value anyway; I checked prices on ebay, and they go for around $20.

Lastly, the project that gave the name of this post: a clock LED super-display, consisting of 3 individual and independent indicators, inspired by the Leitch studio clock, brought to my attention by Nick (VE2HOT). The goal for the clock super-display is to eventually be able to emulate the Leitch clock. Here it is, in its incipient glory (only the back panel; the black wooden frame not pictured):

Since I am not the crafty kind-of-guy (also not keen on spending for form more than for content), I am always looking for cheap, easy and quick solutions for encasing electronics. In this case, Ikea's Ribba 9"x9" frame ($10) seems to be a good fit for the job, and hopefully will help the future clock look "Leitchy" or even better (Nick's photo below):

The 2 alphanumeric displays (4 and 8 chars) of the clock super-display are I2C-driven. The 60 LED ring is adafruit neopixel, controlled by a single pin. With this setup, even an ESP8266 module could be used as the brains of the clock.

The ring is fixed to the cardboard back/panel of the deep Ikea frame with four M3 plastic standoffs glued to the PCB.
The 4-character alphanumeric 16-segment is my creation, introduced earlier. It is driven by the HT16K33 backpack, also from adafruit (not in the picture). The PCB has M3 holes for screws.
The 8-character alphanumeric is made of two side-by-side quad 14-segment LED displays, also from adafruit. The 2 modules already have the HT16K33 drivers installed (soldered on the back). Attaching these quad displays to the panel is not easy, since the holes are probably M1.4. Even these thin M1.4 screws need to be forced, because the screw head presses against display's plastic enclosure. Eventually, the M1.4 screws will be glued to the M3 plastic standoffs, that's the best I could come up with. It is weird that, for such a popular and successful product, one cannot find photos (or instructions) on mounting these modules using screws.

Next step is the software support in the WiFiChron software. Also need to find a way to access the 3 buttons: having them in the back is not a good idea, having them in the front is impossible, unless the glass is replaced with transparent/smoky/grey acrylic, which can be drilled.

Monday, April 22, 2019

Hacking DWex into combo analog-digital clock

DWex, my forgotten watch, was not a successful project, probably because I rushed its design, I spent more money on it than I planned and I did not follow up with revisions. DWex was also not offered as a kit, but as an assembled board with SMD components, not easily hackable or expandable, pretty much a dead end from hardware perspective. Its idea is still sound though, after so many years: mostly sleep, to conserve battery, then, at a press of a button, flicker some LEDs to indicate the time.

This rainy Easter weekend I stumbled upon the few DWex boards I still have, and they brought back memories. One thought lead to another, and I found myself, characteristically (I am the "penny wise, pound foolish"- kind), soldering around once again. So here I am, writing another useless post, about another useless project, on how to convert time, money and energy into joy, sometimes mixed with frustration, when things don't work on the first try (as it's usually the case).

DWex is equivalent to a smaller wsduino (ATmega328 + RTC), with 24 LEDs. Why not recycle it into something physically "bigger", by adding extras (alphanumeric display, micro switches, ESP8266, OLED etc.)?
The design of the DWex board has a few peculiarities:
  • RTC chip is DS1337, with support for alarms;
  • the on-board CR2025 3V battery powers the whole watch, not only the RTC (there is no time keeping without a battery);
  • FTDI connector does not have Vcc wired, relying instead on the battery to power the processor while uploading the sketch;
  • the ATmega328 processor is clocked with an external 8MHz crystal, thus making the board compatible with LilyPad 328;
  • pins available are D11, D12 and D13, all broken out on the ISP connector (unused are also D2 and D10, but they would need to be wired directly from the processor's pins);
  • features only one button.
But the most particular aspect of DWex is the way it shows the time on the analog round face, by blinking LEDs on request (button push). This is actually not suitable for continuous display, simply because it is confusing to make sense of non-stop blinking LEDs.
OK, so enough complaining. Here is what we plan to do:
  • add a 4-digit alphanumeric Adafruit I2C 0.54" display;
  • add ESP8266 module to sync the clock on NTP;
  • add toggle switch for setting up wifi parameters (for ESP8266);
  • use RTC's alarm capability; add toggle switch and buzzer (or other audio module) for alarm mode;
  • add OLED (I2C) for displaying messages, info etc;
  • modify the software, a combination of DWex and WiFiChron, to support all of the above features, plus change the way the time is shown on the analog face (no more sleep, no button press to show the time);
  • add "seconds" mode, on the digital display;
  • maybe adapt the 8-character-based menu system from WiFiChron to 4-character (by showing only the first 1 or 2 letters of the menu);
  • add 3V3/500mA regulator to the board.

This will be a work-in-progress for a while, especially on the software (which I will publish later).

Saturday, April 13, 2019

WiFiChron support for 16-segment LED display

This is the second time I am writing this post. First time it just disappeared after almost 2 hours of editing. I started the post by saying that whenever I want to have some electronics fun, I open one of my drawers. Nice story line, but I am too frustrated now to recreate it from memory. (The lesson I learned is that I should write it first as a document, save locally, then copy and paste into a blog post.)
So I will keep it short and dry.

Some time ago, I designed this "4-character 16-segment 1-inch LED" board (pictured below), briefly mentioned here. I abandoned it, after a couple of failed tries, while writing the character definitions. Since then, I discovered the Adafruit 4-char alphanumeric LED backpack, which comes with nice software support as well.

For WiFiChron, two cascaded modules make an 8-character display functionally similar to HDSP-2534, but bigger and more visible. With the "Display Abstraction Layer" already in place, software support should be easy to integrate, since controlling it with the HT16K33 breakout allows the re-use of the above mentioned Adafruit LED backpack library. For maximum compatibility, I followed the same wiring, then connected the two extra segments, A2 and D2, to pin 10 (not connected for the 14-segment backpack) and pin 11 (connected to the DP), respectively.

I added a new class, Alphanum8x16, to the original files (Adafruit_LEDBackpack.h and cpp) to control the extra segments:

class Alphanum8x16 : public Adafruit_AlphaNum4 {  public:   void writeDigitAscii(uint8_t n, uint8_t ascii); };
void Alphanum8x16::writeDigitAscii(uint8_t n, uint8_t a) {   uint16_t font = pgm_read_word(alphafonttable+a);   displaybuffer[n] = font;   //--------------------------------------------------------   // this is the Adafruit mapping of digits to segments:   // 0 DP N M L K J H G2 G1 F E D C B A   //   // this is the 16 seg mapping of digits to segments:   // A2 D2 N M L K J H G2 G1 F E D1 C B A1   //   // bits:   // 1  1  1 ...                 ...  1 0   // 5  4  3   //   // Note: DP is not connected/controlled for the 16 seg;   //--------------------------------------------------------   // if A1 (bit 0) is on, set A2 (bit 15) as well;   if (font & 1)     displaybuffer[n] |= 0x8000;   // if D1 (bit 3) is on, set D2 (bit 14) as well;   if (font & 8)     displaybuffer[n] |= 0x4000; }
The 8x16-segment display is implemented in class DisplayHT16K33 in the WiFiChron software.
So far, WiFiChron can support the following displays (defines in DAL.h):

//#define DISPLAY_HDSP2534
//#define DISPLAY_DL1414
#define DISPLAY_HT16K33
//#define DISPLAY_OLED
//#define DISPLAY_HT1632
//#define DISPLAY_MAX6955

In principle, any display that can show 8 characters can be used through DAL.

Sunday, March 17, 2019

Debugging the IN-17 Nixie clock (aka "Rothko clock")

This weekend I felt like doing something, which rarely happens lately. From the pile of semi-failed ("started but not finished", "finished but not working", "not fully functional" etc.) I picked the Nixie clock with 6 IN-17 tubes. Its problem was that it did not display any 6 nor 7, on all tubes. A quick check with the meter showed, indeed, a short between 2 neighbor pins. Upon visual inspection (not as easy as it used to be) and with a lot of luck (and magnification), I found the culprit: one tube in the middle of them all had two pins crossed (inverted), as shown in the photo below.

Here is the board with the IN-17 removed.

Since it was impossible for me to re-insert the old short-pined IN-17 (because of the tight space), I had to use a new one. Everything turned out well in the end.

Now onto the usability of this pretty Nixie clock. The only way to set the time is to send commands from a Bluetooth device (phone, tablet). This is not very "user friendly", nor quick, is it? The obvious "remedy" to this situation was to add a couple of buttons on top, where they can be easily pressed. As you may know from my old post, the high voltage (170V) for powering the IN-17 tubes is generated in the same top-of-the-board area, definitely not a good place for fingers. The solution was to use a longer piece of prototyping PCB to cover the danger zone.

As in most simple clocks, the right button increments the minutes, the left one increments the hours, while the seconds are always reset.

I also added a hardware "12 hour mode" through the use of a jumper placed at the bottom of the board:

With the jumper off, the clock shows military time (the hours between 0 and 23).

Unlike the first version, this new Nixie clock, which I shall name "Rothko clock" from now on, uses just 2 boards: wsduino (with on-board RTC and XBee support, assembled for 9V power) and the Nixie shield itself. The 2-button hack should be made somehow permanent, probably by adding them onto the Nixie shield, similar to the LED matrix mini display shield used in the Mondrian clock. Also note that the alarm feature won't work (although implemented in the code, shared here) since there is no buzzer. Bluetooth should still work with a BTBee module plugged into its wsduino socket.

Interestingly, after all these years, one "new old stock" IN-17 Nixie tube can still be bought on ebay for about $7 (compared with about $2 for the bigger IN-12s).

Sunday, March 3, 2019

Wise Clock 4 - March 2019 software release

A long overdue (3+ years since the previous one!?) release of the Wise Clock 4 software is finally here. This one compiles on Arduino 1.6.7 (and later) and has a few code improvements, most of them courtesy of MikeM:
  • created a display abstraction layer that will allow porting the display functions away from HT1632 Sure displays, eventually; essentially, any new "compatible" (min 16x32 resolution) display can be supported by implementing the set of functions declared in DisplayBase.h; currently, the HT1632 functions are defined in DisplayHT1632.cpp class;
  • eliminated the need to set the day-of-week, which is now calculated from date (Zeller method);
  • introduced the option to use MiniGPS class instead of TinyGPS, which saves some program memory and also RAM; the improved GPS code uses now a new setting in messages.txt (utc.offset);
  • some bug fixes related to buffer overruns when getting the weather RSS data; Mike discovered this issue after switching to a new weather service (, since the old one (e.g. is no longer supported (protocol was changed to https, which cannot be handled by the current ESP8266 class);
As a reminder note (for myself), the ESP8266 and GPS-related changes mentioned above should also find their way into the WiFiChron code, sometime.

Recently, Nick sent this photo of his stack (stash?) of WiFiChrons.