Last Christmas I bought a Velleman MK170 Christmas Star project for my Wife to build. She often shows interest in my various electronics projects and I thought it would be a good way for her to build something that she could show off to friends and family, whilst at the same time teaching her a thing or two about electronics, components, and soldering.
After the build was completed we connected it to a 9V D.C. supply, as instructed by the documentation, and…
I was quite disappointed! The project was definitely functional, but the display was extremely dim and underwhelming. At first I was convinced we’d done something wrong during the assembly, but nope; everything was as it should be!
The camera flatters the result. To the naked eye the brightness of the LEDs is completely unsatisfactory.
I decided to revisit the project for this year. I downloaded the schematic from the Velleman website, and took a look to see what was going on.
Looking at the schematic (click the image for a larger version) you can see that we basically have three sets of LEDs, each of which is split into sub-groups of series and parallel LEDs.
Now, one thing that jumps out straight away is the value of the series resistors; they’re HUGE!
Take, for example, the series chain consisting of LED1, LED2, LED3, LED4. I measured one of these individual LEDs and they don’t even begin to conduct until ~1.7V. So to work out the current through these resistors we have:
(9V – (1.7V * 4)) / 2200R = 1mA!
I looked up the datasheet for the LEDs and I found that the typical forward current should be around 10mA. Practical tests showed that these LEDs conduct 10mA at around 2V forward voltage.
So, to work out more appropriate resistor values:
Four Series LEDs
For the chains with four series LEDs, the forward voltage drop will be 2 * 4 = 8V.
This means the drop across the current limiting resistor will be 9 – 8 = 1V. In order for 10mA to flow, we’ll need a 100R resistor.
100R!! The 2k2 resistors that Velleman fitted are not even in the ball-park!
Two Series LEDs
The same process can be used to determine the appropriate value for the chains with two series LEDs. The drop across the resistor ends up being 5V, so you need around 500R for the current limiting resistance.
I really don’t know what Velleman were thinking with this project. Their choice of current limiting resistor values are way off. I can only imagine that their intension was to reduce the current down to the absolute minimum, so that the project could be powered by a standard PP3 battery for relatively long periods of time.
That’s all very well, but the result is a project with totally unsatisfactory LED brightness.
I changed all the resistor values on ours, and now we are able to show off the project along with all our other Christmas decorations.
The current consumption on my unit, after my modifications, is 120mA when all LEDs are lit. Not all the LEDs are lit all of the time, but I guess it would be reasonable to assume >90mA average current consumption.
A standard 9V PP3 battery is going to be wasted very quickly at this current consumption. I would estimate 1-2 hours use before the battery drains flat!
That’s probably why Velleman used such high resistor values. But my take on this is that it was a poor design decision to build the project around a PP3 battery in the first place. These batteries have very low capacity, so they were on to a loser from the beginning.
We are powering ours from a 9V DC adaptor, which is the only realistic way forwards for a project like this.
Recently I was asked to produce a circuit to create a variable ‘dim’ control for an existing LED based exhibition.
I decided to go with a simple 555-timer based design which provides control of the pulse width of an output, whilst keeping the oscillation frequency fixed.
The circuit is shown below. It’s an unusual design, because the output is taken from pin 7. This ‘output’ is not capable of driving current (at least not without affecting the circuit behaviour) so you have to be careful with the connections you make to it.
The circuit works because of some very simple rules:
When pin 7 is high, the output pin (3) is low.
When pin 7 is low, the output pin (3) is high.
Pin 7 will be high when the trigger/threshold pin is > 2/3 of VCC.
Pin 7 will be low when the trigger/threshold pin is < 1/3 of VCC.
When the circuit is first powered on, pin 7 is low because C2 is discharged. This causes pin 3 to go high, and C2 begins to charge via D1. When C2 reaches about 2/3 of VCC pin 7 goes high, causing pin 3 to go low. Now C2 discharges through D2 until its voltage falls below 1/3 of VCC and then the cycle repeats as an oscillation.
The resistance in the charge and discharge cycles is controlled by RV1. When the resistance is increased for the D1 side of RV1 the resistance falls by the same amount on the D2 side of RV1. This changes the relative ‘speed’ of the charge/discharge cycle, which has the practical effect of pulse width adjustment.
Since the total resistance of RV1 (for the total charge/discharge cycle) is constant, the frequency of the output is stable and is determined by the values for RV1 and C2.
The frequency of the output is governed by a simple formula:
FREQUENCY = 1.44 * RV1 * C2
The power switch is a PMOS FET. It controls the switching of a 12V feed onto the existing LED array at the exhibition. RV1 is adjusted to provide the desired brightness for the display, and LED D3 provides an indication of the level of ‘dimming’ that the circuit is currently providing.
The circuit oscillates at 100Hz, so there is no perceived flicker.
A few years ago I created a little valentines day project, shown in the video at the end of this post. It’s basically just a multi-vibrator circuit with two groups of LEDs, arranged as an inner and outer heart:
The full schematic is shown here, click on it for a full enlarged display:
Finally, if you want to download all the project information, you can get it here. This project is considered to be in the public domain.
I’ve thought about doing a new version actually, with micro-control of the LEDs for brightness fade in/out etc.
I completed this design a number of years ago when I was still learning to program. In fact, this was my first “proper” project that I directed my new-found programming skills towards. My programming skills have improved by many orders of magnitude since, and with that in mind I was a bit ambivalent about whether to put this project up on my site. I only like to showcase my best work, and although this really was my best work back in 2009, it’s nowhere near up to my current standards.
That said, I constantly find myself receiving emails from people who want to have a copy of the code and/or PCB design files. It seems I’m not the only one who is intrigued by IR communication methods.
I have therefore decided that I will publish this old work on my site for the benefit of others who are also learning. The information is a literal copy of the original article I wrote for a very old version of my website, back in the days when I used to hand code the HTML. I have simply copied and pasted the information into this post.
The code for the LCD and the RC5 decoding is mixed in to one C file, although obviously they are separated into their own relevant functions. These should ideally be made into their own libraries, particularly the LCD code. I have in fact used the LCD code in other projects and during that time I have made huge improvements to it and I’ve made it into my own library. The LCD code provided in this project is basically a skeleton solution, suitable for this particular application but not a lot else.
In practice I found this version of the LCD code to be a bit hit-and-miss. It works fine with the LCDs stated in the BOM, but when I tried it with other LCDs it sometimes worked and sometimes didn’t – so bare that in mind.
The RC5 decode solution provided here analyses the RC5 data stream in real time, bit-by-bit, as it is received by the IR receiver. There is some error detection that throws out the stream if it is not deemed to conform to expected RC5 standards, but you might want to have a play with this. In practice I found it to be reliable with a number of different RC5 remotes.
A better solution to this problem is to do a post-analysis on the received data. That is the technique being employed by version 2 of my RC5 decoder, which is currently in development as a kind of side project that I work on every now and then.
The IR receiver listed in the BOM is very important because it filters out ambient noise. The code relies upon that. If you try to use a simple IR LED to detect an RC5 stream you will experience noise problems because the code is not designed to account for it.
RC5 Decoder V2 is in development!
It should be noted that there is an RC5 Decoder V2 in development. The new version will receive remote control data streams and provide post-analysis of the data. This is an improvement because it will allow the project to decode other protocols as well, simply by adding new libraries. Also, the LCD code has been significantly improved and broken out into a separate library. The V2 version, when released, will be published on this site.
RC5 article from old version of brianhoskins.uk follows
What follows is an article I wrote for the first version of my website that details the RC5 decoder development, provides explanation, and also provides all of the design files you’ll need to repeat my work.
What is an RC5 Decoder?
If you’re a computer geek, you might think I’m claiming to have built a project that decrypts the RC5 block cipher. I wish that were the case, and indeed if it were I’d certainly be earning a lot more money than I am now! But alas, this project refers to a much simpler idea – the RC5 protocol for wireless (infra-red) communication. If you’ve used a television remote control before, then it’s quite possible that you’ve used one that transmits RC5 coded commands. In that case your television will be acting as an RC5 decoder; receiving the infra-red data stream from your remote control, decoding it and acting upon the command it has received.
The project described here can receive an RC5 coded infra-red data stream, decode it, and display the address, command and toggle data on an alpha-numeric LCD.
What is the point of this project? Well for me it was an educational experience. I had been busy learning assembly and C for PIC Microcontrollers and, whilst I had already written a number of experimental programs to help with my education, this was my first attempt at a complete microprocessor based project. Thus, this project served no other purpose than academic value. In practice, though, you could use this project in any application that requires remote control of equipment via infra-red communication. I have used my decoder firmware to display information about the commands that were received, but the project software could be easily modified to act upon the commands that are recieved and control practically anything you want with it. If you do create something useful/interesting with this project, please let me know!
The heart of this project is based upon receiving and decoding an RC5 data stream. So, I guess the first question to ask is: “what does an RC5 data stream look like?” A second one might be: “how does it work?” and a final one would be: “how can I decode it?”. These are all questions I had to ask of myself before I could come up with a working design, and hence this section shall answer those questions.
What does RC5 look like?
Firstly, to find out what an RC5 data-stream looks like, you can employ one of two techniques. Either you can try to find some written reference to an RC5 data-stream, or you can try to measure one. I did both. For written references, google is your friend. You will find that I am not the first Electronics hobbyist to try to decode an RC5 data-stream – far from it in fact. Plenty of other Engineers/hobbyists have done this before! That said, I haven’t yet found anyone else who has designed a solution using the C language so if C is your poison you’ve probably come to the right place.
If you do take the time to trawl google results you’ll probably do well to find a diagram better than this one:
This diagram was found at davshomepage and I think it is a good rendition of the RC5 protocol. This particular diagram is showing the following information:
Start Bits: 11 (these are always logic 1)
It also clearly shows the timing for a single RC5 encoded bit, as well as the timing for one full transmission in its entirety. If the logic levels look a bit weird to you, it’s because they’re Bi-Phase (Manchester) encoded. We’ll get to that later.
So that’s pretty much answered the first question, “what does RC5 look like”, but just for completness I’m going to show you what it looks like if you try to measure it. In order to do this experiment, I purchased an IR receiver device sensitive to 36Khz (because RC5 uses 36Khz modulation) with a demodulator built inside. You can receive the stream using a simple photodiode if you want, but then you’re going to have to demodulate it and you’ll need to concern yourself with other problems such as gain control and noise reduction etc. You can buy very small modules that have all of these features built in, so my opinion is why burden yourself with the hassle? Don’t reinvent the wheel, life is too short! The little module I used was a TSOP2236 which you can buy readily from Farnell.
All you need to do to start experimenting with one of these devices is to connect it up to a power supply and you’re good to go. If you read the datasheet it’ll start telling you about using pull-up resistors and connecting some capacitive filters etc, which is all very relevant and important to include in your final design but for the purpose of just playing around and experimenting you don’t need any of that stuff – power connections are all you need to do.
So, with some power connections made (I’d show you a picture but what’s the point – it really is that simple) we’re ready to receive an RC5 data stream. All we need now is an RC5 generator. For this I used an old Philips Universal Remote Control set up for TV and VCR modes. Philips designed the RC5 protocol, so most of their older equipment uses it. I also experimented with a universal remote application for Windows CE and that worked fine as well. You need to be a little bit careful here because your IR receiver package will receive your datastream regardless of the protocol – it won’t care whether it’s RC5 or not. It’s easy to recognise an RC5 protocol though, just compare it to the diagram on the previous page, paying particular attention to the start-bits and the number of bits in total. The data stream should also be Manchester Coded (or bi-phase coded, same thing). What’s Manchester Coding? We’ll get to that in the next section.
So, with the RC5 generator to hand and my IR module connected up to a power supply, I just need to press a button on the remote control and the IR module should recieve the infra-red light, demodulate the data stream, and output a manchester coded packet of data on its output pin. To see this, we need to connect the output pin to a Digital Storage Oscilloscope. If you don’t have one of these then you’re not going to be able to do the experiment yourself, but you don’t really need to unless you’re particularly interested – just check out my results on the next page!
This is what an RC5 Data Stream looks like if you measure it. I captured this shot using the Single Sequence Aquisition mode on my Tektronix DSO. To generate the RC5 I used an old Universal Remote Control set to VCR mode. I happen to know from previous experiments that a VCR remote is assigned Address number 5, so if you decode this stream (I’ll show you how next) you’ll find that the address is indeed 05. Also, I pressed number “8” on the Remote and, again from previous experience, I have found that the numbers 0 – 9 on the keypad are encoded as Data 00 – 09 respectively.
San Bergmans has compiled a small list of some RC5 codes on his website here. The list is by no means exhaustive, but it gives you the general idea. In addition to San’s listed codes, there are also codes for satellite receivers, CD players, and lots of other stuff. I have found through my studies that the RC5 protocol is not fully populated (i.e. not all of the possible addresses / commands have been used) so it is possible to make up your own little address and command codes to control your own equipment, without fear of inteference with other commercial products.
San’s site is also a good reference if you’re hoping to learn more about the RC5 protocol or indeed any of the other Remote Control protocols that exist!
This shot is merely a close-up of the data on the previous page, using the zoom function on the instrument. The zoom function is quite handy for seeing the fine details of your aquisition, and I used it here to zoom in on one single bit of the Manchester encoded data.
The RC5 protocol specifies that one single bit should be 889uS long but in practice, with my Remote Control, I found that it actually measured 812uS (see the cursor readings on the right hand side of the image), which is approximately 10% outside of that which the protocol specifies. This has implications for the design of an RC5 Decoder, because it means that the system will need to measure the length of a single bit of the encoded data, to account for inaccuracies in the RC5 generator. Thanks to Manchester Encoding, this is actually quite easy. The whole point of Manchester Encoding is that it is self-clocking. This is what I’m going to talk about next, and in the process of talking about Manchester Encoding it’ll become clear how the RC5 data can be decoded.
How do I decode RC5?
Now, to answer that question it’ll be necessary to talk about Manchester Encoding. Once the details of Manchester Encoding are understood, it will then be quite a simple task to analyse an RC5 stream and see how it might be decoded. We’ll do this later using the stream I captured on previous pages, and see if we do indeed arrive at Address: 05, Data: 08. Once all of this has been understood, we are then presented with the problem of how to accomplish the decoding task using an Electronic solution. I came up with a software based solution which I shall present later on!
Before I get into Manchester Encoding, I want to illustrate the problem that arises when your data stream is not Manchester Encoded.
Usually, digital data communication requires at least two separate lines – clock and data. The clock line is required for synchronisation purposes, so that the receiver knows when to sample the incoming data. For example, suppose I were to transmit an 8-bit data stream comprised of the data, “10001100“. This data stream might look something like that illustrated below:
Now, it’s not immediately obvious that the data above is equal to 1001100 is it? That’s because you don’t know where the data starts or where it ends, or even how long a single bit is. It would seem that the first logic 1 is a single bit, but how do you know? It could be 1, 2 3, or any amount of bits long. And, if we accept for the moment that it is 1 bit, then is that a logic 0 at the start? Or does the data start with the logic 1? And where does it end – how many logic 0’s are there on the end of that stream?
To make matters worse, what if I were to transmit 00000000? That’s a perfectly valid data stream, but without any kind of synchronisation technique (a clock) your only option for data recovery would be to agree a communications speed up-front with the transmitter. In fact, some communications protocols do exactly that! RS232, for example, relies upon us both agreeing – transmitter and receiver – that we’ll talk at a certain BAUD rate before we can exchange any data. After we’ve agreed the BAUD rate, we each have to trust the other’s internal clocks to be stable and accurate, so that 9600 BAUD means the same thing to me as it does to you. Communication in this manner works for small data packets.
In regular wired data communication busses, a clock line is normally included so that you know where to sample the line in order to recover the correct data. Data is either sampled on the rising edge or falling edge of the clock, depending on how the system has been designed. To illustrate a rising edge system, see the diagram overleaf which shows how the above signal could be sampled and recovered using a clock signal.
Recovering Data with a clock
The following diagram shows how the previous data is recovered using a clock signal:
With the addition of the clock signal it is suddenly easy to reconstruct the data. Data is only sampled on the rising edge of the clock line, and in this manner the original data (10001100) is correctly reconstructed.
Manchester Encoding – A Self-Clocking Communications System
In order to get around the problems caused by long strings of logic 1’s or logic 0’s, where there is no clock to aid data recovery, a clever person came up with Manchester (also called binary phased shift) keying. I’m not actually sure who that clever person was – answers on an email!
In Manchester Coding, logic 1’s and logic 0’s are no longer represented by simple high and low voltages. Instead, they are represented by a rise in logic level and a fall in logic level respectively. This is illustrated below:
Note that in some systems this is the other way around – a logic 0 can be represented by the low to high transition and the logic 1 by the high to low. It depends how the system has been designed.
To see how this method effects the previous transmission data 10001100, the data below has been generated using Manchester Code logic levels:
If you trace through the above diagram, you should be able to see that the original logic 1’s and logic 0’s are represented by low-high and high-low transitions. If you’ve understood this correctly, then a little further thought should convince you that the problematic data stream described earlier (00000000) would now be transmitted as a long string of high-low transitions under the Manchester Coding scheme. The clock signal is easily extracted from a manchester coded transmission, even when there are long periods of logic 1’s or 0’s! Also, the start point and stop point of the transmission is more easily determined.
For these reasons, a Manchester Coded data stream is often refferred to as “self clocking”. No separate clock line is required under this scheme.
The other day I stumbled across an old Nokia mobile phone sitting helplessly in the drawer. It’s not really that old, but already it’s pretty useless in terms of what we expect from a mobile phone in this day and age. What should I do with it? Throw it away?
No! What self-respecting electronics nerd would throw away a piece of kit with all those useful bits and pieces in it? Surely we can make use of some of those parts? What can we do with that GLCD, for example?
I took the phone to bits and robbed the GLCD from it to see what I could come up with.
Find the info!
First of all, I need to find a pin-out for that LCD. I found this really useful website that details the pinouts for quite a number of Nokia LCDs. The pinout I was interested in was this one:
Next I needed to find some information about the controller chip on the LCD. I found from the website that the LCD uses a SED1565 controller so I downloaded a datasheet from the controller from here.
Write some code!
I connected up the LCD using the wiring diagram above and I strapped the SPI bus of the connector to the SPI bus of a PIC micro. Now it’s time to write some code! If anyone can show me a decent code snippets plugin for wordpress that would be great. All the methods I’ve tried suck eggs. Here’s a link to the sourcecode instead. Open it in Notepad++.
After much testing and hackery, I managed to communicate with the GLCD. Here are the results!
For copy of the c code, see my repository on github: https://github.com/bh4017/nokia7110-glcd/