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.

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 (http://www.rssweather.com/zipcode/27612/rss.php), since the old one (e.g. http://w1.weather.gov/xml/current_obs/KRDU.rss) 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.

Mondrian clock software release

Unbelievably, there is still demand for the Dual LED matrix shield for Arduino, which also pressures me to maintain and upgrade the supporting software, usually on client's request.
And that is how the Mondrian clock got a couple of new display modes: one picked directly from the Cube clock, showing just hours and minutes, the other one an improvement of the same, with the addition of a red dot moving around the rectangular clock face to indicate the seconds.
The display mode changes when both buttons are pressed simultaneously.

Here is the clock in action.

The Mondrian clock uses the Dual LED matrix shield and wsduino (as an RTC-equipped and XBee-supporting Arduino-compatible).
The code is available here. There is no GPS support, but that can be copied and adapted from the previous version of Mondrian software.

Note that the LED matrix shield was designed to accommodate either the common-anode or the common-cathode LED matrices, by soldering the correct LED driver, either A2982 or ULN2803 respectively. In the software, use either one of these defines:
#define _COMMON_ANODE_
//#define _COMMON_CATHODE_

The only user interface on the shield is the pair of buttons. Pressing the left one will increment the hours, the right one will increment the minutes, while the seconds are always reset.
By pressing both buttons at once, the display mode cycles through Mondrian mode (red hours, green minutes, orange seconds), 24-hour mode (HH:MM in green), 12-hour mode (HH:MM in orange), and moving second red dot (12-hour, HH:MM in green, more square font).

Display Abstraction Layer

"Software never dies", the saying goes. But to help that happen, the software should be as independent as possible from the hardware it uses. Today, we are getting closer to this goal by introducing the Display Abstraction Layer (DAL), a simple framework that allows displaying on any suitable device. The implementation is based on polymorphism: using a virtual class when writing to the display, but instantiating a concrete display class depending on the device being written to. Each device requires its own concrete class that implements a set of functions (defined in the virtual class) used for outputting to the display. Thus every concrete display class becomes a simple “device driver” for the specific display device that was written for.

A class diagram of the DAL framework is shown below.

This is nothing revolutionary, just a simple solution that should have been there (in projects using displays) from the beginning. It provides an easy adaptation between the project functionality and the display, and also reduces the porting effort to just implementing a class for the new display.

The DAL interface consists of a set of function definitions used to output to the display. This set of functions depends on the project. That means that the DAL interface for WiFiChron will be different from the one for WiseClock. For example, in the case of WiFiChron, there are only 4 functions dealing with the display that need to be implemented:

    void setup();

    void writeDisplay (char* displayBuffer);

    void setBrightness(uint8_t brightness);

    void reset();

WiseClock uses a lot more display functions (currently defined in HT1632.h):

  void setup();

  void clear();

  void setBrightness(byte level);

  void snapshot_shadowram();

  byte get_snapshotram   (coord_t x, int8_t y);

  byte get_shadowram     (coord_t x, int8_t y);

  void clearSnapshot     ();

  void clearSnapshot     (int8_t dispNo = 0);

  void copyToVideo       (byte chipNo, char* vbuffer);

  void overlayWithSnapshotHorizontal(int8_t y);

  void overlayWithSnapshotVertical  (coord_t x);

  void plot         (coord_t x, int8_t y, byte color);

  void line         (coord_t x1, int8_t y1, coord_t x2, int8_t y2, byte val);

  void putChar      (coord_t x, int8_t y, char c, byte color);

  void putTinyChar  (coord_t x, int8_t y, char c, byte color);

  coord_t       putLargeChar (coord_t x, int8_t y, char c, byte color);

  void putBigDigit  (coord_t x, int8_t y, int8_t digit, int8_t fontNbr, byte color, int8_t columns);

  void putFullDigit (coord_t x, int8_t y, uint8_t digit, byte color, byte fontNumber=0);

  void putBitmap    (coord_t x, int8_t y, byte indexBmp, byte color=ORANGE);

  void putString    (coord_t x, int8_t y, const char* str, byte color);

  void putTinyString(coord_t x, int8_t y, const char* str, byte color);

  void displayStaticLine  (char* text, int8_t y, byte color);

  void displayStaticLine_P(const char* text, int8_t y, byte color);

Currently, I have implemented and tested a bunch of DAL classes for HDSPwise clock (the simpler version of WiFiChron). These include support for HDSP2534, DL1414, OLED (128x64). The common characteristic of these displays, that makes them suitable for the HDSP clock/WiFiChron, is that all of them can display 8 characters that can then be scrolled horizontally.

DAL for WiseClock would require implementing the above functions for a graphic display with a resolution of at least 32x16 pixels. Also, this graphic display should need no more than 4 control wires (hardware limitation of WiseClock4 board). So, if you wish to replace the 3216 display (not available from Sure Electronics anymore), a suitable candidate would be a TV (through the TV pixel library) or even an 128x64 I2C OLED. Keep in mind that controlling the 16x32 LED displays that use shift registers (either monochrome or RGB) requires more than 4 wires. Their support by Wise Clock 4 would need hardware changes, probably the insertion of a controller (e.g. HT1632, HT16K33 etc).