OpenWRT and the Zsun Card Reader

During the last few weeks since my first post about the Zsun WiFi Card Reader I learned a few things that I haven’t documented yet.

After I was able to confirm that my device has indeed PCB v2 but that flashing should work just the same, I tried the simple method described here:

  1. Insert a FAT formatted micro SD card into the reader and plug the reader into a PC (running Windows, in my case). The card should be assigned a drive letter, say “J:”.
  2. Connect to the WiFi access point created by the reader.
  3. Open
  4. Open the drive/card in the file explorer, create a new folder named “.update.” and copy the SD100-openwrt.tar.gz archive into it.
  5. Open – this should return status code “2”.
  6. Wait patiently for the described LED flashes!
  7. Connect to the new access point called “OpenWRT”.
  8. Open and configure OpenWRT.

This worked like a charm (a big thanks to Warsaw!), but only 5 minutes later I managed to lock myself out with a bad WiFi config. Great. So I went ahead and soldered leads to the serial headers. But while I was able to receive and read the console output just fine I had no success sending any input to that console. Only today I learned that PCB version 2 is missing a jumper that needs to be connected in order to enable serial RX. Connecting this jumper has exceeded my meager soldering skills so far, though.

Fortunately, I learned another fact from a helpful comment on my previous post: By inserting or removing the SD card during boot, OpenWRT can be put into fail-safe mode that will reset the configuration. I kept inserting and removing it in quick succession for about 10 seconds in order to get the timing right. Now I’m able to connect to the WiFi again!

One of the images is showing an Ethernet cable attached directly to the board. This did not work for me and trying it was somewhat naive. It’s been brought to my attention that this might damage the SoC, too. If resetting an OpenWRT installation as described above is not enough, the best way to un-brick the device seems to be through the serial console as described in the comments.


The Zsun WiFi Card Reader

I’m not sure where I read first about the $8 Zsun WiFi Card Reader and the attempts by the people at Warsaw Hackerspace to flash it with their port of OpenWRT. It made me curious, so I went ahead and ordered a sample. Shipping from China took a while but I received the tiny gadget yesterday.

So far I could confirm the documented root access to the stock firmware via telnet on port 11880 using the password “zsun1188”. I have not tried flashing OpenWRT yet as I am not sure which of the at least two different PCB versions I got. Could anyone give me a hint on this?

The Fancy Lantern Stick

I’m not sure about other parts of the world, but back here in Germany we’ve got a tradition called Laternelaufen. It involves lanterns, preferably home-made from cardboard and colored paper, lantern sticks, and a bunch of happily singing children. And of course, it requires a way of lighting the lanterns. Traditionally, this is accomplished by the use of burning candles which are cheap and actually looking great, but will also ever so often result in the lanterns themselves catching fire. So, for many years there have been battery powered lantern sticks featuring a small light bulb on the upper end.

My daughter is very much looking forward to this year’s Laternelaufen events. What a great excuse for myself to get started on a small new project, the Fancy Lantern Stick! Here’s the list of major ingredients:

  • 20cm of PVC tubing 40mm in diameter, normally used for in-house plumbing
  • 50cm aluminum pipe, 6mm in diameter
  • 1 small piece of wooden board, roughly 15mm strong
  • Acrylic spray paint, the colors of your choice
  • Clear lacquer spray
  • 1 Arduino Pro Mini
  • 1 5V Step-up power converter
  • 1 Battery holder for 2 AA sized batteries
  • 8 WS2812B LEDs on separate tiny boards
  • 1 Switch
  • 1 Push-button
  • An assortment of wires, headers and connectors
  • Hot glue

When switched on, the Arduino will produce yellowish-white light from the 8 LEDs and simulate the moderate flickering of a candle flame. The red push-button on the handle triggers special light effects to show off.

The source code for the Arduino sketch is available on Github, and I’ll try to add a couple of photos showing the finished stick once I find the time and manage to borrow it back from my daughter.


I did manage to take a few photos of the finished stick today and added them to the gallery. Also, if there is enough interest I could supply more detailed information on how to build one of these, of course.


Converting .mysql_history Files to New Format

When I upgraded one of my servers from Fedora 20 to 21 recently, I noticed that – among a few other issues – the command line history of my mysql client was missing. Too me, this is valuable information and documentation, even. So I investigated and found, that the file format for the .mysql_history seemed to have changed and the client had just discarded my old data. The new file now contains various characters (including ‘space’) in octal notation and it starts with a special marker line:


I assume that this change might have been caused by either MariaDB or Fedora itself having switched from readline to using libedit.

#!/usr/bin/env php
$oldData = file($argv[1]);
foreach ($oldData as $line) {

The PHP package that comes with Fedora 21 seems to be using the same library. So, after restoring my old .mysql_history from backup it was easily converted to the new format using but a few lines of PHP code:

./convert_history.php ~/.mysql_history.bkp ~/.mysql_history



Wireless Sensor Network, Part 2

Still trying to save my batteries

By now it is time for at least an intermediate update on this project. In the meantime I have indeed revised the sensor boards by adding a switching transistor controlled through one of the remaining digital pins on the ATmega. The firmware was modified, and it will now power down the attached sensors before entering sleep mode. Disappointingly, this resulted in a battery lifetime extended by no more than roughly 10%.

On a mostly unrelated note, the voltage graph now looks “stepped” when compared to the previous one. This seemed to be a direct result of switching from maniacbug’s original driver for the RF24 module to the one newly optimized by tmrh20. I’ve got absolutely no clue why this would affect the voltage measurement against the bandgap reference, but there it was. If you can shed some light on this, please leave me a comment.

The next thing I tried, somewhat desperately, was to reduce the number of data samples by increasing the sleep time from 1 minute to 5 minutes. This had no discernible effect on battery life-time. But at least it leads to the conclusion that I need to further investigate power consumption during sleep mode.

So, just assuming that it was the sensors that were draining the batteries in sleep mode turned out to be a bad idea. Now I really need to replace my crappy 7€ multimeter with something a little more precise that will allow me to actually measure which part of the circuit is drawing which amount of current.

Wireless Sensor Network, Part 1

With all components finally having arrived from China, I built the first couple of wireless sensors a few months ago. They are using the cheap nRF24L01 transceiver modules for data transmission based on the RF24Network network layer. I’m using a Raspberry Pi with the transceiver module directly connected to its GPIO pins as the root node. The sensor nodes are controlled by an ATmega328 microcrontroller flashed with the Arduino firmware for convenience.

Each sensor node currently features a DHT11 humidity sensor, a DS18B20 digital thermometer, a BMP180 barometric pressures sensor and it’s powered by three AA cells. The controller spends most of its time in power-saving sleep mode, waking up to send a data packet about every minute. Each packet contains the readings from the three sensors as well as the battery voltage as determined against the bandgap reference.

The setup is far from final. For one, I’m still not sure how to store the data. Currently, it is just logged into a text file with an occasional and experimental import into OpenTSDB. I haven’t really come to trust OpenTSDB since I haven’t found a suitable and convincing way to backup the HBase data, yet.  Also, I might still replace the Raspberry Pi root node with an Arduino based MQTT relay.

First though, the power consumption of the sensor nodes needs improving. When I started out I was hoping for each node to run for close to a year on a single set of batteries. As you can see in the graph above, with the current design a set of three NiMH batteries with low self discharge lasts for no more than 6 weeks. What comes to mind in order to improve this, is to switch off the sensors and the transceiver in between samples. That is probably what I’ll try next. Please let me know if you’ve got any other ideas!



Minimal Arduino using an ATmega88

In preparation of the quest to build my own wireless sensor network I spent some time in getting a minimal Arduino up and running based on the ATmega8 chip. It was not before I finally succeeded that I realized it would be of no use in this case, because the ATmega8 lacks the ability to trigger an interrupt handler through its watchdog timer. So, I wouldn’t be able to use its power down sleep mode.

ATmega88 using internal clock

I then found a couple of ATmega88 chips in my stockpile, which aren’t subject to this limitation. Fortunately, setting this one up as a minimal Arduino turned out to be much the same. I mostly followed an existing guide, but added the Optiboot bootloader to the mix.

I first needed to compile the bootloader for the use with the internal osciallator at 8Mhz. So I added the following lines to arduino-1.0.5-r2/hardware/arduino/bootloaders/optiboot/Makefile:

atmega88_8: TARGET = atmega88
atmega88_8: MCU_TARGET = atmega88
atmega88_8: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=19200'
atmega88_8: AVR_FREQ = 8000000L
atmega88_8: LDSECTIONS  = -Wl,--section-start=.text=0x1e00 -Wl,--section-start=.version=0x1ffe
atmega88_8: $(PROGRAM)_atmega88_8.hex
atmega88_8: $(PROGRAM)_atmega88_8.lst

I limited the baud rate to 19200 as greater values turned out to be less reliable in my setup. For this to work, I had to explicitly disable SOFT_UART in optiboot.c:

/* Switch in soft UART for hard baud rates */
#if (F_CPU/BAUD_RATE) > 280 // > 57600 for 16MHz
#ifndef SOFT_UART
//#define SOFT_UART

With that you can build the bootloader by running make atmega88_8 or omake.bat atmega88_8 on Windows in that same directory.

Next, I added the new Arduino type to arduino-1.0.5-r2/hardware/arduino/boards.txt. It should have been possible to add the board definition to a boards.txt file below the sketchbook directory but that did not work for me and the current version of my Arduino IDE. Optiboot (8MHz internal OSC)

Finally, with the ISP connected, I installed the new bootloader using the Aduino IDE and can now upload sketched through the serial connection.

There seems to be one annoying issue left though. When the compiled sketch size is getting close to the limit of 7680 bytes the upload will fail with an error message. If anyone can shed some light on what I might have missed here, please leave me a comment.

Android Development on Windows using an Intellibook Tablet

Earlier this year I acquired a 7 inch Intellibook Android tablet by ordering a trial subscription for a magazine on Java programming. When I tried to use it for Android development on Windows today, I couldn’t find a suitable USB driver. It took me a while to find out that the driver released by Google for their own devices would actually work.

Intellibook Tablet

Here is how to install it for the Intellibook tablet:

  1. Download the Google USB driver package for Windows.
  2. When finished, the driver is located in <android-sdk>\extras\google\usb_driver\, and you need to modify the file android_winusb.inf contained within. Add the following lines twice, once in each section [Google.NTx86] and [Google.NTamd64]:
    %SingleAdbInterface%        = USB_Install, USB\VID_2207&PID_0010
    %CompositeAdbInterface%     = USB_Install, USB\VID_2207&PID_0010&MI_01
  3. Connect the tablet to the PC and install the modified driver.device_manager
  4. Create the file %USERPROFILE%\.android\adb_usb.ini containing the vendor code 0x2207 or add it if the file exists:
    echo 0x2207 >> "%USERPROFILE%\.android\adb_usb.ini"
  5. Remember to enable developer options and USB debugging on the device.

This worked for me, but of course there is no guarantee since Google does not support this device. On the other hand, it might also work for other “no-name” devices lacking suitable drivers. To find the hardware id string needed to modify the driver’s *.inf file connect the device to the PC, locate it in the Device Manager, and right-click to open properties -> details -> hardware-id. Try at your own risk…

Cheap USBASP Sticks for V-USB Development

A while ago I ordered a couple of cheap USBASP sticks. They are to be had on Ebay for as little as 2,50 € including world wide shipping and meant to be used for programming AVR microcontrollers. The programmer itself is based on an ATMega 8 controller so one of the sticks can actually be used to update the USBASP firmware on the other one. All it needs is shortening JP2 on the board to be flashed.


avrdude -v -c usbasp -p atmega8 -U flash:w:usbasp.atmega8.2011-05-28.hex

But that is not even best part: the USBASP firmware is based on the open source V-USB driver, meaning these sticks can easily flashed with any other firmware using the same driver. So, they make for a cheap, complete, and easy to handle development platform for USB projects like the IR receiver introduced in an earlier post.

USB Receiver for the Ruwido Merlin IR Keyboard

When I noticed this compact IR Keyboard was on sale for no more than 1.- € I had no choice but to order a couple. One of them might prove useful when I manage to set up a media center based on a Raspberry Pi some day.

Ruwido Merlin Keyboard

Of course, this keyboard comes without a receiver. But how hard could it be to get it to work with LIRC? Very hard, as it turns out. Fortunately, I wasn’t the first one to encounter this problem. There is an open source decoder for this keyboard targeting AVR microcontrollers and I had just come up with the idea to combine it with the V-USB stack to create a USB receiver when I found out that someone else had already done just that.

The circuit was easily set up on a breadboard, but the firmware needed a few minor modifications to compile with recent versions of avr-gcc. When those were done and the firmware flashed, the operating system would still refuse to accept the circuit as a valid HID device. It took me quite a while to figure out that the author had made and committed some changes that seemingly broke the USB stack. When I reverted to an earlier version, the device worked fine. My clone of the repository is available on Github and its master branch now holds the still working version of the firmware.

Ruwido HIDUSB 1.0

Then I created a compact board to hold all the component. It has a single sided layout with only a few jumper wires on the top side and I used the toner transfer method for etching. The result did not turn out very pretty but it does the job. Unfortunately, in the first version of my design I missed R3 so the images on the gallery show a quick-fix for that problem. The board also features a 10 pin connector for the ISP since the firmware will probably still require more work. I added the revised EAGLE files to the repository.