More WiFiChron variants

This post shows two WiFiChron mods, that look more like finished projects rather than just experiments.

First one uses the WiFiChron board connected on I2C to two Adafruit Quad Alphanumeric Displays (I2C addresses 0x70 and 0x71). The WiFiChron software has similar adaptation as the one for HDSP clock (see this post for details).

Did I mention that two plexiglass plates are still waiting to be cut and screwed in the standoffs?

This (poor) video shows it in action.

The interesting thing about the Chinese clones (of the Adafruit displays) I had in hand is that each module has one (2 digit) display red and the other orange. Initially I thought it's a manufacturing error, but after checking, it seems that this is intended (for reasons I do not understand).

The second one is an "HDSP clock" with a 8-character display with 16-segment LED modules, introduced here, cased in a LEGO enclosure.

After cutting the top of board off (since there is no HDSP-2534) and a little filing of all sides, the PCB fit perfectly between the LEGO bricks.

For this display, the line that has to be enabled (un-commented) in DAL.h is:

#define DISPLAY_HT16K33

Alternative displays for HDSP or WiFiChron clocks

So you would like to build your own HDSP clock or WiFiChron clock but you find the HDSP-2534 display too small or too expensive. Why not just replace it with a bigger 8-character display, like the 1-inch 8 x 16-segment or two cascaded Adafruit 0.54" 4 x 14-segment backpacks? We have you covered, in software. Both these displays are now supported, as extension classes of the DAL (Display Abstraction Layer), together with the 128x64 I2C OLED and the HT1632-based 32x8 LED matrix display (used to be from Sure  Electronics). Support could be further extended to LCD displays (think big font on 40x4), MAX6955 with 8 x 16 segment etc., basically anything that can show 8 alphanumeric characters (numbers only, like regular Nixie tubes, would not suffice).

Below are some examples.

Two Adafruit 4-character backpacks are connected on I2C, addresses 0x70 (default) and 0x71, handled by class DisplayAda14seg, which in turn uses the Adafruit_LEDBackpack library.

To enable this display, uncomment the line (in DAL.h, comment out the rest):

#define DISPLAY_ADA_14SEG  // 2 x Adafruit 4x14seg displays;

Functionality for the 8x32 (or 16x32) LED matrix display is implemented in class DisplayHT1632, which is based on code recycled from Wise Clock 4. To enable this display, simply uncomment the line (in DAL.h, comment out the others):

#define DISPLAY_HT1632	 // Sure 8x32 LED matrix controlled by HT1632;

To accommodate the 8 characters on a 32-pixel line, fontTiny had to be used (each character is 4 pixels wide).

Note the connections for the HT1632 display (in DisplayHT1632.cpp):

#define HT1632_DATA 4 // Data pin (pin 7 of display connector)

#define HT1632_CS         3      // Chip Select (pin 1 of display connnector)

#define HT1632_WRCLK 2 // Write clock pin (pin 5 of display connector)

#define HT1632_CLK 5 // clock pin (pin 2 of display connector)

Other possible definitions in DAL.h are:

//****************************************************************************************
// Define the display you wish to use here.
// Comment out the ones not used.

//#define DISPLAY_HDSP2534	// original HDSP-2534 display in HDSP clock;
//#define DISPLAY_HUB08		// TODO: 8x32 LED matrix display with cascading shift registers (?)
//#define DISPLAY_DL1414	// 2 x DL1414; tested June 23, 2018 (http://timewitharduino.blogspot.com/2018/06/wifichron-adapter-for-dl-1414-displays.html)
//#define DISPLAY_HT16K33	// my 8x16-segment driven by HK16K33, tested Jul 26, 2020;
//#define DISPLAY_OLED		// I2C OLED; tested
  #define DISPLAY_HT1632	// Sure 8x32 LED matrix controlled by HT1632; tested Aug 14, 2020;
//#define DISPLAY_MAX6955	// TODO: 8x16 segment driven by MAX6955
//#define DISPLAY_LCD1602	// TODO: classic LCD 16x2 (or better 40x4, with big font);
//#define DISPLAY_ADA_14SEG	// 2 x Adafruit 4x14seg displays, wired on 0x70 and 0x71 I2C addresses; tested Jul 26, 2020;

// show time on the 60-pixel Adafruit Neopixel ring;
//#define _ADD_NEOPIXEL_
//****************************************************************************************

And so on.

HDSP clock with SCD5583 display

Here is another interesting "intelligent" LED matrix display, whose name actually makes some sense (unlike HDSP-2354, among many others): SCD5583A. I reckon it means: "Serial Character Display with 5x5x8 dot matrix". 3 is the code for green (0 for red, 1 for yellow).
This display is now obsolete (replaced by touch screens in avionics, the industry for which it was designed), but it is still available on ebay for a reasonable price (except for incredibly high shipping cost).

Compared to other intelligent displays like the above-mentioned HDSP-2534 employed by the HDSP clock (hence the bland unimaginative name), SCD558X does not have an internally-defined font and requires the user to provide one. This makes it a little more complicated to use, but also allows for more flexibility, making it truly international (non-English character set). Even more, each pixel can be addressed individually, like a graphical 5x40 LED matrix.
The fact that is serial means fewer pins are required for interfacing (3 control pins in this case) and less driving circuitry (no need for the external shift register).

The photo below shows the display connected to an Arduino and running the HDSP sketch adapted for SCD5833.

Practically, the HDSP sketch uses only one function to write to display, aptly called "writeDisplay()", that needs to be re-written. The support for SCD5583 is provided by the class SCD5583, shown below (header + cpp files, compiled with Arduino IDE 1.8.13).

#ifndef _SCD5583_H_
#define _SCD5583_H_

#include  "Arduino.h"

class SCD5583
{
  public:
    SCD5583(byte loadPin, byte dataPin, byte clkPin);
    void clearMatrix();
    void setBrightness(byte b);
    void writeLine(char text[9]);

  private:
    void _sendData(byte data);
    void _getCharDefinition(byte* rows, char c);
    void _selectIndex(byte position);

    byte _loadPin;
    byte _dataPin;
    byte _clkPin;
};

#endif // _SCD5583_H_

-----------------------------------------------

#include "SCD5583.h"
#include "font5x5.h"

#define MAX_CHARS 8   // set to 10 for SCD5510X (10 digits) or to 4 for SCD554X (4 digits);
#define NUM_ROWS  5

SCD5583::SCD5583(byte loadPin, byte dataPin, byte clkPin)
{
  pinMode(loadPin, OUTPUT);
  pinMode(dataPin, OUTPUT);
  pinMode(clkPin, OUTPUT);
  _loadPin = loadPin;
  _dataPin = dataPin;
  _clkPin  = clkPin;
  clearMatrix();
//  setBrightness(0);
}

void SCD5583::clearMatrix()
{
  _sendData(B11000000);
}

void SCD5583::setBrightness(byte b)
{
  if (b > 0 && b < 7)
  {
     _sendData(B11110000 + b);
  }
}

void SCD5583::_selectIndex(byte position)
{
   _sendData(B10100000 + position);
}

void SCD5583::_sendData(byte data)
{
  byte mask = 1;
  digitalWrite(_loadPin, LOW);
  digitalWrite(_clkPin,  LOW);
  for (byte i = 0; i < 8; i++)
  {
    digitalWrite(_dataPin, mask & data? HIGH : LOW);
    digitalWrite(_clkPin, HIGH);
//  delay(10);
    digitalWrite(_clkPin, LOW);
    mask = mask*2;
  }
  digitalWrite(_loadPin, HIGH);
}

void SCD5583::_getCharDefinition(byte* rows, char c)
{
  for (byte i = 0; i < NUM_ROWS; i++)
  {
    rows[i] = font5x5[((c- 0x20) * NUM_ROWS) + i];
  }
}

void SCD5583::writeLine(char* text)
{
  byte rows[NUM_ROWS];
  for (int i = 0; i < MAX_CHARS; i++)
  {
    _selectIndex(i);
    _getCharDefinition(rows, text[i]);
    for (int r = 0; r < NUM_ROWS; r++)
    {
      _sendData(rows[r]);
    }
  }
}

As mentioned previously, the font must be provided too (content of file "font5x5.h" shown below):

#ifndef _FONT5X5_H_
#define _FONT5X5_H_

// ascii characters 0x41-0x7a (32-127);
static unsigned char font5x5[] =
{
  0x00, 0x20, 0x40, 0x60, 0x80, // space
  0x04, 0x24, 0x44, 0x60, 0x84, // !
  0x0A, 0x2A, 0x40, 0x60, 0x80, // "
  0x0A, 0x3F, 0x4A, 0x7F, 0x8A, // #
  0x0F, 0x34, 0x4E, 0x65, 0x9E, // $
  0x19, 0x3A, 0x44, 0x6B, 0x93, // %
  0x08, 0x34, 0x4D, 0x72, 0x8D, // &
  0x04, 0x24, 0x40, 0x60, 0x80, // '
  0x02, 0x24, 0x44, 0x64, 0x82, // (
  0x08, 0x24, 0x44, 0x64, 0x88, // )
  0x15, 0x2E, 0x5F, 0x6E, 0x95, // *
  0x04, 0x24, 0x5F, 0x64, 0x84, // +
  0x00, 0x20, 0x40, 0x64, 0x84, // ,
  0x00, 0x20, 0x4E, 0x60, 0x80, // -
  0x00, 0x20, 0x40, 0x60, 0x84, // .
  0x01, 0x22, 0x44, 0x68, 0x90, // /
  0x0E, 0x33, 0x55, 0x79, 0x8E, // 0
  0x04, 0x2C, 0x44, 0x64, 0x8E, // 1
  0x1E, 0x21, 0x46, 0x68, 0x9F, // 2
  0x1E, 0x21, 0x4E, 0x61, 0x9E, // 3
  0x06, 0x2A, 0x5F, 0x62, 0x82, // 4
  0x1F, 0x30, 0x5E, 0x61, 0x9E, // 5
  0x06, 0x28, 0x5E, 0x71, 0x8E, // 6
  0x1F, 0x22, 0x44, 0x68, 0x88, // 7
  0x0E, 0x31, 0x4E, 0x71, 0x8E, // 8
  0x0E, 0x31, 0x4F, 0x62, 0x8C, // 9
  0x00, 0x24, 0x40, 0x64, 0x80, // :
  0x00, 0x24, 0x40, 0x6C, 0x80, // ;
  0x02, 0x24, 0x48, 0x64, 0x82, // <
  0x00, 0x3F, 0x40, 0x7F, 0x80, // =
  0x08, 0x24, 0x42, 0x64, 0x88, // >
  0x0E, 0x31, 0x42, 0x64, 0x84, // ?
  0x0E, 0x35, 0x57, 0x70, 0x8E, // @
  0x04, 0x2A, 0x5F, 0x71, 0x91, // A
  0x1E, 0x29, 0x4E, 0x69, 0x9E, // B
  0x0F, 0x30, 0x50, 0x70, 0x8F, // C
  0x1E, 0x29, 0x49, 0x69, 0x9E, // D
  0x1F, 0x30, 0x5E, 0x70, 0x9F, // E
  0x1F, 0x30, 0x5E, 0x70, 0x90, // F
  0x0F, 0x30, 0x53, 0x71, 0x8F, // G
  0x11, 0x31, 0x5F, 0x71, 0x91, // H
  0x0E, 0x24, 0x44, 0x64, 0x8E, // I
  0x01, 0x21, 0x41, 0x71, 0x8E, // J
  0x13, 0x34, 0x58, 0x74, 0x93, // K
  0x10, 0x30, 0x50, 0x70, 0x9F, // L
  0x11, 0x3B, 0x55, 0x71, 0x91, // M
  0x11, 0x39, 0x55, 0x73, 0x91, // N
  0x0E, 0x31, 0x51, 0x71, 0x8E, // O
  0x1E, 0x31, 0x5E, 0x70, 0x90, // P
  0x0C, 0x32, 0x56, 0x72, 0x8D, // Q
  0x1E, 0x31, 0x5E, 0x74, 0x92, // R
  0x0F, 0x30, 0x4E, 0x61, 0x9E, // S
  0x1F, 0x24, 0x44, 0x64, 0x84, // T
  0x11, 0x31, 0x51, 0x71, 0x8E, // U
  0x11, 0x31, 0x51, 0x6A, 0x84, // V
  0x11, 0x31, 0x55, 0x7B, 0x91, // W
  0x11, 0x2A, 0x44, 0x6A, 0x91, // X
  0x11, 0x2A, 0x44, 0x64, 0x84, // Y
  0x1F, 0x22, 0x44, 0x68, 0x9F, // Z
  0x07, 0x24, 0x44, 0x64, 0x87, // [
  0x10, 0x28, 0x44, 0x62, 0x81, // \
  0x1C, 0x24, 0x44, 0x64, 0x9C, // ]
  0x04, 0x2A, 0x51, 0x60, 0x80, // ^
  0x00, 0x20, 0x40, 0x60, 0x9F, // _
  0x0A, 0x2A, 0x40, 0x60, 0x80, // '
  0x00, 0x2E, 0x52, 0x72, 0x8D, // a
  0x10, 0x30, 0x5E, 0x71, 0x9E, // b
  0x00, 0x2F, 0x50, 0x70, 0x8F, // c
  0x01, 0x21, 0x4F, 0x71, 0x8F, // d
  0x00, 0x2E, 0x5F, 0x70, 0x8E, // e
  0x04, 0x2A, 0x48, 0x7C, 0x88, // f
  0x00, 0x2F, 0x50, 0x73, 0x8F, // g
  0x10, 0x30, 0x56, 0x79, 0x91, // h
  0x04, 0x20, 0x4C, 0x64, 0x8E, // i
  0x00, 0x26, 0x42, 0x72, 0x8C, // j
  0x10, 0x30, 0x56, 0x78, 0x96, // k
  0x0C, 0x24, 0x44, 0x64, 0x8E, // l
  0x00, 0x2A, 0x55, 0x71, 0x91, // m
  0x00, 0x36, 0x59, 0x71, 0x91, // n
  0x00, 0x2E, 0x51, 0x71, 0x8E, // o
  0x00, 0x3E, 0x51, 0x7E, 0x90, // p
  0x00, 0x2F, 0x51, 0x6F, 0x81, // q
  0x00, 0x33, 0x54, 0x78, 0x90, // r
  0x00, 0x23, 0x44, 0x62, 0x8C, // s
  0x08, 0x3C, 0x48, 0x6A, 0x84, // t
  0x00, 0x32, 0x52, 0x72, 0x8D, // u
  0x00, 0x31, 0x51, 0x6A, 0x84, // v
  0x00, 0x31, 0x55, 0x7B, 0x91, // w
  0x00, 0x32, 0x4C, 0x6C, 0x92, // x
  0x00, 0x31, 0x4A, 0x64, 0x98, // y
  0x00, 0x3E, 0x44, 0x68, 0x9E, // z
  0x06, 0x24, 0x48, 0x64, 0x86, // {
  0x04, 0x24, 0x44, 0x64, 0x84, // |
  0x0C, 0x24, 0x42, 0x64, 0x8C, // }
  0x00, 0x27, 0x5C, 0x60, 0x80, // ~
};

#endif  // _FONT5X5_H_

And finally, the changes in HDSP.ino are:

1. add the following line at the top:

#include "SCD5583.h"

// SCD5583 pins: LOAD to D4, DATA to D5, SDCLK to D3;
SCD5583 scd(4,5,3);

2. replace the function writeDisplay() written for HDSP-2534, with the following:

void writeDisplay()
{
  scd.writeLine(displayBuffer);
}

Hardware-wise, some re-wiring is required on the HDSP board, starting with the removal of the 595 shift register. Then, D3, D4 and D5 (ATmega328 pins 5, 6, 11) must be connected respectively to SDCLK, LOAD and DATA pins (1, 2, 27) of the SCD5583 display.

And there you have it, a working HDSP clock with SCD5583 display.

It is worth mentioning that the measured current drawn was between 10mA (lowest brightness) and 20mA (highest), and that it works similarly well when powered by 3V3.

Teardown of an Old Dimmer Switch

The 40+ year-old dimmer (made by Nortron Industries Limited in Milton, Ontario) in my attic broke down. Electronically, the dimming circuit still worked, but mechanically, the push button got stuck.
This is what's inside, for the curious.

The active component in the circuit is Q2006LT, a "quadrac" which, according to the datasheet, "is an internally triggered Triac designed for AC switching and phase control applications. It is a Triac and DIAC in a single package, which saves user expense by eliminating the need for separate Triac and DIAC components".

The "reversed-engineered" schematic looks like this:

For those who want to understand more on how the triac-controlled dimmer works, this article provides an in-depth explanation.

The 250V capacitors may be reused in a Nixie high-voltage (~170V) power source. For a hoarder, both the choke and the potentiometer (push button removed) look good.

I will report back on the internals of the replacement switch in 40 years or so, when it breaks down. I hope I/it last(s) that long.

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

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.

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

Here are a few more detail photos on the wires that connect the buttons:

The hour buttons (on the left) is connected to A1.
The minutes button (right side) is connected to A0.
The "12/24H mode" header pins (with jumper, at the bottom side of the board) are connected to A2 and GND. Jumper on means pin A2 to the ground, thus enabling 12H mode.

WiFiChron adapter for DL-1414 displays

WiFiChron has now support for the obsolete (?) DL-1414 displays. I know, the question everybody is probably asking is "why bother?" The immediate answer is because these displays are cheap and easy to find (on ebay or Chinese electronics suppliers), compared to the HDSP-2534. I actually got a few as a gift from Mr. Kin, thank you very much!

DL-1414 is a 4-character 16-segment parallel intelligent display, the grandfather of HDSP-2534: put an ASCII code on the data lines, then flick the WR line, and there you have it, a character displayed at the position specified by A0 and A1 bits. It really does not get any simpler than this. The character set definition, also similar HDSP-2534 (only defines upper case letters though) is stored internally, so there is no need to manipulate any of the 16 segments individually. Although the magnifiers ("bubbles") make them look somehow like QDSP-6064, the DL-1414 display is much smarter, and therefore much easier to interface and program.

Below are some photos of the prototype adapter for the HDSP clock horizontal mod (more of them shown here).

The adapter PCB I designed is available from oshpark (not tested though).

Note that the DL-1414 display is higher, so it won't fit in the Serpac A20 enclosure, but it will fit in the Serpac A21.

Adapting the HDSP/WiFiChron code was super easy. The only functions requiring change are writeChar(...) and writeDisplay(). The next images show these 2 functions side by side, for DL-1414 (left) and HDSP-2534 (right):

Note that the 2 chips share the D0-D6 and A0-A1 lines, but WR lines are separate, which allows individual control of each chip.

In the end, the DL-1414 offers the same functionality as HDSP-2534, at a lower cost, but also with less visibility (characters are about half the size) and less coolness (harsher "font", no lower case).

The DL-1414 experiment opened the door for future WiFiChron displays. Essentially, any 8-character display can be adapted by modifying the two above mentioned functions. This will be next. Stay tuned.

Upgrade your HDSP clock to an NTP-synchronized WiFiChron

So you have the simple HDSP clock but you wish you had the NTP-based time synchronization and the weather feature of the WiFiChron (not to mention the alarm). The "solution" is to buy the WiFiChron kit :)

The alternative "solution" is to hack your HDSP clock, by adding a proto-shield with an ESP8266 module, a 3V3 regulator (e.g. MCP1700) and a buzzer, the components that make the difference between the two clocks.

Before building the ESP8266 proto-shield, perform the following 4 modifications (highlighted in the next photo) on the HDSP board:

1. isolate the FTDI's CTS pin (second from the top) by cutting its traces to the ground;
2. wire the newly isolated FTDI pin 2 to pin 16 of the processor (D10, used for the buzzer);
3. cut the trace connecting pin 1 of the LED display (RST) to pin 3 of the processor;
4. solder the right angle FTDI male header on the back of the board, towards the USB plug.

The small proto-shield, that looks like in the photos below, will plug in the FTDI header. Naturally, the same FTDI header is used for either the FDTI breakout (to upload sketches) or the ESP8266 proto-shield.

Besides the hardware, one little software change (of the original WiFiChron sketch, available here) is required as well, due to the second button connected to A3 (instead of A1 as in WiFiChron):

    #define PIN_BTN_UP 17  // A3 in hacked HDSP
// #define PIN_BTN_UP 15  // A1 in WiFiChron

Since the 3rd button ("Down") is missing on the HDSP board, only the "Up" button function will be available (the left button).

Follow this post to set up the network connection.
And remember, the ESP8266 baud rate MUST be lower than 115200 (set it to 38400), since the ATmega328 with internal clock cannot handle this speed reliably (according to the datasheet, the drift is about 8%).