Posts with «wise clock 4» label

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

"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();
}



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.

Animation on Wise Clock 3/4

Mr Ruud did it again :)  He took this video showing a few more features he added.



1. ANIMATIONS
It is now possible to create your own animations which are stored on the SD card.
The APPS menu entry ANIM allows for continously showing one or all animations files.
Animation files are named: anim0.wc3 - anim9.wc3
There are also 4 special animation files named: time00.wc3, time15.wc3, time30.wc3 and time45.wc3
If ANIM+ is selected in the SETUP menu and the BIG mode is active then every quarter the correponding animation is shown once with a random speed. 
Besides the four time*.wc3 animation file, there are currently 4 sample animations: anim1.wc3 - anim4.wc3.

You may create your own animations (there is NO programming involved) by creating individual screens in Excel and then use a small conversion program to create the *.wc3 file. 
As the animations are stored on the SD card you can make them as big as you like.

2. LOGGING
If the LOG+ menu is selected in the SETUP menu then the following items will be logged in the wc3log.csv file:
  • every hour the current temperature is logged both in Celsius and Fahrenheit (32.5 degrees is stored as 325)
  • all entries created in the time clock (TCLOK) app are now stored in the log file

The wc3log.csv file is an ASCII Comma Separated Values file, which can be opened in Excel for further analysis (or for creating graphs etc).

The average log record is about 25 bytes long. The temperature logging will take 24 x 25 bytes =  600 per day. (So the 2 Megabyte log file will be full after about 9 years.)
A warning message ("log= @ End") will be shown when the log file is almost full, an error message ("log= FULL!") will appear if no more records can be written to the log file.

The SETUP menu entry CLRLG allows for clearing the complete log file, it will take about 10 minutes to clear a 2 megabyte log file.

Mike integrated all of the above changes with a previous version that works with FAT32. This code is still under testing and it will become available soon.


Wise Clock 4 with remote "Alarm stop" button

The Ramos project brought the novel idea of a wireless alarm-stop button: instead of just reaching out to the press on the top of your nightstand alarm clock, you now have to actually get out of the bed and walk to a remote corner of your dwelling to click on a keypad. No chance you will return to sleep afterward :)

This remote alarm-stop feature for Wise Clock 4 can be implemented in several different ways, all of them using of the on-board XBee socket:
  • through a Bluetooth module;
  • through WiFi, using the Roving Networks WiFly module;
  • through XBee radios.
The cheapest and easiest would be the Bluetooth solution, providing that you already have a BT device (e.g. Android phone/tablet) to communicate with. In pseudo-code, it should look like this:

if (alarm is ON)
{
    while (Serial1.available())
    {
       read characters received;
       if (it is the expected string)
       {
            set alarm OFF;
        }
    }
}

The WiFi solution would require a second WiFi device (phone/tablet) to access a web site, or maybe they could talk directly (sockets), using their IP addresses.

The solution based on XBee relies on direct communication between two XBee radios. One would have to build the remote device, probably around an Arduino, with a keypad and an XBee.

Wise Clock 4 with remote "Alarm stop" button

The Ramos project brought the novel idea of a wireless alarm-stop button: instead of just reaching out to the press on the top of your nightstand alarm clock, you now have to actually get out of the bed and walk to a remote corner of your dwelling to click on a keypad. No chance you will return to sleep afterward :)

This remote alarm-stop feature for Wise Clock 4 can be implemented in several different ways, all of them using of the on-board XBee socket:
  • through a Bluetooth module;
  • through WiFi, using the Roving Networks WiFly module;
  • through XBee radios.
The cheapest and easiest would be the Bluetooth solution, providing that you already have a BT device (e.g. Android phone/tablet) to communicate with. In pseudo-code, it should look like this:

if (alarm is ON)
{
    while (Serial1.available())
    {
       read characters received;
       if (it is the expected string)
       {
            set alarm OFF;
        }
    }
}

The WiFi solution would require a second WiFi device (phone/tablet) to access a web site, or maybe they could talk directly (sockets), using their IP addresses.

The solution based on XBee relies on direct communication between two XBee radios. One would have to build the remote device, probably around an Arduino, with a keypad and an XBee.


Guest post: Wise Clock 3/4 Apr-2012 software release

Here is the email I received from Mike, who took on the challenge to fix and improve the code for Wise Clock 3/4, available here. Thanks Mike, keep up the great work!

My note: If you don't feel very confident about upgrading the software on Wise Clock 3/4, please do not do it.

I combined WiseClock3/WiseClock4 into one distribution, creating a WiseClockVer.h file with a
   #define _WISE_CLOCK_VER 3
line.  HT1632.cpp and Buttons.h include WiseClockVer.h, and use lines like
  #if _WISE_CLOCK_VER > 3
  #define HT1632_CLK      15      // clock pin (pin 2 of display connector)
  #else
  #define HT1632_CLK      11      // clock pin (pin 2 of display connector)
  #endif
That way the same distribution can be used for Wise Clock 3 or Wise Clock 4, and only one line has to be changed.

I found some places where over 100 bytes of data are copied into msgLine, overflowing the buffer.  Rather than just increasing the size of QUO_MSG_LEN, I changed all references to QUO_MSG_LEN to use MAX_MSG_LEN instead.

When reading a quote line a prefix character of Control-R (^R) will display the quote in red.  A prefix character of Control-O (^O) will display the quote in orange.

I removed all floating-point operations in favor of scaled integers.  For AppPong I scaled by 256, for temperature I scaled by 4 as the DS3231 is only accurate to 0.25 degrees.  I found that when the high and low temperatures were scaled by 10 and displaying farenheit that today's high could be 0.1 degree lower than the current temperature due to round-off errors.  These errors are avoided by saving the temperature scaled by 4 instead of 10.

I added a DST flag to indicate Daylight Savings Time is in affect.  DST+ sets the flag and advances the hour by one, DST- clears the flag and retards the hour by one.  The DST settings in the message file are still honored, setting the flag and incrementing the hour (if the DST flag is clear) or clearing the flag and decrementing the hour (if the DST flag is set) at the appropriate time.
The DST flag is used in the UTC code so the UTC offset is set once.  There is no need to change the UTC offset when Daylight Savings Time starts or ends.

I changed the sign of the UTC offset, so '-5' is now correct for Eastern Standard Time.  UTC + offset = current time.
Negative UTC offsets could not be restored properly, as -5 when retrieved would come back unsigned as 250.  I worked around the problem by adding 24 when saving to EEPROM and subtracting 24 when reading the EEPROM.

I changed the resolution of AppTimeLived's makeTime() from seconds to minutes.  The displayed seconds are calculated by taking the delta of the current second specified birth second, so makeTime() does not need the extra accuracy.  This change allows the offset to be calculated from 1900 instead of 1950.  With a second resolution and base of 1950 makeTime() would wrap in 2018.  With a minute resolution and a base of 1900 makeTime() won't wrap for another ~4000 years.

I changed the DEMO mode so it cycles through several display modes.  The number of minutes to display each mode is selected on the first screen after DEMO is selected, going from 0 minutes to 9 minutes.  Ten seconds is added to the cycle time, so selecting "0" goes to a new display every ten seconds.
The original lines Demo is only displayed for ten seconds, regardless of the selected cycle time.  The LIFE demo is displayed for fifteen seconds.
I was going to have AppWords as one of the demos, but I'd have to in-line most of AppWords' initialization code in the demo code, so I didn't bother.

I changed AppLife so it now wraps over the edges of the display.

I went through AppPong so all display offsets are relative to X_MAX and Y_MAX. As mentioned earlier, floating point math was replaced by scaled integers.  The height of the bat is now a #define and set to 5 instead of the previous version's hard-coded 6.  I settled on a color scheme -- ball and pitch are green, score is red, bats are orange.  I fixed some bugs in the ball prediction code and the 'flip' code (used to put 'english' on the ball).  I changed the 'miss' code to only miss by a few pixels.

The removal of the floating point freed up a lot of space.
It's [the whole sketch] less than 58K bytes.

I'm running the clock now.  The only issue is the year's high temperature needs to be re-initialized.  It was scaled by 10, now we expect it to be scaled by 4.  The nightly comparison won't save a new high temperature because the old one now is 2.5 times higher than it should be.  New clocks won't have the problem, but upgrading an existing one will.  The yearly low temperature isn't a problem because the scaled-by-four temp will be lower than the scaled-by-ten temp (unless your low is less than 0 C).  The work-around is easy, just set the year back by one overnight.  In the morning the yearly high/low temp will be reset.  The yearly high/low is only displayed in the "STATS" app anyway.



I corrected the life neighbor calculations.  The neighbor calculation used to be the sum of the colors for the eight neighbors.  This works when only green (1) is used, but when the colors are randomized the neighbor calculations are wrong, as some neighbors could be red (2) or orange (3).  I changed the color selection to use green for birth, orange for steady-state, red for dead.  The neighbor calculation now looks at the least significant bit of the color.  Green and Orange both have the lsb set, so this works well.

A quote-line can now be any length.  The quote buffer is replenished when processing is within 24 characters from the end of the buffer and the line was truncated.  Additional characters are tacked on to the end of the remaining 24, with no interruption.  This will repeat until the entire line has been processed, no matter how long the line is.  Reminders and Messages are still limited to 100 characters, and the lines in the Words files are still limited to 175 characters.

Guest post: Wise Clock 3/4 Apr-2012 software release

Here is the email I received from Mike, who took on the challenge to fix and improve the code for Wise Clock 3/4, available here. Thanks Mike, keep up the great work!

My note: If you don't feel very confident about upgrading the software on Wise Clock 3/4, please do not do it.

I combined WiseClock3/WiseClock4 into one distribution, creating a WiseClockVer.h file with a
   #define _WISE_CLOCK_VER 3
line.  HT1632.cpp and Buttons.h include WiseClockVer.h, and use lines like
  #if _WISE_CLOCK_VER > 3
  #define HT1632_CLK      15      // clock pin (pin 2 of display connector)
  #else
  #define HT1632_CLK      11      // clock pin (pin 2 of display connector)
  #endif
That way the same distribution can be used for Wise Clock 3 or Wise Clock 4, and only one line has to be changed.

I found some places where over 100 bytes of data are copied into msgLine, overflowing the buffer.  Rather than just increasing the size of QUO_MSG_LEN, I changed all references to QUO_MSG_LEN to use MAX_MSG_LEN instead.

When reading a quote line a prefix character of Control-R (^R) will display the quote in red.  A prefix character of Control-O (^O) will display the quote in orange.

I removed all floating-point operations in favor of scaled integers.  For AppPong I scaled by 256, for temperature I scaled by 4 as the DS3231 is only accurate to 0.25 degrees.  I found that when the high and low temperatures were scaled by 10 and displaying farenheit that today's high could be 0.1 degree lower than the current temperature due to round-off errors.  These errors are avoided by saving the temperature scaled by 4 instead of 10.

I added a DST flag to indicate Daylight Savings Time is in affect.  DST+ sets the flag and advances the hour by one, DST- clears the flag and retards the hour by one.  The DST settings in the message file are still honored, setting the flag and incrementing the hour (if the DST flag is clear) or clearing the flag and decrementing the hour (if the DST flag is set) at the appropriate time.
The DST flag is used in the UTC code so the UTC offset is set once.  There is no need to change the UTC offset when Daylight Savings Time starts or ends.

I changed the sign of the UTC offset, so '-5' is now correct for Eastern Standard Time.  UTC + offset = current time.
Negative UTC offsets could not be restored properly, as -5 when retrieved would come back unsigned as 250.  I worked around the problem by adding 24 when saving to EEPROM and subtracting 24 when reading the EEPROM.

I changed the resolution of AppTimeLived's makeTime() from seconds to minutes.  The displayed seconds are calculated by taking the delta of the current second specified birth second, so makeTime() does not need the extra accuracy.  This change allows the offset to be calculated from 1900 instead of 1950.  With a second resolution and base of 1950 makeTime() would wrap in 2018.  With a minute resolution and a base of 1900 makeTime() won't wrap for another ~4000 years.

I changed the DEMO mode so it cycles through several display modes.  The number of minutes to display each mode is selected on the first screen after DEMO is selected, going from 0 minutes to 9 minutes.  Ten seconds is added to the cycle time, so selecting "0" goes to a new display every ten seconds.
The original lines Demo is only displayed for ten seconds, regardless of the selected cycle time.  The LIFE demo is displayed for fifteen seconds.
I was going to have AppWords as one of the demos, but I'd have to in-line most of AppWords' initialization code in the demo code, so I didn't bother.

I changed AppLife so it now wraps over the edges of the display.

I went through AppPong so all display offsets are relative to X_MAX and Y_MAX. As mentioned earlier, floating point math was replaced by scaled integers.  The height of the bat is now a #define and set to 5 instead of the previous version's hard-coded 6.  I settled on a color scheme -- ball and pitch are green, score is red, bats are orange.  I fixed some bugs in the ball prediction code and the 'flip' code (used to put 'english' on the ball).  I changed the 'miss' code to only miss by a few pixels.

The removal of the floating point freed up a lot of space.
It's [the whole sketch] less than 58K bytes.

I'm running the clock now.  The only issue is the year's high temperature needs to be re-initialized.  It was scaled by 10, now we expect it to be scaled by 4.  The nightly comparison won't save a new high temperature because the old one now is 2.5 times higher than it should be.  New clocks won't have the problem, but upgrading an existing one will.  The yearly low temperature isn't a problem because the scaled-by-four temp will be lower than the scaled-by-ten temp (unless your low is less than 0 C).  The work-around is easy, just set the year back by one overnight.  In the morning the yearly high/low temp will be reset.  The yearly high/low is only displayed in the "STATS" app anyway.



I corrected the life neighbor calculations.  The neighbor calculation used to be the sum of the colors for the eight neighbors.  This works when only green (1) is used, but when the colors are randomized the neighbor calculations are wrong, as some neighbors could be red (2) or orange (3).  I changed the color selection to use green for birth, orange for steady-state, red for dead.  The neighbor calculation now looks at the least significant bit of the color.  Green and Orange both have the lsb set, so this works well.

A quote-line can now be any length.  The quote buffer is replenished when processing is within 24 characters from the end of the buffer and the line was truncated.  Additional characters are tacked on to the end of the remaining 24, with no interruption.  This will repeat until the entire line has been processed, no matter how long the line is.  Reminders and Messages are still limited to 100 characters, and the lines in the Words files are still limited to 175 characters.


Scrolling message sign with Bluetooth

A simple application for Bluetooth was suggested a while back by fellow arduinoer evanrich (who also created a home for his project on github): a scrolling sign using several cascaded 3216 displays and controlled through Bluetooth from an Android phone. His intention was to use it as a wireless sign that can be put in the back of the car to tell drivers to get off his tail.

I gave it a try myself, using Wise Clock 4 with Bluetooth and two 3216 displays, as shown in this photo (the blue LED on the BTBee is power, the orange one is communication status).


















The code is a modified version of the one posted here.

This message sign, especially if it is made with the larger (5mm) 3216 displays, can be also used in waiting rooms, call centers, stores etc, to show dynamic and easily-changeable messages.


Related posts:


Scrolling message sign with Bluetooth

A simple application for Bluetooth was suggested a while back by fellow arduinoer evanrich (who also created a home for his project on github): a scrolling sign using several cascaded 3216 displays and controlled through Bluetooth from an Android phone. His intention was to use it as a wireless sign that can be put in the back of the car to tell drivers to get off his tail.

I gave it a try myself, using Wise Clock 4 with Bluetooth and two 3216 displays, as shown in this photo (the blue LED on the BTBee is power, the orange one is communication status).


















The code is a modified version of the one posted here.

This message sign, especially if it is made with the larger (5mm) 3216 displays, can be also used in waiting rooms, call centers, stores etc, to show dynamic and easily-changeable messages.


Related posts: