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

Getting the codes from the original remote control

The first step is to use an IR receiver connected to the Nanode to read the codes from the original remote control. An IR receiver is basically a photocell that is tuned to the infrared spectrum along with a demodulator that gives an inverted logic level output. I used a Vishay TSOP31238 IR sensor (63p +VAT from Farnell) and connected it to the Nanode as shown on the left.

To read the codes load the IRrecvDump example sketch that is included with the IR library onto the Nanode, open the serial monitor and point the remote control you want to get the codes from at the sensor, for supported protocols it will output the protocol, a hex value, the number of bits and the raw code as each button is pressed, for an unsupported protocol it will return “Could not decode message” and output the raw code only.

Press each button in turn and save the codes in a safe place. Once all the necessary codes have been gathered the IR receiver is no longer required for this project but has lots of potential for future use.

Sending the codes from the Nanode

To transmit the IR codes you need an infrared emitter – a type of LED that emits infrared light. I used a Vishay TSAL7400 2.6V IR emitter (18p +VAT from Farnell) connected via a 27 Ohm resistor (as I’m using a 5V Nanode 5) to pin 3 of the Nanode as shown on the right.

The codes are transmitted by the library using pulse width modulation so a PWM pin must be used on the Nanode, the library is configured to use pin 3 which is convenient as it is free for use on a Nanode 5 (and on a Nanode Classic or RF provided you aren’t using an MCP7941x RTC).

Supported protocol codes

To send a code using one of the supported protocols you just need to use to use the relevant irsend command with the hex value and the number of bits, for example to send an NEC protocol command that IRrecvDump reported as “Decoded NEC: A10C800F (32 bits)“ you would use:

irsend.sendNEC(A10C800F, 32)

Change sendNEC to sendSony, sendRC5 or sendRC6 depending on the protocol that IRrecvDump reported.

Raw Codes

For raw codes we first need to modify the output from the IRrecvDump sketch slightly, just remove the first group of digits and make all the numbers positive, then add commas between each group and put it into an array.

eg. The code received from the IRrecvDump sketch:

-14368 4500 -4500 600 -500 600 -1650 600 -550 550 -550 600 -500 600 -550 600 -500 600 -1650 600 -550 550 -1700 550 -550 600 -550 550 -550 600 -500 600 -550 600 -1600 600 -1650 600 -550 550 -550 600 -550 550 -550 600 -550 550 -550 600 -550 550 -550 600 -1650 600 -1600 600 -1650 600 -1650 600 -1650 600 -1650 600 -1650 600 

becomes

unsigned int rawCode[68] = {4500, 4500, 600, 500, 600, 1650, 600, 550, 550, 550, 600, 500, 600, 550, 600, 500, 600, 1650, 600, 550, 550, 1700, 550, 550, 600, 550, 550, 550, 600, 500, 600, 550, 600, 1600, 600, 1650, 600, 550, 550, 550, 600, 550, 550, 550, 600, 550, 550, 550, 600, 550, 550, 550, 600, 1650, 600, 1600, 600, 1650, 600, 1650, 600, 1650, 600, 1650, 600, 1650, 600};

and then to send it we use the sendRaw command with the array name, array length and the frequency (38kHz):

irsend.sendRaw(rawCode,68,38);

Turning all this into a functional web based remote control

So now I have all the relevant codes for my target device and can send them from the Nanode to control it, the next step was to build a simple web server on the Nanode to allow easy selection of the various codes.

I based this on the Ethercard version of RESTduino by Andrew D Lindsay (itself based on the original by Jason Gullickson) modifying it to transmit IR codes instead of controlling the I/O pins and adding the menu. The only problem I ran into here was due to all the arrays for the raw codes eating up the RAM in the ATmega 328 but storing them in flash using PROGMEM instead solved that. I’m not sure the way I’m reading them back is the most elegant but it works!

My code for this is available on GitHub here and it would be simple to modify for other IR controlled devices. There is also an optional css file there to prettify the basic HTML output, due to the lack of RAM this would need to go on a separate web server. Another option would be to build a full fat web interface on another server and just call the Nanode’s URLs to send each command, eg. “http://192.168.0.188/4” to send the command for preset 4.

Other uses for infrared

The IR library along with the IR receiver makes it easy to use an arbitrary infra red remote control to control the Nanode (or any other Arduino compatible for that matter). It’s as simple as building a conditional structure in the loop to do what you want on reception of the relevant code, this could be used to turn outputs on and off or trigger events over the network or RF.

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.

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.

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.

SparkFun LCD-09351 Serial 128×64 GLCD

The LCD-09351 from SparkFun is basically a parallel KS0108 with an ATmega168 based serial backpack attached and only needs 3 pins including the power. It’s not all fun out of the box though as the firmware that is supplied on it isn’t very good at all. Fortunately someone has written a much improved firware, available here. To update this you will need to use an ICSP programmer to flash it with AVRDUDE or WinAVR, this post on the SparkFun product page has details. Unfortunately the ICSP pads on the serial backpack are unpopulated and they aren’t the easiest thing to solder to when the backpack is fixed to the screen. I did it by pushing some wires up from between the two and soldering on the top.

Here is the pinout for the ICSP:

Once the new firmware from summoningdark has been flashed to the backpack you can use the serialglcdlib library here.

Another oddity of this screen is that VIN on the 4 pin header requires 6-7V for the display to work properly but on inspection this just goes to a regulator to feed 5V to the rest of the board so as long as you are providing it with a regulated 5V (eg. from an Arduino) you can just connect to the 5V pad on the opposite side of the board instead.

This is a nice display with a crisp output and good contrast, the 3 wire connection is very handy but on the downside it isn’t cheap, at £27+delivery from SK Pang it’s nearly twice the price of a bare KS0108. Also, unlike with the bare KS0108 it isn’t easy to use different fonts with this display, only two can be used and they can only be changed by compiling them into the firmware when flashing the backpack.

I’ve put some code on GitHub for using this display with an Arduino and RFM12B transceiver as a display for OpenEnergyMonitor.

Adafruit ST7565 Serial 128×64 GLCD with RGB backlight

Another display I’ve been playing with is a ST7565 based unit branded by Adafruit and sold in the UK by Proto-PIC at the great price of only £17.99 It’s the same resolution as the KS0108 displays (128×64) but is slightly larger and more readable in good light without the backlight on. The backlight is where this display differs from most 128×64 displays as it is an RGB backlight, essentially three in one, you have a common anode and a separate cathode for each of red, green and blue, which means you can drive them from separate pins on the Arduino and use PWM to fade and mix the colours giving you a whole range of colours, not just red, green and blue.

To drive the LCD part you can either use the Adafruit libary or the JeeLabs library. The Jeelabs library is an extension of the Adafruit one and is more actively developed, recently having been updated for Arduino 1.0 and has some nice additional functions including support for remote displays that I’ve not looked at yet. It’s also the one that OpenEnergyMonitor use so was the natural choice.

This screen runs on 3.3V so you can either run your whole system on 3.3V or Proto PIC have included a very handy CD4050BC chip which can be used as a logic level converter as described on this Adafruit tutorial.

I’ve been testing this on a 5V Arduino and in order to leave pins free for the RFM12B transceiver and Nintendo DS touchscreen that I am also be using I’ve connected it as follows:

Pins 3, 5 and 6 are used for the backlight as these pins can do hardware PWM which will allow the three colours to be dimmed individually.

The anode for the backlights is connected to 5V via a 270 Ohm resistor

Changes to the JeeLabs library

The JeeLabs library is written for their Graphics Board and if you want to use it with this display on an Arduino you will need to make a few minor changes.

Firstly, in GLCD_ST7565.cpp make sure the defines for the pins reflect what you are using, eg. I used:

#define PIN_SID 0
#define PIN_SCLK 1
#define PIN_A0 4
#define PIN_RST 7

Change LCDUNUSEDSTARTBYTES from 4 to 1 otherwise the display will be off to the right hand side:

#define LCDUNUSEDSTARTBYTES 1

Uncomment the slowSPI define:

// Switch from fast direct bit flipping to slower Arduino bit writes.
#define slowSPI

Change the PAGE_FLIP mode by changing from 0×7 to 0×3

// If the top line is appearing halfway down the screen, try the other mode.
//#define PAGE_FLIP 0×7
#define PAGE_FLIP 0×3

Adjust the contrast to your liking. I don’t think the contrast is as good on this as the KS0108 displays, you can adjust it in the library by changing the badly named st7565_Set_Brightness value in GLCD_ST7565.cpp, the default 0×15 was far too light for me and I settled on 0×19. 0×20 does gives slightly better text but then lines start to appear in the background with some colours.

st7565_Set_Brightness(0×19); // strictly speaking this is the contrast of the LCD panel, the twist on the crystals.

A minor point but the library has been written for a negative display so I reversed the colour defines in GLCD_ST7565.h to it makes more sense for a positive display, this will save some hair pulling later on I’m sure.

#define BLACK 1
#define WHITE 0

My code for using this screen as a display for OpenEnergyMonitor with the backlight colour changing with power usage is also available on my GitHub page.

Using the Nintendo DS Touchscreen with the Arduino

The touchscreen from the Nintendo DS handheld game console makes a good companion to these small GLCDs, it’s slightly larger but this doesn’t matter and you could even use the extra off screen space for fixed (ie. none graphical) buttons.

They aren’t expensive either £5.65 for the screen and £2.51 for a breakout board/connector from Proto-PIC.

You WILL want the breakout board, don’t be tempted to try and solder to the ribbon connector, if you think it looks small in a picture I promise it is smaller in real life.

They are very easy to connect to an Arduino, it connects to four analogue pins and give you an x and y value of the place the screen was touched so you can build button areas by doing something like:

if (y>510 && x<490) { //top left quadrant touched }

There is some good info on using these touchscreens with an Arduino here and here.

The four connections from the touchscreen change purpose depending on which axis is being read, eg. to read the x value you need to put a positive voltage on X2 and ground on X1 the use the analogRead function to get the value of Y1. To read the y value you switch the positive to Y2, ground to Y1 and read X1

I haven’t used pull down resistors as the accuracy is fine for detecting large segments of the screen to use as buttons and not using resistors allows 3.3V to be used and I plan to use a WiNode which is 3.3V for my final build.

My code for the ST7565 display makes use of this touchscreen.

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.

Hard to believe that another one of the computers that had such an impact on my life is now thirty years old, I don’t feel old enough for anything I remember so well to be 30 years ago. After the Sinclair ZX81 and the Spectrum that followed it our next family computer was the BBC Micro Model B, it was an amazing computer for its time and remained in use for many years, I still have the same one today (that’s it on the right).

Made by Acorn Computers for the BBC as part of the BBC Computer Literacy Project it won out over the competition, including Sinclair, to build a computer for the BBC to use as part of its series to educate people about computers. The story behind the battle to win the contract was dramatised in the very enjoyable Micro Men programme that was shown as part of the Electric Revolution season on BBC Four in 2009. If you didn’t see it at the time it is well worth a watch.

Affectionately known as the Beeb, the BBC Micro was a 6502 based 8-bit micro with 16k or 32k RAM depending on the model, it ran at a relatively fast (for the time) 2MHz and it had a proper, robust keyboard, a plethora of connectivity options and a key factor in its success was the comparitively sophisticated BBC BASIC. Unlike most computers that followed it the Beeb also came with a proper manual, a thick ring bound affair that was actually a proper guide to BASIC programming. The Advanced User Guide available separately covered things in more detail including 6502 machine code and even contained a full circuit diagram.

Along with the accompanying television programmes and thanks to most schools choosing the BBC Micro it went on to become the corner stone of computing education throughout the 80s, together with the time then given to computing in the school curriculum it gave kids of my generation a grounding in computers that hasn’t really been seen since.

I spent many happy hours with the Beeb and learnt a lot both in and out of school. These were the days when you were taught how to program a computer at school rather than just operate one as sadly seems to be the case in these days of ICT classes that just teach kids how to use programs such as Word and Powerpoint.

The BBC Micro also gave me my first experience of networked computers, something that would become so important in later life. After one summer holiday we were excited to return to school to find we now had a dedicated computer room full of BBC Micros all networked with econet, much fun ensued and a little good natured mischief (netmess anyone?). A year or so later myself and several friends ran a teletext type information system (using the little known Mikefax software) that was used at open nights and sports days and eventually had a dedicated screen in the school entrance hall. My first experience of publishing information electronically.

The BBC Micro also brought my first exposure to computer communications, first using a 1200/75 baud modem and later a Watford LeModem to connect to local bulletin board systems and services such as Micronet800, Telecom Gold and Prestel (often using dodgy logins aquired from a BBS) and look where that ended up.

As with many of my generation I owe a lot to the BBC Micro and what it taught me and as many others have commented recently, this sort of thing is missing from the lives of most kids these days. Projects such as Coding For Kids, Raspberry Pi and the recently launched Goto Foundation can hopefully do something to help turn this around.