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!
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.
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
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
/* Switch in soft UART for hard baud rates */ #if (F_CPU/BAUD_RATE) > 280 // > 57600 for 16MHz #ifndef SOFT_UART //#define SOFT_UART #endif #endif
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.
atmega88_8.name=ATmega88 Optiboot (8MHz internal OSC) atmega88_8.upload.protocol=arduino atmega88_8.upload.maximum_size=7680 atmega88_8.upload.speed=19200 atmega88_8.bootloader.low_fuses=0xe2 atmega88_8.bootloader.high_fuses=0xdf atmega88_8.bootloader.extended_fuses=0x00 atmega88_8.bootloader.path=optiboot atmega88_8.bootloader.file=optiboot_atmega88_8.hex atmega88_8.bootloader.unlock_bits=0x3F atmega88_8.bootloader.lock_bits=0x0F atmega88_8.build.mcu=atmega88 atmega88_8.build.f_cpu=8000000L atmega88_8.build.core=arduino atmega88_8.build.variant=standard
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.
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.
Here is how to install it for the Intellibook tablet:
- Download the Google USB driver package for Windows.
- When finished, the driver is located in
<android-sdk>\extras\google\usb_driver\, and you need to modify the file
android_winusb.infcontained within. Add the following lines twice, once in each section
;Intellibook %SingleAdbInterface% = USB_Install, USB\VID_2207&PID_0010 %CompositeAdbInterface% = USB_Install, USB\VID_2207&PID_0010&MI_01
- Connect the tablet to the PC and install the modified driver.
- Create the file
%USERPROFILE%\.android\adb_usb.inicontaining the vendor code
0x2207or add it if the file exists:
echo 0x2207 >> "%USERPROFILE%\.android\adb_usb.ini"
- 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…
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.
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.
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.
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.
The RGB wall light project is currently on hold due to a massive lack of time. Still, I’m taking little steps of preparation for the second phase of the project, the software intended to control the RGB matrix. I could use the gcc cross compiler for the job, but using a scripting language to develop directly on the device promises to be far more comfortable. I’d like to narrow this down to languages readily available as packages for OpenWRT which leaves me with Erlang, Lua, Ruby, Perl, and Python. Since I feel like trying something new I’m going to rule out Perl for now.
The installation of the bleeding edge OpenWRT version called “Attitude Adjustment” on the TL-MR3220 leaves about 1MB of space for additional packages to be installed – which isn’t even close to being enough for this purpose. So, the first step is to extend that space and the currently recommended way to do this is to move the overlay mount to an external USB device: Read the rest of this entry »
I’ve been using the Asus WL-500g Premium under OpenWRT for years. I always keep a second cold-spare device in stock to minimize our household’s downtime in case the router breaks. Last year, it was actually the router’s power supply unit that ceased to function. After I replaced it with the PSU from the spare device everything was back to normal. The same thing happened again this week, so I decided to document how I fixed the wall-wart back then.
Note: This is potentially dangerous so don’t try this at home! You’ve been warned.
Actually, the hardest part was to open the PSU. Both parts of the case are glued together, so separating them will inevitably scar the case. After the case was open, the worn out capacitor that broke the unit was clearly visible. I just de-soldered the capacitor, replaced it with a new one, and closed the case using two strips of adhesive tape. Done.
Inspired by the so called Lampduino and several other related projects I decided to build my own version of a RGB matrix wall light some time ago. During the last few weeks I finally managed to start out on this project.
The matrix of 64 individual cells and the LED back-plane are made from 4mm thin plywood that I spray-painted with a silvery varnish. The outer frame is made from a stronger 14mm birch multiplex board, yielding a very solid construction. I also bought some thin, white PVC board intended as the material for the front cover, but I still have to figure out how to cut that nicely.
Lacking the ambition to create my own LED driver board I settled for the “Rainbowduino”, an Arduino compatible board developed and sold by Seeed Studio. In addition to that, I wanted the matrix to be controlled and programmed over the air. One of the cheapest, easiest, and most versatile ways to accomplish this was to modify an OpenWRT based router for this purpose.
Last time, I installed OpenWRT on the TL-MR3220 router and added a connector for it’s serial interface. Today, I wanted to try and connect this interface to an Arduino to make the two communicate. The router’s interface operates at 3.3V while the Arduino’s UART operates at 5V, so we need to convert between those levels. The cheapest way to do this that I could find is described here. It involves using a 74LS04 hex inverter chip to convert the 3.3V signal up to 5V and two resistors for a simple voltage divider to convert the 5V signal down to 3.3V.
The TP-LINK router TL-MR3220 is a very cheap (around €22 in Germany) yet feature-rich wireless 802.11n router that supports the open source OpenWRT firmware. It offers a USB port, allowing a bunch of additional peripheral hardware to be connected. Installing the matching OpenWRT nightly build was easy enough, the original firmware offers to do so using the standard web interface.
I was thinking about connecting one of them to an Arduino in a project to come. The integrated serial interface seems to be the obvious way to achieve this. The router’s board readily exposes the interface, so I added a 4-pin header to do a few tests. The pin-out of the interface is documented in the OpenWRT wiki. Using a standard FTDI adapter I then got access to the router’s serial console. From here it should not be to hard to use the same interface to connect to an Arduino instead.