Posts with «tips and tricks» label

M4 receiver backpack for reliable wireless remote control

My investigation into the failure of the M4 receiver remote controlling my Wise Clock 4 concluded with the need to add a step-up converter. The Sure 1632 display makes the input voltage drop sometimes below the absolute minimum of 4.5V required for the M4 module to work properly. It's not the noise (spikes) in the 5V power, nor the interference on 315MHz.

I designed a simple "M4 receiver backpack" that uses a DC-DC step-up converter to ensure a 5V power for the M4 receiver module. The board supports 2 different kinds of converters, one from ebay (red in the photo below), the other from tindie (made by BBtech, black in the photo).


The backpack can be used, by default, without the step-up converter if the voltage is steady at around 5V. (A trace-jumper must be cut when a converter is added.)

The wireless remote pair of 4-key fob transmitter and receiver module is sold by Adafruit or vendors on ebay.

The assembled board wired to Wise Clock 4 is shown in the photos below. Note that only 3 out of 4 buttons on the remote have a function on the clock. Each button press could light up a (optional) LED on the receiver board for visual confirmation.


A new design of the Wise Clock 4 board should probably feature a header for plugging in the receiver module, otherwise the back of the board will show a bunch of ugly wires.


This M4 receiver backpack could be used for adding remote control to other devices with buttons, especially when these buttons are hard to access (due to enclosure design constraints), or hidden (for aesthetic purpose). One example that comes to mind is an oscilloscope clock fully enclosed in transparent acrylic; drilling holes for the buttons would require some design stretches.

The M4 receiver backpack would be also suitable for hacking an old alarm clock. Please let me know if anyone is interested :)

My first impression on Cogwheel Nixie clock

Many months ago I bought, attracted by the clearance price, the PCB for the "Nixie Driver Board Rev A" from "Cogwheel circuit works" store. I was hoping that, with all documentation in place, I would be able to build it on my own, considering it's controlled by an ATmega328 and the software was available, though not the source code.

First thing to note is that the board uses mostly SMDs. If anything went wrong (and there was a high chance, since the PCB was already described as a "mistake the board house made"), the board would become a coaster.

The schematic includes some exotic components, like the HV513 Nixie driver, not offered by digikey. Others are the DS1302 RTC and the optional DS32KHZ oscillator for RTC, which I heard of for the first time. But thanks to the detailed BOM, gathering the components was relatively (some of them are already discontinued, for example) easy.

High voltage for the Nixie tubes is generated by a hardware PWM under software control. So, like the Ice Tube Clock, in order to measure the high voltage and make sure the HV circuitry works, some software must be uploaded onto the processor. I expected the released software to do that. Unfortunately, the highest voltage I saw was under 9V.




After some digging (and learning in the process), I ended up with this simple sketch, adapted from Satashnik Nixie clock, which generates a stable 190V. I know, I was surprised too :)

#include "Arduino.h"

#define DDRHVPUMP  DDRB
#define BV2(a,b) (_BV(a)|_BV(b))
#define BV6(a,b,c,d,e,f) (_BV(a)|_BV(b)|_BV(c)|_BV(d)|_BV(e)|_BV(f))
#define VOLTAGE_WASTE   370                     //!< ~180V
#define VOLTAGE_SAVE    355                     //!< ~170V

volatile uint16_t voltage; 
static volatile uint16_t voltage_setpoint = VOLTAGE_WASTE;
static const uint16_t ocr1a_reload = 60;

void pump_init()
{
    // set fast pwm mode
    // COM1A1:0 = 10, clear oc1a on compare match, set at top
    // COM1B1:0 = 00, normal port operation
    // no FOC
    // WGM11:10 (WGM = Fast PWM, TOP=ICR1: 1110) = 11
    TCCR1A = BV2(COM1A1, WGM11);
    TCCR1B = BV2(WGM13,  WGM12);
    OCR1A = ocr1a_reload; 
    ICR1 = 170;
    TCCR1B |= _BV(CS10); // clk/1 (16MHz)
    DDRHVPUMP |= BV2(1,2);
}

void adc_init()
{
    voltage = 0;
    // PORTA.6 is the feedback input, AREF = AREF pin
    ADMUX = 6;  
    // ADC enable, autotrigger, interrupt enable, prescaler = 111 (divide by 32)
    ADCSRA = BV6(ADEN, ADATE, ADIE, ADPS2, ADPS1, ADPS0); 
    ADCSRA |= _BV(ADSC); 
}

/// Start voltage booster
void voltage_start()
{
    adc_init();
    pump_init();
}

ISR(ADC_vect)
{
    voltage = (voltage + ADC) / 2;
    if (voltage < voltage_setpoint) {
        OCR1A = ocr1a_reload;
    } else {
        OCR1A = 0;
    }
}

void setup()
{
    sei();
    voltage_start();        // start HV generation    
}

void loop()
{
  // clock functionality in here;
}

The next big step is to write the software to drive the tubes and actually show the time, which is essentially re-writing the Cogwheel Nixie clock code (or at least the basic functionality) from scratch. Then open source it. Any help would be appreciated :)

The ugliest project I've built so far

Based on this photo from BroHogan's gallery of Geiger counters, it was supposed to be a simple encasing using Adafruit's Arduino enclosure. Everything looked neat and clean inside, even with room to spare.
I wanted to use LiPo instead of AAA batteries, to avoid opening and closing the device every so often. This required the use of a LiPo charger, for which I picked the one I already had, the seeedstudio's LiPo Rider.

I spent countless hours trying to put this puzzle together:
  • only 4 places for screws;
  • small(ish) charger board must to be solidly anchored to the case (since an USB cable will be plugged in frequently), yet it does not have any hole for screws;
  • 6 wires (battery, V out, switch) must be soldered to the charger SMD board;
  • 12 wires need to connect the Geiger board to the LCD, on the other half of the case;
  • trim pot suspended somewhere (since there is no room for it on the PCB);
  • power switch to fit in the rectangular opening of the bottom ;

When I thought I figured it out, the two halves of the case wouldn't close because things inside were too tall/thick. Back to the "drawing board". Took out the ATmega328 from the Geiger board (it was touching the LCD connectors, which were already minimized for space), and replaced it with a cheap ($4) "Arduino Nano" (or is it "Mini") from ebay. This also helped immensely with the wiring: instead of connecting 12 wires between the case halves (Atmega328 to LCD), I had to solder only 3 (Vcc, Gnd, Int).



After a few more kludges (e.g. re-positioned the inductor on its side, removed the (over)power(ing) LED on Arduino Nano), I ended up with something , as the saying goes, "only a mother can love".

The lesson I learned from this experience is that, if one wants a seamless, solid, beautiful, project, one needs to either design the board for an enclosure, or the enclosure for a board. Trying to mix and match the board with the enclosure leads, at best, to something ugly.


Did I mention that I worked on it on and off for about 3 months?
The red light in the bottom left corner is the "charging" LED. (And then there is the somehow annoying LCD's backlight, visible through the translucent enclosure.)


The power switch is advertised as being the smallest rocker power switch out there. I only had to file off about 1mm on the upper side of the original rectangular opening to make it fit.

Another lesson I learned: use a transparent enclosure only when the inside looks perfect and you want to show it, and by "perfect" I mean even no visible wires.

Stay tuned for the next version of this Geiger device. (You did not think I would stop here, did you ? :)

More open source VFD clocks

I just finished assembling the latest version of akafugu VFD clock, the "MK2". Per, from akafugu, generously sent me the board for testing/review. It comes will all SMD components pre-soldered, and the processor pre-programmed. The rest of the components, all through-hole, I sourced on my own.
Here is a photo of the kit as I put it together (I forgot to include the through-hole resistors though).



Assembling was straightforward thanks to the combination of good board design and easy-to-follow instructions. The result is shown in the photo below.



MK2 has some improvements over version 1:
- newer processor (Atmega32U4, as the one used in Leonardo);
- 5V power source (vs 9V previously);
- direct sketch upload from Arduino IDE (no hacking required);
- integrated support (on-board 24LC256 eeprom) for four-letter-word feature;
- all SMD parts (quite a few actually) come pre-soldered;
- directly compatible with the existing (version 1) VFD display shields;
- better clearance with the VFD display shield (because parts are shorter in height).

In conclusion, MK2 is another winner for akafugu.


I also recently assembled the Ice Tube clock from adafruit. I bought the PCB(s) a while ago (when they were still available for sale on adafruit site) and I sourced the parts on my own. I followed the legendary assembly instructions, but things did not go without a glitch for me. Here is what I learned in the process:
  • The Ice Tube clock is not Arduino-compatible as I initially thought (see here). It cannot be programmed from the Arduino IDE and it does not have an FTDI interface/connector. The processor (I used Atmega328, but ATmega168 should work with the base software too) uses the internal 8MHz oscillator and an external 32kHz crystal. This crystal, in conjunction with TIMER2 (see file iv.c), is the heart of the clock "mechanism". (More details on the design can be found here.)
  • The high voltage for the tube is produced with impulses generated from an output pin of the processor (instead of using an external chip, like may other designs). Therefore, high voltage is not there until the chip is correctly programmed.
  • Programming the chip was a bit of a challenge; I used the makefile to build the hex file from the source, but programmed the chip with avrdude directly, as shown in this screenshot (click for bigger picture).

  • IV-18 tubes bought on ebay, even when they are new (with the wire terminals intact) can be defective. Out of the 5 tubes I got, 4 had a blackened spot on the back and one had a white spot, as shown in the photo below. Guess which one did not work.

  • Inserting all 24 wire terminals of the IV-18 tube in their holes is a challenge. I would much rather prefer the solution adopted by akafugu in their VFD clock, with half terminal holes, opening in a big empty circle (as shown below, photo from akafugu).

  • IC sockets, particularly PLCC28, although bought from digikey, can be "defective". Unlike the DIP IC sockets which press each IC pin on two sides, the PLCC28 sockets actually press against the IC pins on one (external) side only. It took me many minutes to figure out that the tube was not lighting up because one socket pin was loose and did not make contact with the IC's pin.
  • MAX6921 VFD driver used in the Ice Tube clock is more than twice as expensive as HV5812 VFD driver used in MK2. Yet, adafruit's Ice Tube Clock is still the cheapest complete (including enclosure) VFD clock kit out there.

Overall, building the Ice Tube clock was a pleasant and rewarding experience, which I recommend to kit-builders at any level. This clock looks compact, sleek, stylish, and stands out in my clock collection.

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


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 else, 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 (bad 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 the 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:)

Adventures in WiFly land - Part 1

This was a bit of a struggle, working with the XBee-footprinted WiFly RN-XV module from Roving Networks.

The goal was to get some data from the RSS feeds, kind of what this project had achieved.

First, I tried to set up the RN-XV module following this crash course (and using ladyada's XBee adapter with the FTDI cable). Everything went fine except connecting to my home WiFi network: I kept getting "AUTH-ERR". Eventually, after many tries, the module joined the network. I thought this is caused by the weak WiFi signal and other people may experience a similar scenario (which should be dealt with by the software).
Then I found with this software library, which, of course, did not work in my special case. After I started tweaking it and read the RN-XV manual once again, I found the explanation: WPA (which I am currently using) handshaking takes more than 1,000ms (1 second), which is the default timeout for the module. The solution was to increase this timeout (to 5000ms) with the command

set opt jointmr 5000

I ended up writing this sketch that makes requests to Yahoo's weather and stock quotes RSS feeds. It should work with the mentioned WiFly library (if they don't keep changing it).
Actually, I had to modify the library a bit too, to include my own specific commands in the initialization procedure. So I created this new function

boolean WiFlyDevice::myInit()
{
  if (!enterCommandMode())
  {
    DEBUG_LOG (1, "Failed to enter command mode");
    return false;
  }

  // turn off remote string;
  sendCommand("set com remote 0", false, "AOK");

  return sendCommand("set opt jointmr 5000", false, "AOK");
}

then modified begin() to look like this:

void WiFlyDevice::begin() 
{
  DEBUG_LOG(1, "Entered WiFlyDevice::begin()");

  if (!bDifferentUart) SPIuart.begin();
  myInit();
}

Another detail worth mentioning is the tuning of the delay between sending the request and reading the response. If this delay is too long, the response buffer gets overwritten, so response data is lost. If the delay is too short, the response is not there yet. Similar consideration while retrieving the response data from the buffer: we need to wait a bit for more data to come before we can say (kind-of) for sure that all data was received.

Next step (Part 2) is to parse the responses to find the correct values we are looking for, temperature and stock price, respectively, then to display them on Wise Clock 4.

Note: The RSS feeds I used are 
and
They could be custom-replaced with any other URL that returns a small(ish) set of XML data for easy parsing.


Adventures in WiFly land - Part 1

This was a bit of a struggle, working with the XBee-footprinted WiFly RN-XV module from Roving Networks.

The goal was to get some data from the RSS feeds, kind of what this project had achieved.

First, I tried to set up the RN-XV module following this crash course (and using ladyada's XBee adapter with the FTDI cable). Everything went fine except connecting to my home WiFi network: I kept getting "AUTH-ERR". Eventually, after many tries, the module joined the network. I thought this is caused by the weak WiFi signal and other people may experience a similar scenario (which should be dealt with by the software).
Then I found with this software library, which, of course, did not work in my special case. After I started tweaking it and read the RN-XV manual once again, I found the explanation: WPA (which I am currently using) handshaking takes more than 1,000ms (1 second), which is the default timeout for the module. The solution was to increase this timeout (to 5000ms) with the command

set opt jointmr 5000

I ended up writing this sketch that makes requests to Yahoo's weather and stock quotes RSS feeds. It should work with the mentioned WiFly library (if they don't keep changing it).
Actually, I had to modify the library a bit too, to include my own specific commands in the initialization procedure. So I created this new function

boolean WiFlyDevice::myInit()
{
  if (!enterCommandMode())
  {
    DEBUG_LOG (1, "Failed to enter command mode");
    return false;
  }

  // turn off remote string;
  sendCommand("set com remote 0", false, "AOK");

  return sendCommand("set opt jointmr 5000", false, "AOK");
}

then modified begin() to look like this:

void WiFlyDevice::begin() 
{
  DEBUG_LOG(1, "Entered WiFlyDevice::begin()");

  if (!bDifferentUart) SPIuart.begin();
  myInit();
}

Another detail worth mentioning is the tuning of the delay between sending the request and reading the response. If this delay is too long, the response buffer gets overwritten, so response data is lost. If the delay is too short, the response is not there yet. Similar consideration while retrieving the response data from the buffer: we need to wait a bit for more data to come before we can say (kind-of) for sure that all data was received.

Next step (Part 2) is to parse the responses to find the correct values we are looking for, temperature and stock price, respectively, then to display them on Wise Clock 4.

Note: The RSS feeds I used are 
and
They could be custom-replaced with any other URL that returns a small(ish) set of XML data for easy parsing.