Friday, 18 January 2013

Tiny LED Clock

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

Now that I have finished the new circuit for the old LED clock and that was running nicely, I got to thinking that the ATMega328 used in that was overkill, 18 pins, most of which were unused. I'd gone with that as it was fairly simple to use an Arduino for development. But back in the simple LED clock all it was doing was reading I2C from the RTC and writing it to the LED display using the same I2C bus, and that only took two pins. I decided to have a look at the ATTiny45, an 8 pin device which could do I2C. I rigged up a test circuit with the Arduino ISP programming the ATTiny45 (using the approach suggestedby high-low tech).
It looks a bit like an ode to the flying spaghetti monster, but basically, the orange wires are the ISP connections from the Arduino, running the ArduinoISP project (the capacitor is needed on UNO boards to stop the Arduino resetting). The rest are the black and red of power and the white and green and the I2C clock and data to the Adafruit RTC module and LED display. It all looked promising until I clicked build, as unfortunately the wire library used for I2C comms on the Arduino isn't supported on the ATTiny range.
I found the TinyWire library, which did provide I2C support on the ATTiny range, but the RTC lib and the Adafruit display libraries used wire and didn't work. The example which came with the TinyWire actually used the DS1307 RTC, but just made the call to read and processed the BCD response in the main code. That approach was all I really needed there for the RTC. The display was more of an issue as there I couldn't used the Adafruit library code. However, I had found a slight issue with that. Only slight, it only had a problem between 23:59 and 1:00. Basically the time is converted into an integer as hours x 100 + minutes, so 23:59 is just 2,359. The trouble comes with midnight. This adds up to 0 and so the display just shows '  :  '. A minute later we get '  : 1', nine minutes after that we get '  :10', and so on until '  :59' is finally followed by ' 1:00'. So I decided I could get around that be extracting the bits of the library I needed and converting them to use TinyWire rather than Wire, and in the process ensuring I left leading zeroes where required.
So finally, I ended up with a very simple circuit, but more complex software. I made the finished board the same size as the LED display, which sits on top. I could have used a smaller button cell, but the CR2032 is ubiquitous, and I had spare holders and cells, and it just fitted in the space. The only other components are the decoupling capacitor, pull up resistors for the I2C bus and the 32.768KHz RTC crystal.
One downside to this approach was not being able to set the RTC without writing mode code. I went with the easier option of installing the battery, then wiring up the I2C bus (without the ATTiny45 installed) via the display connector to an Arduino. This ran some simple code which set the RTC to the PC clock. I then disconnected that, installed the ATTiny45 and the Adafruit LED baclpack and the unit was complete.
I've wired this to a USB cable, and it now shows the time next to my PC. When the PC is off, the power to the USB goes off and so does the display. The RTC maintains the time thanks to the battery, and next time the PC is switched on, on comes the display with the right time on it.

Sunday, 6 January 2013

LED Clock Part 4 - The Finished Product

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

Following on from the previous articles on the LED Clock (a simple replacement and a teardown of the original clock and a more complicated replacement), the parts I ordered from CPC have finally arrived, I've now finished the replacement unit. And here it is.
OK, so it looks like the original. Well yes and no. Yes, it does look like the original, that was the intention. However, it is now a 24 hour clock and the time is derived from a battery backed real time clock. The colons now flash at 1Hz, previously they were on continuously - the TMS3450NL chip on the original clock does have an output to flash the colon, but the designers decided not to use that and wired them permanently on.
Inside it looks different. The original display has been reused, but this now has a row of pin headers and plugs into a new board which contains (from left to right) the CR2032 battery for the RTC, the two MCP23008s to drive the common anodes, the ATMega328P microcontroller and the DS1307RTC. Here it is with the display removed.
On the bottom right are the two common cathode drive transistors and the power supply circuitry. The original transformer wasn't ideal so I've replaced it with one of a similar size (and vintage), with a very simple rectifier, capacitor and 78L05 based power supply. More than enough to supply the 60mA it uses.

The pin header on the left pokes out of the side of the clock, where there used to be a slide switch. This allows the 'Arduino USB2Serial light' to plug in to reprogram the unit, or to set the time.
I could have just gone out and bought a new clock, but that would have been too easy. This has been an interesting project, and I'm happy with the result.

Saturday, 22 December 2012

LED Clock Part 3 - Display Multiplexing

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

Recently I've been looking at replacing the circuit in an old LED clock that finally gave up after 30 years faithful service. Previously, I've looked at a simple replacement and a teardown of the original clock.

Having now given up on CPC supplying the LED displays for the replacement circuit (I'm told they're due sometime in January), I've decided to look at reusing the original display. It's unusual as most LED displays these days are sealed units, where as this one has LED chips on a PCB with a white frame around that and a red diffuser on top.
You can just see the some of the segments are lit, they're just washed out by the camera flash. The method of driving is also unusual and is one of those circuits that I just don't think anyone would design like that these days.

Traditionally, you have two options to drive a 4x7 segment display, either directly drive each segment from an IO pin via a current limiting resistor, or multiplex the display digit by digit. The former option requires 4x7 = 28 IO pins and current limiting resistors and all segments are connected to ground. At 10mA per lit segment, it would use 280mA worse case. The later saves both pins and power, at the expense of more complicated software. The segments are all wired in parallel, but the grounds are switched per segment. So for example, although all the top bars (segment A) are driven from the same IO pin, only one of them will be switched to ground at any time. So the loop is:

  1. setup the output for the first digit, 
  2. turn the first digit on (the display now shows 1_:__) 
  3. wait a set time, 
  4. then turn off digit 1 
  5. setup for digit 2, 
  6. turn on digit 2 (the display now shows _2:__)
  7. wait...
  8. and so on
If you do this fast enough (usually > 50Hz), persistence of vision takes 1_:__, _2:__, __:3_ and __:_4 and merges them, so you see 12:34. This only need 4+7 = 11 IO pins, 7 with current limiting resistors for the segment anodes, and 4 with drive transistors to control the common cathodes. The power is also reduced as only one digit is ever on at a time, so the worst case is only 70mA.

The display on this clock was sort of an unorthodox mix of the two. Rather than 1 phase for each of the 4 digits, this has only 2 phases, each of which controls bits of each digit. There are no current limiting resistors as the IO pins of the TMS3450 are current limited at 18mA. The common cathode drive transistors are also missing as it makes use or a rather neat trick, but one as I said, I don't think anyone would come up with these days. What it does is use the ac from the transformer which already alternates at 50Hz, fed via diodes, so that on each cycle of the mains, one of the common cathodes sinks current as it's on the negative cycle. The other is on the positive cycle, so the diodes are reverse biased and therefore off. The flickering of the F segment on the hours I used to see occasionally must have been due the timing drifting slightly out and this being set before the phase cycle was complete.

I've slowed down the cycle. Here is phase 1:
And here is phase 2:
When switched fast enough, you get the combined result:
So, can I drive this from my microcontroller? Yes, it's just a case of providing 14 io pins for the segments and 2 drive transistors. I used MCP23008's for the segments, one for the hours and one for the minutes. The colon and the common cathode transistors were driven direct from the ATMega328P. I added a DS1307 real time clock, as per the simple version, and here it is, the slightly more complicated LED clock:
The next step is to build that up on veroboard and install it in the original case.

On to part 4, finishing the LED clock

Wednesday, 12 December 2012

LED Clock Part 2 - Teardown

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

I am working on a more complicated version of the 'Simple LED Clock' in my previous post, however this is currently delayed as CPC has messed up my order again and I'm still waiting for some of the parts I ordered. So the prototype is currently using 2 MCP23008's to drive one digit each:
Whilst I'm waiting, here's a look inside the original 30 year old clock.
Inside there's a lot of space where the radio used to live.
It's a three board construction
With one for the top buttons, one the logic board with a single IC and finally the display
The chip is a TMS3450NL, and the date code (32nd week of 1983) seems to fit with the 30 year old estimate.
I have managed to find a scanned datasheet for the chip:

After all this time of putting up with a 12 hour clock, I find that not only did the display have sufficient segments to display 1 and 2 (but not 8), the chip supported 24 hour mode, it just needed a pin shorting to ground.

On to part 3 - more on display multiplexing.

Friday, 7 December 2012

Simple LED Clock


This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

For the last 25 years or so, I've had an old LED bedside clock by my bed. It was discarded by my parent's after they'd used it for a good few years as the radio broke, so is probably about 30 years old in total. I think I fixed the radio, but I never used that anyway, At some point, I replaced the alarm-triggered radio with a relay to turn on first a light and later (ironically) a radio. But for most of those years, it simply stood there with 3 1/2 seven segment led displays showing me the time.  It was a 12 hour clock with an LED to indicate PM. I personally prefer a 24 hour format, but I put up with that as I suspect the leftmost digit can only display a 1 (i.e. is missing the segments to do 20:00). Also a couple of the segments occasionally flicker at half brightness when they are meant to be off, but again that wasn't a major issue.
It's been pretty solid for all those years, I hardly ever had to adjust it, twice a year to add or remove an hour for summer time, and the occasional tweak to the minutes, and of course resetting it after power cuts. I suspect it used the old school technique of counting the mains 50 Hz cycles. Whilst it can vary by a few Hz, it is (or at least used to be) guaranteed to average out to 50Hz over 24 hours. So clocks like this one just filter the ac from the mains transformer, and every time they count to 50 increment the seconds counter.

However, last week I noticed it was out by a few hours. I readjusted it and later found it was out again. It seemed to be ok for a day or two, then I was it was about 6 hours out again. I reset it and then saw it was incrementing the minutes about every 30 seconds! A quick check with a meter showed the mains frequency was 49.95Hz, so it couldn't be that. At this point, I decided it might be time to replace it.

I have designed and made a number of clocks over the years, many using a 40 pin PIC (16F874), multiplexing the displays with a high side driver (ULN2803) an open collector driver (7407). I also liked to use tri-colour LED's which faded through the colours from red to green as part of the display multiplexing.
However, it seemed only right that the replacement for this should be fairly plain red 0.56" 7 segment displays as before, nothing fancy. There were two main elements to deal with, the clock and the display.

The PIC based ones main clock was derived from a 4.194304 MHz crystal which can be divided that down to get a 1 Hz counter (4194304 = 2^22). For this, I'd decided to go for the easier option and use one of the DS1307 real time clocks. This should have sufficient accuracy and a battery backup. This is a nice simple DS1307 module from adafruit.

I went through a few designs for various display options, the favourite using I2C IO expanders (MCE23008 or MCE23016) with direct drive. I finally went for something even simpler. An I2C controller 4x7 segement display module, also from adafruit.
Building up the circuit with an Arduino and the two I2C modules was embarrassingly simple, 8 wires in total!

The code with then almost trivial as well. Ask the rtc what time it is, update the display. sit around doing not very much for a while. Then start again. I went back and added a 2 Hz flash of the colon so that the Arduino didn't get too bored.

I didn't even bother with setting buttons as the adafruit library made it easy to sync the RTC to the PC time, and because of the battery it maintains that time. The date is also set (although not displayed - something I might think about for the future?) so I could expand the code to adjust for daylight saving.

So there it is, about as simple as I could make it. Lets hope I get 30 years out of this one!

Onto part 2 - a teardown of the original LED clock

Saturday, 27 October 2012

Raspberry Pi as a Subversion Server

This is an old post, preserved for reference.
The products and services mentioned within are no longer available.

We hit an issue with a client I was doing work for that required a subversion source control server. Up until that point, I'd been working at home using svn on my ubuntu server for source control. When this work was moved into their office, I transferred the repository from that server to the machine I was working. There was no suitable server available at their office and at that point I was the only developer working on the code.

Now they've taken on a graduate developer to also work on the code and it's not really practical to rely on the server on my dev machine. There is a NAS available, but although it looked at one point that it should be able to run subversion, the minimal linux firmware on there was sufficiently broken to stop us installing subversion.

So we were looking at taking the drives from the NAS and building up a linux server. Then a bit of lateral thinking led to the idea of using the raspberry pi as a server. The pi was setup with the latest version of raspian with the memory split as 240 MB / 16 MB as it is running headless.

CIFS was used to mount a folder on the NAS to hold the repositories and subversion setup. The pi only needed a LAN cable and some power. The repositories were migrated from the dev machine to the new shared Raspberry Pi SVN server and away it went.


So, I've finally found a use for a raspberry pi. I had lots of ideas when I originally ordered them on release day earlier in the year, and several more whilst I waited for them. However, when I finally received the original 256 MB model B Raspberry Pi boards, I was a bit disappointed. There were a few practical issues, like the lack of mounting holes and the connectors sticking out on all sides and the USB connector not being level with the LAN magjack. There are ways around those (see mounting details inside a ZX81 here), but the main issues were the low memory size and the lack of hardware mpeg decoding. And finally, the early recommended distributions were a bit flaky.

Now, things are a bit different. The model B is shipping with 512MB, and some mounting holes. Raspian is looking a bit better and there are options for licensing the mpeg decoder. So with a new one on order, hopefully some of the original ideas might now be possible. Watch this space!

Friday, 10 August 2012

Ikea's record breaking shelves

Oh dear, after several years the Ikea Lack shelves have finally given up.....