User interaction when connecting WiFi devices to network

I spent some time recently analyzing methods for passing the WiFi parameters (network name and password) to a device, in user-friendly manner and on the cheap (that is, by using minimum extra hardware).

This challenge (of selecting the WiFi and entering the network password) was already solved in many different ways, from using the remote control to select characters displayed on the TV screen (as done by Apple TV, XBox etc), to creating an ad-hoc WiFi network (as done by WiFi thermostats, Twine and others).

The bottom line is that every WiFi device must somehow present the users with an interface that allows them to type in the network password. How this is solved determines the user-friendliness of the device and influences the final cost of the product as well.

Here are the methods I found so far. I am sure this list will be extended and improved with details, hopefully also based on the readers' comments and feedback.

1. SD card that includes a text file with network name and password
The user edits the text file on any computer. The SD card is then transferred onto the device. After the device is powered, the settings are stored internally and the SD card can be permanently removed. 
Pros:
- user-friendly and almost fool-proof;
- easy to implement in software;
- SD card may be also used for storing other data (backup in case of network disconnect, power outage etc);
Cons:
- need access to a PC (any text editor would work);
- adds about $6 to the total cost of the device (SD socket, SD card);
- device may need to be shipped with a an SD card USB adapter (adds another $2).

2. Bluetooth – The user interface is provided by a smart phones that communicates with the device through Bluetooth.
Pros:
- very user-friendly user interface through the smart phone app (e.g. Android), that uses a full keyboard and a complete feedback (similar to text editor);
- easy to develop the software for Bluetooth communication for the device;
Cons:
- adds $5 to the cost of the device (BT module);
- a simple application (e.g. BlueTerminal) needs to be downloaded by the user on the smart phone;
- may not work with iPhone, which requires Apple-licensed BT modules.

3. Using QR code that ships with the device - patented, licence-able technology; to investigate further (price, complexity etc.);

Pros:
- (maybe) user friendly, with minimal user interaction: smart phone app leads to a web site that requires the user to input the password;
Cons:
- pay royalties;
- need smart phone with camera and software app for QR codes.

4. Creating a temporary ad-hoc Wifi network (as used by some smart WiFi enabled thermostats)
Pros:
- easy to use web interface;
Cons:
- need a computer that can connect to the existing WiFi;
- requires development of the web site (for inputting the password);
- requires a way to switch the device between the setup mode and regular operation (when already connected to the WiFi). (Note: The above mentioned Twine uses an accelerometer chip for this purpose.)

5. Include an LCD screen with touch sensor or buttons (as in Nest).

Pros:
- all inclusive solution, no other equipment required to interface with the user;
Cons:
- adds to the final cost (at least $4);
- may be cumbersome to use, since the display is quite limited in space;
- makes the device bigger;
- software to handle the user interaction can be quite complicated (for such a simple task);
- waste of resources, since the LCD screen and buttons/touch may be used only for this purpose (user input).

6. Use a wired (custom, non-PC) input terminal, with screen and keyboard, that communicates on serial (RS232, RS485, TTL) interface with the device.

Pros:
- simpler software (processing the commands received on the serial interface);
- does not require extra hardware on the device itself;
Cons:
- need to provide the terminal hardware as well (OK solution when the device installation is done by a trained person).

7. Use an infrared (TV, VCR, stereo etc) remote control
Pros:
- ubiquitous, everybody is guaranteed to have one around;
- software is relatively easy to develop;
Cons:
- user interface not friendly; it would require some user feedback (display);

8. NFC (Near Field Communication) - to be researched
Pros:
- friendly user interface through the smart phone;
Cons:
- requires a smart phone;
- need to develop app for smart phone.



9. Direct connection to PC through USB/FTDI cable - as done by the readiymate board
Pros:
- the simplest to implement method: the board's microcontroller listens to and interprets the serial commands from PC;
- change the network name and password through either the serial monitor (command mode style) or through a GUI app that translates button clicks into serial commands;
Cons:
- requires on board FTDI chip (adds about $5 to the board's cost);
- requires development of the PC (GUI) app that talks to the board;
- also requires the user to download and install the app on the PC.

Raspberry Pi AlaMode

The great team of Wyolum announced that their Raspberry Pi AlaMode is available for pre-order.
This board, shown in the photo below, is Wyolum's answer to interfacing any number of hardware shields, sensors and servos to the Raspberry Pi.


AlaMode is an Arduino compatible board that plugs right on top of the Raspberry Pi computer. It also gives you:

• extremely accurate real time clock DS3231 with backup battery
• micro SD slot
• direct headers for plugging in servos
• safe voltage translation between the Raspberry Pi and Arduino.

Stock ticker with Wise Clock 4 and WiFly

I should have titled this "Adventures in WiFly land - Part 2", a continuation of this post, but really there was no adventure. Things worked smoothly from the start. The main "challenge" was parsing the http response on the fly, since the (truncated) response string itself is about 1500 bytes (3/4 of the RAM in a 328), which is the size of WiFly's receiving buffer.



The code (download from here) performs these steps:

• send http request to yahoo site, specifying the stock symbol;
• read the http response and find the token that identifies the stock price, in this case "last:";
• read the next few characters that represent the stock price;
• display the symbol and the price on the 3216 display.

This crude version is based on the WiFly_WebClient sample code from sparkfun. For display, it uses the HT1632 (header and c) files that are part of Wise Clock 4 library (but also supplied in the zip file). The software should work with any Arduino connected to a serial WiFly and a 3216 display from Sure Electronics.

The plan is to integrate this code as a new application in the Wise Clock 4 software. Stock symbols should be user-configurable and read from the SD card (as opposed to being hardcoded as they are now).
Also, the direction of the stock move, read from the http response as well (after the token "change"), could be shown in red for "down" and in green for "up".

Post data to cosm.com with WiseClock4 + WiFly

Last weekend I re-discovered cosm.com, formerly known as pachube.com.
After spending a lot less time than I had planned (since things went so smoothly), I was about to post details about the experience; then I saw this fresh post on sparkfun, which pretty much explains everything one needs to know about creating an account and sending data.

The main difference between sparkfun's setup and mine is the connection to internet: I used the WiFly module plugged into the WiseClock4 board. Therefore, the code is a little bit different too: I used the great WiFly library, which even comes with a (little dated) "pachube client" example. All one needs to do is provide the right parameters (app key, network ssid, password etc) in credentials.h, then change all references from "pachube" to "cosm".

As a quick experiment, I read the value from (disconnected) A0 every 25 seconds, and this is how the cosm graph looks like:

A user-friendly cosm-client device based on WiseClock4 with WiFly (which, by the way, seems to be the cheapest way to connect to a WiFi network) would read the configuration parameters from a file on SD card (then, for security reasons, delete the file and store those parameters in eeprom) or provide a way to receive these parameters (ssid, password, app key etc) from a smart phone through bluetooth.

(To be continued)

From customer email

Just wanted to let you know I finished putting together my Wise Clock 4 and it looks and works great!  Only took me about 6 months to get started it J.  Thanks for putting together such a nice kit.  I didn’t install an xbee on it yet but hope to experiment with that sometime this year.   I really like all the different modes – and have to read up on what they all do.  Is there a good link you can point me to that describes them?  Hope you are still working on new clock ideas.  Think I saw your name as a supporter of the word clock out on kickstarter?

Bill

On the 3216 LED display from Sure Electronics:

I did look at the clocking relationships on the scope.
The clock to data hold timing on the HC164 was marginal, 2ns, versus -2ns typical and 4ns minimum. Meaning it will probably work, but it's not certain. CLK, DATA and WR are buffered through 2 sections of an HC04, with a delay of 11ns, but CS_OUT is not, so with every successive board in a chain this timing degrades. They ran out of HC04 gates. Installing the 10pf capacitor at C1 might help, but it's not ideal.

Don

The zip file did the trick. I now have them both up and running. 

I've attached a pic for your viewing.

Brian

Just wanted to let you know that I received my kit yesterday and have already put it together.  I was surprised, having not done any soldering in a long time, that it went together easily and worked on the first try!

Michael

Big Thank YOU guys!

Wise Clock 4 - Status update

It's been a slow (and hot, temperature-wise) summer, spent mostly answering customer (and other Arduino fellows asking for help) emails, with almost no notable achievements.

• Improved the design of the Wise Clock 4+ board by adding support for the JY-MCU bluetooth module connected as shown in the next photo (and controlled using the SoftwareSerial library on pins D20 and D21).

• Created the software framework for a Scheduler (subject of a future post); this should support features like multiple alarms, job activation at given times etc.
• Beside his great contribution to the code, MikeM found a fix for the SoftwareSerial bug on ATmega1284P (D20 and D21 did not work because JTAG is enabled); he also sent this photo of his stack of Wise Clock 4s with dual 5mm LED displays.

• Added to my to-do list:
• Android app to remote-control Wise Clock 4;
• remote sensors to start and stop the chronometer function of the clock (request from Javier);
• join a WiFi network in a user-friendly, easy-to-configure, manner;
• automatic adjustment of the display brightness with an LDR, as suggested by Adam, who already hacked his Wise Clock 4, as shown below.

I also got a bit upset with Sure Electronics for the (mechanical) change on their latest revision of the 3216 LED display: the vertical distance between the holes is about 3mm greater. I thought I would have to give away the small stock of laser-cut plates I had, since they would not fit anymore. Turns out that there is a non-wasteful solution though: enlarge the holes with a small file (which I do myself to all displays, until I finish the old stock of plexiglass plates).

As always, any comments, suggestions and contributions are appreciated.

Wise Clock 4 with the 5mm 3216 LED display

The Wise Clock 4 board was designed to be plugged directly into the 3mm 32x16 LED display from Sure Electronics. I am often asked how it would connect to the 5mm 32x16 LED display.
The photos below will give the answer to this question.

First, the 2x8-pin female header provided with the kit needs to be replaced with a 2x8-pin male header (or two 8-pin male headers side-by-side). Place the header on the top side, as shown in the picture above.
Ideally, a "shrouded 2x8-pin header" (like this) should be used here, since that will also force the ribbon cable connector to be inserted with the right orientation (notice that the peg is closer the FTDI connector).

Then connect the board to the display using the ribbon cable (coming with the display), as shown in the next photo, and very importantly, paying attention to the orientation of the connector.

In case you wanted to chain a second display, just connect, with a second ribbon cable, the OUT connector of the first with the IN connector of the second.

The Wise Clock 4 software is able to correctly handle the second display if you modify this line in file HT1632.h, from

#define NUM_DISPLAYS 1

to

#define NUM_DISPLAYS 2

When fully lit, the current consumption of the displays are around 500mA. The best way to power them, especially when chained, would be through the terminal block, with the the red and black wires (as shown). In this case, the Wise Clock 4 board is powered from the display (through the ribbon cable), so you don't need to use an USB cable.

The easier alternative is to use the USB cable. This will provide power to the display(s) as well, but the voltage to the second display may drop below 5V, thus making it less bright, or even behaving erratically. Also, keep in mind that the USB port on a PC may not be able to supply the current for two displays (1A or so). If you notice problems with the second display, first step is to check the voltage to be around 5V.

NOTE: Make sure you use a 5V regulated power source. Anything above 6V will fry the board, and probably the display too. Also, make sure your power source is adequate for the power consumption. Use at least a 2A (10W) power source.

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 M. integrated all of the above changes with a previous version that works with FAT32. This code is available here.

Wise Clock 4 with integrated Bluetooth

Wise Clock 4 can now hold a Bluetooth module outside of the XBee socket, as shown in the pictures below.

The communication with the BT module uses SoftwareSerial on pins D20/PC4 (Tx) and D21/PC5 (Rx).
The module is powered with 3V3 and the Rx line is level-shifted.

I bought a few of these Bluetooth modules from different sources, mostly ebay. Some of them did not work: my PC's Bluetooth could not "discover" them. Once SMD-soldered to the board, it is very difficult to figure out what's wrong and even de-solder and remove them. My advice for anyone using these modules is to check them before soldering them to any board/breakout. An easy way to do this is to solder wires on pins 12 (Vcc) and pin 13 (ground), as shown in the photo below (left), power with 3.3V, then try to pair it with a Bluetooth host (PC, Android; iPhone won't work since it requires an Apple-approved chip).

The module's relevant pins are shown in the diagram below (photo from ebay seller):

I did not test this myself (the experiment may cost about $7), but it seems that these Bluetooth modules only tolerate approx 3.3V and powering with 5V will fry them.

If you already have an Wise Clock 3/4 and want to add Bluetooth functionality (simultaneous to WiFi or XBee), you can add this module to the clock. Connections are through 4 wires: Rx/Tx go to D20/D21 (pins 26 and 27 of the processor), VCC to 5V, GND to ground. Note that this module has on-board power adapter for 3.3V and level-shifter for the logic lines.

DWex mod

From Gerard:

Hi Florin,
I had some spare time and moved on with the software mods on the DWex.
The mods are:
- display is always on (means you need to power by NiMH or wall supply)
- small animation after reset (test all the LED's)
- small animation at full 5' (solid) minutes
Feel free to distribute/publish the mods if you feel appropriate.
Best Regards
gerard, DL8SEL

The sketch is available for download here.

Thank you Gerard. Keep up the great work!

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

Updated Feb 26, 2018: A good XBee remote control would be the SparkFun Wireless joystick.

Another, much cheaper solution, that does not requires software changes, would use the M4 backpack, as detailed here.

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

Updated Apr 20/2012
David M. mentioned an important detail: if you try to compile with Arduino 1.0 on Mac OSX  you will get the error "You can't have a cpp file with the same name as the sketch". The quick fix is to change the name of the file WiseClock4.ino (to TheClock.ino, for example). Interestingly, although it makes sense, this error does not show in Windows.
-------------------------------------------------------------------

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 display with Wise Clock 3/4
• Scrolling large-font message sign display with Wise Clock 3/4

Wise Clock 4 with Bluetooth

Another thing that was supposed to be easy, but it wasn't: Arduino communicating with Windows XP through Bluetooth.

Like everybody, I purchased the cheap and ubiquitous Bluetooth module from dealextreme.
I soldered it myself on the XBee-footprinted PCB (bare BTBee from IteadStudio), for a total price of about $8 (compare that to at least $15 as these Bluetooth XBees go for).

Without knowing much about Bluetooth, I plugged this new "BTBee" module in Wise Clock 4 expecting it to be "discovered" by XP (which has an USB Bluetooth dongle). Discovered it was: the name "linvor" appeared in the list of BT devices, with two serial ports attached to it.

Communication between XP and BT module is performed through the serial ports, I figured. Tried CoolTermWin, HyperTerminal, Putty, on both ports, nothing seemed to work. Time to read the documentation (which always reminds me of that joke). I learned that others had similar problems, and some have solved them by installing new BT drivers. The best advice came from this post. Putty did not work for me, so I stuck with what I had, namely HyperTerminal.

So here is my own step-by-step tutorial on how to make an Arduino communicate with Windows XP via a Bluetooth module.
Note: From the Bluetooth perspective, Wise Clock 4 I used for my testing is similar to Arduino.

1. Upload this simple sketch that "echos" what it reads from Bluetooth and also broadcasts a message periodically. The communication between Arduino and the BT module is serial, with a baud rate of 9600, according to the documentation.

#if ARDUINO < 100
  #include
#else
  #include
#endif

void setup()

{
  Serial.begin(9600);
}


void loop()
{
  while (Serial.available())
  {
    // get char from bluetooth;
    char inChar = (char) Serial.read();
    // output it back, between brackets;
    Serial.print('[');
    Serial.print(inChar);
    Serial.print(']');
  }
  // broadcast message;
  Serial.print("millis() from Arduino: ");
  Serial.println(millis());
  delay(2000);
}

2. Power Arduino, with the BT module connected, and let it run the sketch.

3. Make the BT module (on the Arduino) visible to XP, by adding it to the list of Bluetooth devices. For this, click on the "Bluetooth Devices" icon in the tray (bottom right corner of the XP's desktop). You will see this box.

Next, you will see the BT device added to the list, under the name "linvor".

Then select the last option, "Don't use a passkey". Although it makes little sense at this point (since you know that the passkey is 1234, according to the documentation), it is very important to not use a passkey here.

The last step of the wizard shows the two ports that have been added. Write down the "Outgoing COM port", since this is the one we will be using for communication (step 4).

4. Open HyperTerminal to establish the 2-way communication between XP and Arduino, via Bluetooth.
Select, from the list, the COM port specified as "outgoing" for the BT device.

Next, you will be shown this pop-up.

After you click on it, you are prompted to enter the passkey, the one you (reluctantly) skipped in the process of setting up the BT device. Type "1234", as specified in the BT module documentation.

After hitting "Next", you are shown this last confirmation box.

In the same time, the HyperTerminal starts displaying the message coming from Arduino.

Note that, when the COM port was opened in Auto mode, no parameters (baud rate etc) being specified.
Interestingly, after the communication is established, the baud rate is reported as 2400 for some unexplained reason.
You can also type characters in HyperTerminal and they will be echoed back, between brackets, by Arduino.

Optionally, if you want to see what you typed (before the echoing from Arduino takes place), you can enable local echo, by selecting "Properties", then "ASCII Setup".

Once the communication between XP (HyperTerminal) and Arduino is established via Bluetooth, the "Status" LED (if you have it soldered) is on continuously. When the BT module is not communicating, the "Status" LED is blinking at a frequency of about 2Hz.

The next time a HyperTerminal session is opened, XP remembers the BT device and the communication params (ports, passkey) and does not ask to set it up again. (I guess that's why it is called "pairing", although this word does not appear anywhere in the process.)


Time to write some serious applications using Bluetooth:)

BookClock revisited (time setting from buttons)

By popular demand, I added time setting capabilities to BookClock. Time and date can now be set from two buttons, called "Menu" ("H/M" in the photo) and "Plus" ("+").

Press "Menu" to select between hours and minutes. Press "Plus" to increment the blinking selection. When done, just let it time out (about 4 seconds) and the time will be saved in the RTC.
Hold down "Menu" until the date, formatted as yy/mm/dd, is displayed. Press "Menu" again to select either year, month or day, then press "Plus" to increment the blinking value.

The time-setting code is copied and adapted from IllyClock and uses the same state-machine mechanism.
I connected the two buttons to D16 ("Plus") and D17 ("Menu").

The code, compilable on both Arduino 23 and 1.0, can be downloaded from here.

Wise Clock 4 with ATmega1284

I thought that replacing the ATmega644P with its bigger brother ATmega1284P in Wise Clock 4 would be trivial. How wrong I was.

The first step was to burn the bootloader. After a bit of research, here is what I found out:

• USBtinyISP from adafruit cannot program chips with more than 64K of flash (see this thread);
• if you don't want to start from scratch (that is, compile the source code and figuring the fuses) there are at least 3 sources: ryanmsutton, maniacbug and calunium;
• USBtinyISP half-works: it writes to the flash, but reading back for verification purpose fails because of a bug in the firmware; I ignored the verification error;
• although burning the bootloader (any of the three mentioned above) seemed successful, uploading any sketch afterwards always failed;
• the setup from ryanmsutton did not work for me (I guess the fuses are wrong; then the core files also point to the arduino folder, instead of the sanguino, as it should be);
• with the bootloader from calunium (atmega1284p_16MHz.hex) I was able to upload sketches; these are the settings in boards.txt I used:

atmega1284.name=Sanguino W/ ATmega1284p 16mhz
atmega1284.upload.protocol=stk500v1
atmega1284.upload.maximum_size=129024
atmega1284.upload.speed=57600
atmega1284.bootloader.low_fuses=0xFF
atmega1284.bootloader.high_fuses=0x98
atmega1284.bootloader.extended_fuses=0xFD
atmega1284.bootloader.path=atmega
atmega1284.bootloader.file=atmega1284p_16MHz.hex
atmega1284.bootloader.unlock_bits=0x3F
atmega1284.bootloader.lock_bits=0x0F
atmega1284.build.mcu=atmega1284p
atmega1284.build.f_cpu=16000000L
atmega1284.build.core=sanguino

Note the upload protocol (stk500v1), note the fuses and note the core folder (last line).

• in the end, since the booloader from calunium worked for me, I did not try the one from maniacbug, which (from what I read on the arduino.cc forum) seems to be very popular and work very well;

To compile the code for Sanguino with ATmega1284P, some macros must be updated as well, by adding
defined(__AVR_ATmega1284P__)  to any defined(__ATmega644P__)

like this:

#if defined(__AVR_ATmega644P__) || defined(__AVR_ATmega644__) || defined(__AVR_ATmega1284P__) // sanguino

In the end, the program space is about 126K (compared to 62K in ATmega644P) and the available RAM is 16K (compared to only 4K in Atmega644P). Not a bad upgrade for only a few bucks more.

Note: ATmega1284 is not defined in avrdude.conf shipped with Arduino 22 or 23 (folder \arduino-22\hardware\tools\avr), but it is defined in Arduino 1.0.

Troubleshooting guide for Wise Clock 3/4

This should really be a chapter of the assembling instructions for Wise Clock 3/4. Until I integrate everything into a single document, it is just another post that begged to be written (long ago, as a matter of fact).


1. Right after power up, the clock should make a beeping sound. If that does not happen, here are possible causes:

• missing input 5V power; the optional power LED may be useful in this case, turned on when the power is present;
• reset pin may be shorted to ground (the processor won't execute any code);
• processor may not be powered: check that pin 10 has 5V and pin 11 is connected to ground;
• faulty or missing the 16MHz clock for the processor; check crystal connections to the pins; if everything looks good electrically, try to upload a sketch; it that still doesn't work, test by replacing the processor or replacing the crystal;
• buzzer may be disconnected; check connections between processor's pins and buzzer, shorts to the ground, terminal soldering.

2. The display does not light up at all (assuming the display is not defective):

• faults in the connections to the display (right-hand header): look for shorts between neighbor pins in the display header; look for shorts between any signal pins in the display connector and ground;
• output header (left-hand) display header may have shorts between neighbor pins or pins shorted to the ground;
• the board's female connectors may be misaligned (shifted by one) when plugged in the display's male headers.

3. Getting SD card error in "Quote" mode:

• faulty SD card; check the SD card itself by reading it in a PC; must be formatted FAT16 (therefore 2GB or smaller);
• the required text files may be missing; check for their presence in the root directory;
• SD card may not be powered; check 3V3 power on the third pin from the left (second pin from the left is connected to the ground);
• check voltage divider resistors R5, R6, R7 (under the processor) and make sure they are 4K7.

4. Pressing a buttons (Set, Menu or Plus) does not trigger the expected action:

• button itself may be defective, either always open (there is no contact between button's terminals when button is pressed) or always closed (short between terminals); verify with a multimeter that the button works correctly;
• look for potential shorts between the "active" terminal (connected to the processor pins D0, D1 and D2/D3, see schematic) and ground.

5. Communication error when trying to upload a sketch:

• make sure you plugged the FTDI cable/breakout the correct way/orientation, with the Ground/Black terminal to the right;
• check the Rx/Tx connections to the processor (pins 14 and 15); make sure that they are not cut or shorted to the ground;
• "stk500_getsync(): not in sync: resp=0x00 error" usually indicates that the upload speed is incorrect; for the ATmega644P processor, the upload speed must be 38400 (defined as atmega644.upload.speed=38400 in boards.txt); for the ATmega1284P processor, the upload speed is 57600;
• if you get "avrdude: Yikes!  Invalid device signature. Double check connections and try again, or use -F to override this check", temporarily modify the signature in file hardware/tools/avr/avr/etc/avrdude.conf with one of these (depending on your processor):
• signature = 0x1e 0x96 0x0a;   //  for ATmega644P
• signature = 0x1e 0x97 0x05;   //  for ATmega1284P

Stand for ClockTHREE

Some time ago I received, as a gift, this smart and very useful stand from fellow clock enthusiast Nicholas in San Diego. He designed it and made it specifically for ClockTHREE. Simple yet elegant, this is essential if you want your C3 on the desk or table.

I did not have the chance to appreciate it until now, with an older ClockTHREE borrowed from a friend (I gave it to him as a gift). Here is the C3 on the stand, a perfect fit!

Thank you Nicholas! Keep up the great work!

Wise Clock 4 - "Time Lived" menu option

At the request of AlexT, I implemented a new feature in Wise Clock 4, which allows the display of time lived (since birth) in different formats (years/months/days/hours/minutes/seconds, days only, hours only, minutes only).

The above photo shows the year/month/day on the top row and the hours/minutes/seconds on the bottom row.


Lifetime in Wise Clock 4 from florinc on Vimeo.

The birth date and time are read from the file message.txt on the SD card.

I was inclined to use the Time library, but I found it a little bulky for my needs and also unsuitable for dates before 1970. Then, I copied and modified the function makeTime() to convert a datetime to seconds, and I wrote my own diffTime() function to calculate the difference (in years, months, days etc) between two dates.

Alternating between display modes is done by pressing the SET (middle) button.

This code will be included in the next release of Wise Clock 4 software.

Wise Clock 4 Dual screen chronometer

Update (June 30, 2014): This chronometer clock is complete now. It is also available in the two-sided (two-faced) version, aka "Kandinsky", as shown in these photos.

This chronometer, inspired by the Doomsday clock by Wyolum, is made with a Wise Clock 4 board (available for sale here) and two 3216 displays from Sure Electronics.



Its main feature is the odometer-style rolling of the digits when they change.
The time is updated once a second, based on the 1Hz interrupt signal from DS3231, as described here.

As shown in the video, one button is used to change the display brightness, another button is used for changing the font, and the third is used for switching between rolling style and static style.

By using the bigger (5mm) 3216 displays with the same setup and software, this clock can be easily read from a distance of at least 100 feet (30 meters).

Source code is available here. The current version does not allow setting up the time and date from buttons.

Details on assembling ClockTHREE v2

I just finished assembling another ClockTHREE v2 and I realized that there are details that need a bit of clarification (and not captured in the original building instructions). These are related to the orientation of the RGB LEDs and the battery holder for RTC. Not a lot of info, but I felt I have to record these, since I will have to go through the exercise of figuring it out again next time I assemble another C3.

Here are the pictures worth a thousand words.

First the LEDs, shown laying down in the correct orientation. The longest pin, the common node, is closer to the bottom of the PCB (where the ATmega328 is).

Because the LED pins are only 0.05" apart (as opposed to 0.1" in a normal LED, or most other components for that matter), special attention must be paid when soldering these RGB LEDs. There is a tendency of shorting two adjacent pins, so make sure that doesn't happen, by checking with a magnifying glass (or with the ohmmeter). To avoid the possible shorts, I bend the pins outwards, away from each other, as shown below.

Note: One of the advantages of C3 v2 over C3 v1 is that the RGB LEDs can be inserted directly, all the way through, without the need to use the bending tool (as shown in the tutorial for v1).

Second, the battery holder. If you use one like mine, here is how it should be placed.

Note that the board was smartly designed to allow the use of many types of battery holders, including those all-metal ones (either SMD or through-hole).

Also shown are the pull-up resistors required if you solder the DS3231 RTC chip directly to the (back of the) board (and not use the ChronoDot).

Another detail worth mentioning is that the buzzer I am currently using in Wise Clock 3/4 gives a very faint sound when used in C3/C3Jr.

C3Jr on Kickstarter

Do you want the best deal on C3Jr?
Here it is, on kickstarter.



Already exceeded the goal of $2,500, it will be a sure thing in 21 days from now. I am guessing that the Wyolum team is already busy assembling them :)

The Doomsday clock (pledge $500) looks especially interesting, made of 3 adjacent C3Jrs. Lots of possibilities with this very large display, check out the video.

Scrolling message sign display with Wise Clock 3/4 - part 2

This post, written some time ago, demonstrated how to make a message sign using two 3216 displays connected to Wise Clock 3. The font used in the demo is 8*8 (actually just 7*7), quite small for the 16 LED height of the display.

The code for a larger (11x14) font is already included in the Wise Clock 3/4 software (file fontLarge.h), just not used and used when the "Big Font" menu option is selected (file AppBig.cpp). I resurrected this forgotten font and the functions that use it and this is how it works:



I modified the original sketch (posted in this thread of the Arduino forum) to include the following lines at the top of the file:

char* msgLine = "           Hello world - demo for large font scrolling on dual 3216 display.";
int crtPos = 0;
int crtColor = GREEN;

and the loop() function:

void loop ()

{

  displayLargeScrollingLine();

  if (crtPos >= strlen(msgLine))

      crtPos = 0;

}

The source code for the demo in the video can be found here.


Related posts:

• Introducing Wise Clock 4