After a long wait the Raspberry Pi I ordered from Farnell on 29th February finally arrived yesterday.
I expect that most people reading this blog knows all about the Raspberry Pi and the charity behind it by now, designed with the aim to bring programming back into the school curriculum and spawn a new generation of coders, it’s had some fantastic news coverage and even people with no idea about computers have mentioned it to me over the last few months. It has been a rocky road, originally it was expected to have been released in late 2011 but finally the much anticipated single board computer has started to be delivered into the eager hands of geeks around the world. Initially only a caseless version of the “Model B” is available, intended for early adopters and developers with a fully cased version being launched for education later in the year. The idea being that by the time it reaches the hands of school children there will already be a healthy eco system built up around it and those preparing educational material will have been able to do so.
At the moment I am just familiarising myself with it and getting a grasp of what it is capable of. I’m running Debian Squeeze on it as that’s my distro of choice for servers and the like anyway and is also what the Raspberry Pi team are currently recommending. As a desktop it’s usable but pretty sluggish, perhaps not as much as expected but it’s potential for me lies more in the home automation and IoT field, £30 for a tiny networked Linux box is unbeatable and with up to 17 GPIO pins, built in UART and support for I2C and SPI it also opens up a lot of possibilities for interfacing to other hardware, a number of expansion boards are already available or in the pipeline. Here is a good primer on Getting Started with Raspberry Pi GPIO and Python.
It might seem like magic but a boost converter or step-up converter is a handy little device that can output a voltage greater than its input voltage. This makes it very useful for getting a consistent voltage in battery powered devices or running a circuit from fewer cells than would otherwise be required. If you don’t need much capacity it can also be a good way of using the last remaining power from batteries that other devices have deemed too flat, connect a few up to a boost converter and you can still get some useful power out of them for a while longer. For more capacity you can add more cells (as long as you keep the input voltage under the output voltage) or use higher capacity batteries such as C or D cells. The Maxim chip I am using here has an adjustable output (2.7-5.5V) and will work with an input voltage as low as 0.7V.
Obviously it isn’t really magic and this extra power can’t be generated from nowhere, P=IV and all that. What this means in practice is that by increasing the output voltage the available output current must be lower than the source current and will decrease as the input voltage decreases (as the batteries deplete), as seen in the graph on the left below. Efficiency is also dependent on the input voltage and the output current, peaking at around 87% with a 3.3V input and a 5V 200mA load as seen on the right hand graph.
I was poking around in the JeeLabs RF12 library recently (now part of JeeLib) and noticed that it now supports the ATtiny microcontrollers – it’s what the new JeeNode Micro uses, which got me thinking about even smaller, simpler wireless temperature sensor modules again. If you aren’t familiar with the Atmel TinyAVR range of microcontrollers they are the little brother of the ATmega that is used in our old friend the Arduino, smaller and lower cost, they are ideal for simple applications like this. The Arduino platform doesn’t support the ATtiny out of the box but thanks to the arduino-tiny project that is easily fixed, more on that later.
The version of the TinyAVR that I’m using here is the ATtiny84, it’s a 14 pin DIP package with 8KB flash, 512 byte RAM, up to 11 GPIO pins, 8 with ADC, and support for SPI, plenty to easily support the RFM12B and a temperature sensor. Using the ATtiny84 has allowed me to build my smallest (4cm square excluding the 2 x AA batteries), simplest and cheapest wireless temperature sensor yet which I’ve dubbed the TempTX-tiny, only 3 components are used, the ATtiny84 microcontroller itself, the RFM12B transceiver and a temperature sensor.
This little project was born out of a wish to control a DAB tuner from other rooms of the house and a couple of hours on a Sunday afternoon made it reality. A Nanode (an original Nanode 5 in this case) is plugged into my ethernet network and an infrared emitter is connected to digital pin 3, on visiting the ip address of the Nanode using a web browser you will see a series of buttons (shown on my phone in the screenshot on the right, click to see it full size) and selecting the various options makes the Nanode transmit the relevant infrared code to operate the DAB tuner.
The hard work here is done by the IR Remote library by Ken Shirriff available here. This infrared library has direct support for several common IR protocols (NEC, Sony SIRC and Philips RC5 and RC6) but not the one that my DAB tuner uses, fortunately this isn’t a problem as the library also makes it easy to read and transmit using the raw infrared codes (mark and space intervals) from any remote control. NB. If you are using Arduino IDE 1.0 note the comment on the library page about changing WProgram.h for Arduino.h – that’s the only change required for 1.0
I’ve been struggling for thinking and tinkering time this week due to a bad cold that has totally wiped me out but I did have some more thoughts on further reducing the power usage of the TempTX V2. The first one is quite simple and will only have a minor effect but only needs a minor code change – it turns out that it is possible to reduce the time the DS18B20 temperature sensor takes to get a reading by reducing its resolution as shown in the table below. It is currently using a 12 bit resolution but even reducing it to the lowest setting of 9 bit, an effective resolution of 0.5°C at a time would be acceptable for most applications I think.
Resolution
9 bit
10 bit
11 bit
12 bit
Conversion Time (ms)
93.75
187.5
375
750
LSB (°C)
0.5
0.25
0.125
0.0625
Milliseconds might only seem like a small difference but that is as much as an 8 fold difference and as I said in the last post, every little counts.
Secondly, a completely unrelated discussion on Twitter at the weekend lead to a likely explanation for the total drop out when the battery voltage reaches 2.7V, namely that the default BOD (Brown Out Detection) fuse setting for the ATmega328 when using the default Arduino bootloader is 2.7V (sound familiar?), when the voltage drops below this level the mcu is put into a reset loop until it rises again. That explains the sudden cut off at 2.7V. With some fiddling and reflashing of the bootloader this BOD setting can be changed to 1.8V or even disabled completely and some brief research shows that the ATmega328 can run from as little as 1.8V (although it would be out of spec running at 16MHz at that low of a voltage) and that the RFM12B module should run OK down to 2.2V so there is plenty of room there. Surprisingly the DS18B20 temperature sensor is not so tolerant, the datasheet says it needs a minimum of 3.0V, however, I’ve already proved that it runs ok at 2.7V (at current average temperatures anyway) and a little research found some reports that it works down to around 2.6V before it starts to give errors and the addition of an electrolytic capacitor should be sufficient for it to get a reliable reading at even lower voltages, especially at the lower resolutions where it needs to be powered for a shorter amount of time. I might try some more voltage tests with the BOD disabled to see how low I can get the whole thing will go before it starts to become unreliable. Another, maybe more sensible option might be to look at some different temperature sensors that are rated to work at lower voltages, there are several cheaper analogue alternatives to the DS18B20 that might make more sense, they would need to be calibrated though and it would mean only one sensor per input (not really a factor with the way I’ve been using these boards so far) but would have a secondary advantage in that the 1-wire and Dallas Temperature libraries wouldn’t be required which might mean that the code can be reduced to fit into one of the smaller ATmega microcontrollers thus reducing cost again.
Please feel free to post in the comments if you can think of any other suggestions or improvements.
I just wanted to share this fantastic Pink Floyd-esque (with a hint of Ozric Tentacles in places) reworking of the Doctor Who theme tune from Traffic Experiment as it doesn’t seem to have been getting the love it so obviously deserves. You can also download this track for free as an MP3 or FLAC at the Traffic Experiment website.
I hope you enjoyed this interval, normal service will be resumed shortly.
The original wireless temperature sensor module that I built at the end of October is still happily working away proving that the concept of a very minimal wireless node works and that it is quite happy running from two AA batteries.
There were a couple of factors that influenced the previous boards design that meant is was less than ideal, firstly the need to remove the RFM12B when programming using a 5V FTDI cable complicated things and due to Royal Mail dragging their feet and my impatience to get the thing built I only had a piece of stripboard 18 rows high which necessitated placing the RFM12B alongside the ATmega instead of in line with it .
Now, armed with new supplies of stripboard and some new ideas I’ve made a new improved and smaller (40x65mm) board. To resolve the voltage issue I decided to make a small adapter board which contains a voltage regulator and smoothing caps (I didn’t want to put these on the main board in order to keep it as minimal as possible) and I’ve also moved the capacitor and pull up resistor for the reset on to this board meaning the TempTX (as I’ve been calling it) now requires two less components and a little less space. Of course only one adapter is required for as many of the TempTX nodes that are used so in the long run the saving of components required and time to build will make more sense. This adapter also allowed me to re-order the programming pins on the main board which further reduced the number of links required and therefore the space required. Other than using a resonator instead of the crystal and load capacitors I think this is as minimal as this board is going to get. I suppose you could omit the programming header and program the ATmega in another board but that’s probably taking minimalism a bit too far.
I’ve recently put together another wireless GLCD display, this time using a WiNode together with a ST7565 GLCD with RGB backlight and a Nintendo DS touchscreen. The WiNode is fitted with a 433MHz RFB12B transceiver and the MCP79410 Real Time Clock (RTC) option as well as a DS18B20 temperature sensor for the room temperature reading.
This is quite an improvement on the first display I made, the feature list is now:
Touch control using Nintendo DS touchscreen
3 Different display views selectable via touchscreen
Backlight colour changes depending on power reading
Supports MCP79410 RTC for time & date display
The WiNode makes a great base on which to build a display like this and being 3.3V it pairs well with the 3.3V ST7565 displays. This particular display is the Adafruit one with the RGB backlight (available from Proto-PIC) that I covered here and I’ve connected it up along with the touchscreen and temperature sensor as follows:
I’ve been playing with some more GLCDs (Graphical Liquid Crystal Displays) recently, along with a Nintendo DS touchscreen. The parallel KS0108 display I used for my emonGLCD used an awful lot of pins, 16 including the power, which doesn’t leave a lot left over for anything else, so I thought I would try some of the serial displays that are available, one from SparkFun and a nice one from Adafruit that has a RGB backlight, you can see a montage of pictures of this display on the right.
Interfacing with and coding for each of these displays is subtly different as there isn’t a single unified Arduino library but none of them are complicated, it’s basically commands to move to a particular pixel of the display, select a font and print it, or for boxes, lines etc. you need to provide coordinates for the start and end points.
In combination with these screens I’ve also been experimenting with the Nintendo DS Touchscreen which is available on its own from a number of suppliers and makes for a cost effective method of adding touch control to screens of this size. When you only want to detect relatively large areas of the screen, such as for a menu, they are very easy to use.
The original Nanode has proved to be a great success with a growing community of people building many interesting networked devices and this month, Ken Boak, the creator of the Nanode has launched several new additions to the line. The new Nanode RF is essentially an upgrade to the original Nanode 5 with an on board RFM12B wireless transceiver and options for several extras such as a real time clock (RTC), 32KB SRAM and a Micro SD socket.
The second new member of the Nanode family is the WiNode, a low cost wireless node that is available in several different configurations, all using the same PCB with just the installed components differentiating between them. As with the Nanode and Nanode RF, the WiNode can be fitted with the standard Arduino headers for compatibility with Arduino shields as well as the RTC (SOIC or DIP), 32KB SRAM and Micro SD options as with the Nanode RF. The WiNode also features four 16V tolerant analogue inputs and when fitted with a dual H-bridge driver chip it can provide 2A digital outputs for driving relays or motors (although you can’t use the SRAM/SD if the H-bridge is used). Due to a nifty bit of design the WiNode can also be built for use as a shield for the original Nanode to add RFM12B wireless capability and more. Prices are very good, with WiNode kits starting at £17.50 (or £15 if you buy a pair) for the basic stand alone wireless node or only £10 if you want to use one to expand an existing Nanode 5. The Nanode RF kits start at £30 and for the first time a fully assembled unit with all the options is available for £40.
Pictured above is my first WiNode build, decked out with the SRAM and SOIC RTC options. I’ve fitted all the optional bits on this one, headers, screw terminals and even the socket for the H-bridge driver as I will keep this one aside for experimentation and prototyping, subsequent builds will just include whatever is required for the particular use. That’s the Nanode RF on the left.
As with the original Nanode, both the Nanode RF and WiNode are supplied as a kit for you to build yourself and anyone with basic soldering skills should find it very straightforward. Ian Chilton has already created a very comprehensive guide to building the Nanode RF which is available here and I suspect a WiNode version won’t be far behind (update: WiNode build guide is now almost complete).
Ken says he will have an online shop available shortly but for now you can order by sending a Paypal payment, for further details and prices of the various options see this blog post.
After a long wait the Raspberry Pi I ordered from Farnell on 29th February finally arrived yesterday.
Most Popular