Friday, December 2, 2011

Buy Complete Wise Clock 4 kit - includes display and enclosure

Update July 7, 2015
Before you buy, please read this post on assembling the Wise Clock 4 with the new display.

When you buy the "Complete Wise Clock 4 kit", on top of the Wise Clock 4 kit you get the 3216 bi-color (red/green/orange) LED display from Sure Electronics, plus the enclosure, consisting of two laser-cut transparent acrylic plates and the required hardware (standoffs, screws etc) to assemble it.

  US$125 US$115 - free shipping to North America

The "complete kit" comes with everything you need to build a functional Wise Clock 4. You will need to add your own FAT16/FAT32-formatted SD card (with the necessary files on it), the miniB USB power cable and, eventually, an BTBee module (if you want Wise Clock 4 to display messages sent from your Android device).

The assembly guide, written by StefanK, can be found here.


  1. I just got by Wise Clock 4 and I thought I'd share since I've written a new clock for it. Probably boring for most of you though. This is an alarm clock for my toddler who can't tell time (of course). It uses colors to tell him when he should be sleeping and when he should get up.

    I didn't need to, but I wrote all the code so its self contained including setting multiple alarms, setting the time, and turning the audio on and off.

    1. What are the differences between the Wise Clock 3 and 4? Why would someone want 4 over 3 or the other way around? Thanks.

    2. Very Cool - do you have your code in a repo somewhere that we can play with?

    3. Chris,
      Please take a look at this post:
      It also has a link to the source code. For some reason, google code says "deprecated", but it's not.

  2. This is great! Definitely not boring.
    Should be in its own (guest) post. Let me know if you want to write a short presentation of the features, eventually publish the code.

  3. Hi Florin,

    As a Wise Clock 3 owner, I would like to know if it is possible to only buy the Wise Clock 4 board because I already own the rest of the hardware.

    1. The board has all SMDs soldered on it, so it's not really "only the board". PM me and we'll work out the details.

  4. 1. Are the LED driven in a dimmable fashion?
    2. Any code for getting the time via some wireless method?

    1. Dwight,
      1. The LEDs are driven by LED driver chip HT1632. The display board itself, built by Sure Electronics, has 4 such chips.
      Yes, the current software allows 5 levels of brightness for the display, user-selectable through a button.
      2. Yes, either though GPS, as shown here ( or through WiFi (in the code already, but not explained in any post yet).
      I hope this helps.

  5. Is the lowest level of brightness set where it doesn't light up the room at night? I see that the board allows for 16 levels of brightness, so the the code should be tweakable fairly easy...

    The GPS option looks great!

    1. The display allows for 16 levels of brightness, but the difference between adjacent levels are almost imperceptible, so I decided to have only 5 steps (every button push increases the level by 3). That can be modified, of course.
      The GPS option adds about $40 to the cost, with no obvious benefit, considering that the RTC in itself is extremely accurate (+/- 2 minutes per year).

    2. At the dimmest level does it light up the room at night?

    3. Not lighting up the room, but it can definitely be seen clearly. After all, these are LEDs :)

  6. Another question, does the clock auto-dim based an ambient light or time of day? Seems like that would be useful.

    1. Currently, the kit does not include a photo-resistor (nor a place holder for it) for automatic dimming. One customer added that though, see this post:

  7. Well, parts arrived, assembled and working :-) Many thanks.

    However, I've not got the WiFi working yes, so I need to debug. Although I'm a software developer, I've not used Arduino before ... so I would like to check how things work. I presume I need to :-

    1) Install the Arduino SDK ( )
    2) Add in Sanguino ( )
    3) Download source zip ( ) and extract
    4) Open TheClock.ino, select board Sanguino ATmega1284p and compile

    In fact doing this I get "Binary sketch size: 71,408 bytes (of a 129,024 byte maximum)" which I think is a good sign.

    5) Get a FTDI cable and connect to the clock
    6) Upload the binary and use the serial port monitor for debugging

    Is this about it ? Anything to watch out for ? I see there are 3.3V and 5V cables, which one do I need ? Is it okay to power the clock via USB and use the serial port at the same time ? Is this fairly safe ... ie I'm not going to brick it ?

    But looking at the source I see WANT_WIFLY is disabled so that will be the first start :-)

    Many thanks,


  8. Pete,
    You got everything right (steps 1-6).
    I use the 5V FTDI breakout to upload, debug and power the clock (from USB).
    "Bricking" would mean disabling or overwriting the bootloader somehow. That never happened to me.

    The easiest way to get WiFi for Wise Clock 4 is to use the WiFly module from Roving Networks ($35, Sparkfun). Then, you need to un-comment WANT_WIFLY, as you noted.

    Similarly, you could use the newer and cheaper ESP8266, which also talks to the processor on serial (and also powered by 3V3).

    I have a few posts on WiFly, search my blog for "wifly".


  9. Well, I have a RN-XV module from Roving Networks and a serial cable.

    After enabling debug, I found the code no-longer compiles. The fix appears to be to update AppUtc.cpp to :-

    #ifdef _DEBUG_
    Serial.print("Saved UTC difference: ");
    Serial.println(wiseClock.utcDiff); // was just utcDiff

    I see a log of junk data coming from the WiFly card such as :-

    .4 xi

    I'm not sure whats causing this ... but eventually the right response does come back buried in the junk and so the WiFi state machine progresses.

    I also found a problem substituting $ for space for the wifi phrase ... looks like a cut & paste error ... the ssid is checked not the phrase. So the code should be :-

    // replace any blanks in the phrase with '$' -- WiFly module converts it back
    for (s = phrase; *s != 0; s++) { // was ssid
    if (*s == ' ')
    *s = '$';
    doWep = false;

    With these two changes I get connected to the network and I can telnet to port 2000. However, the clock isn't being synced because of the apparent junk being returned over the serial port.

    Any ideas what could be the cause of the just data coming back ?



    1. Hi Pete,
      Thanks for the bug fixes.
      I haven't touched the WiFly code in a long while now and I don't remember much.
      I will take a look in the following days, I hope.
      But you seem to be better at finding solutions to this :)
      Keep up the great work!
      Happy New Year!

    2. I looked (visually) at the WiFly code (which I did not write).
      It seems to require a NTP server IP address (in message.txt file). First check is to make sure that the NTP is valid and active.
      I have a "Time" library downloaded from some place (not sure where), that has a TimeNTP.pde sample sketch. It enumerates these NTP servers:

      byte SNTP_server_IP[] = { 192, 43, 244, 18}; //
      //byte SNTP_server_IP[] = { 130,149,17,21}; //
      //byte SNTP_server_IP[] = { 192,53,103,108}; //

      So, I would think that first we need to make sure we get correct data from an active NTP server. Maybe it is easier to perform the test with the sample TimeNTP sketch.

      (I also realized that I lent my WiFly to a friend.)

  10. I think the issue I'm seeing is the serial link between the ATmega and the RN-XV ... I've tried various software uart settings, but I'm now wondering if there is a hardware issue.

    1. I think that being able to connect to WiFi network (passing ssid, password etc) proves that the serial communication on the second UART works.

      What exactly is not working? Do you get runtime errors/ timeouts?

    2. It looks like sending data to the Wifly works but receiving data is garbled.

    3. Could it be the WiFly module itself?
      You could try a simple sketch that only sends and receives.
      Also, keep in mind that any response longer than 2K is truncated/lost, since the WiFly's RAM buffer is only 2K.

  11. Thanks for the tip - a separate sketch works fine - data from the the WiFly is not corrupted.

    But, I think I see the issue. WiseClock::checkSerial() is reading from the WiFly ( to get any messages to display ) at the same time as CWiFly::check() is also reading. So CWiFly::check is only getting around 1/2 the characters. If I simply comment out the reading of Serial1 in WiseClock::checkSerial() then I see un-corrupted responses from the WiFly in command mode.

    I'll see if there is a way to better synchronise these two readers tomorrow. But also, there is a conflict if USE_SOFTWARE_SERIAL is set ( WiseClock.cpp uses this but WiFly.cpp doesn't ).

    BTW - is a source repository available somewhere (read only ) ? It might be easier to email you diffs against the latest.

    Many thanks for your time,


    1. From what I remember, USE_SOFTWARE_SERIAL was defined for the JY-MCU Bluetooth module that connects to 2 digital pins and uses SoftwareSerial library. It should not interfere with the use of UART2 (second hardware serial port).

      I don't have a github repository yet, but I will create one soon, I hope.
      But if you send me the modified files, I could merge the changes into my code (I also have other changes from the code you are working on).

    2. I really appreciate your help and your contribution. At this point of complexity, I think it takes a great mind to understand how things work and to be able to fix bugs.
      I thank you!

  12. This appears to work ...

    In WiFly.h, add in public flag :-

    boolean cmdMode; // using command mode

    In WiFly.cpp, initial the flag to false in CWiFly::configInit() :-

    cmdMode = false;

    In CWiFly::check(), only read from serial if cmdMode is true :-

    if (wiFly.cmdMode == true) {

    while(Serial1.available() > 0) {

    if (timerActive) {

    Set cmdMode to false on receipt of EXIT :-

    if (confMatch(msgBuf, PSTR("EXIT"), 4, 0, 0)) {
    if (msgBuf[4] == 0) {
    cmdActive = false;
    cmdMode = false;

    set cmdMode to true before entering command mode :-

    case WIFLY_CMD_START: // switch to command mode
    cmdMode = true;

    In WiseClock.cpp, only read from serial1 if commandMode is false :-

    void WiseClock::checkSerial()
    #ifdef SERIAL_MSG
    char c;

    #ifdef _WiFly_H_
    if (wiFly.cmdMode == false) {
    #ifdef _WiFly_H_

    #ifdef _WiFly_H_

    With this I can get both the WiFi settings okay ( with no garbled responses ) and can set the message by telneting to port 2000.

    Feels like it needs a android app to manage the clock :-)



    1. I'm not convinced this is the best way ... in my tree I've now done it the other way around - ie disable reading of the messages over wifi in WiseClock.cpp and keep it in WiFly.cpp.

  13. One annoyance is the bright LED's on the WiFi board ... however these can be disabled. Maybe in WiFly.cpp :-

    print_P(PSTR("set sys printlvl 0\r")); // disable verbose messages
    #ifdef WiFly_DBG
    print_P(PSTR("set sys mask 0x2100 1\r")); // disable LED's

    1. Good stuff, thanks.
      A cheaper alternative to WiFly is ESP8266 (less than $5), but the code is a little different, I think.

      An alternative I have been contemplating is something I named "WiseDock", a RPi device (with WiFi) that streams out the results of processing http responses on BT. Since Wise Clock is already able to display messages from BT, no code changes would be required.

  14. I wanted to read the date as well as the time from WiFly module ... however this appears to have a bug.

    Running "show t t" you get the time as well as the UNIX timestamp - although the time is shown with a timezone offset.

    A good example is :-

    show t t
    UpTime=14267 s

    The timestamp 1420322240 is Sat, 03 Jan 2015 21:57:20 GMT.

    However I sometimes see something like :-

    show t t
    UpTime=8528 s

    1420316996 is Sat, 03 Jan 2015 20:29:56 GMT ... so 100 seconds out.

    I've reported this to microchip.

  15. Here is my clock.
    I use the microcontroller atmega1284p. I added a MIDI board to play simple melodies. I also installed the WiFly module to adjust the current time and display forecasts.