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):

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.



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

The latest revision of WiFiChron has an XBee socket (beside the ESP8266 8-pin socket), which allows the addition of a few individual features:

1. GPS-based time synchronization, by using the GPSBee;
2. displaying messages sent from a Bluetooth device, by using the BTBee/BLEBee;
3. displaying data acquired from an XBee/ZigBee network of sensors (not implemented yet);

Things did not go smoothly, without some drama though. Naively (I always seem to forget that there is a difference between theory and practice), I designed the XBee/ESP to connect to the serial port, with the expectation that once the development (including testing with debug statements to the serial monitor) is done, I will just plug in the serial module (either XBee of ESP8266) and things will work properly. Well, I had to re-consider this approach once again. Luckily, I had two pins left available (D7 and D17), which I could use for software serial. I re-wired those to the XBee/ESP and used the hardware serial for console communication. Until the next board revision, anyone wanting to follow will need to re-route a couple of traces manually, as shown in the photos below (cuts are red-circled).


A few details on my implementation of the GPS time sync (so that one doesn't need to look at the code to figure it out):

• user can set a timezone (stored in eeprom, default is -1); there is no (easy) way to determine if the timezone was set or not, since -1 (eeprom byte being 255) is a valid value;
• estimate the timezone from the longitude, assuming that a every 15 degrees is an hour difference;
• a difference between GPS estimated timezone and the user-set timezone of more than 2 hours would mean that the time is way off and the user did not set the timezone; in this case, blink the display; a difference of 2 hours or less would be acceptable (for many reasons, including summer-time, or variations from the "15-degrees-longitude-per-hour" approximation);
• in any case, the minutes and seconds are set from the GPS data;
• date and day are not set/synchronized at all (currently);
• the GPS sync is scheduled to happen every 10 hours (and also after a reset);
• a successful sync is indicated by an up arrow at the end of the scrolling date (e.g. March 29, 2015 ^).

I will publish the code as soon as I have a chance to polish it (and also test it with BTBee).