Posts

Happy Pi Day!!!

Pi Pie ready for baking

Pi Day is traditionally held on 14th March to celebrate the irrational number π – 3.14159265. π is the ratio between the circumference : diameter of a circle and cannot be expressed as an exact fraction. It is also a transcendental number. I have often thought long and hard about these kinds of numbers and they fascinate me. It is truly amazing that no matter how accurately you try to express a number like π, it can always be expressed to an even greater accuracy again. It makes you wonder… what is the smallest fraction possible in nature? Surely there must be one? Yet π can be calculated to an indefinite decimal representation, it would seem. This means that in nature there can never be a “perfect” circle.

A friend of mine, Emma Constantine, helped me celebrate Pi Day by baking this gorgeous Raspberry Pi Pie. And very tasty it was too!

It will now be my turn to reciprocate on 22nd July, which is the day us number geeks get to celebrate Pi Approximation Day. 22/7 is a commonly used approximation for π in mathematics.

I’m going through a bit of a rough time in my life at the moment, which has necessitated a kind of self-personality reboot. I’ve been forced to take a long, hard, honest look at myself in the mirror and make some real life changes. I’ve discovered who I really am, and although there are a lot of things about me that I really like, I need to make some significant changes if I’m going to become the person I actually want to be.
In his book, Sam Harris proposes that all forms of lying, even the little white lies, are dangerous, damaging, and promote ill-fated poor relationships with other people. I think he’s right and, on reflection, it is the very act of ‘lying’ that caused my life to self destruct and triggered a domino of consequences, the biggest and most damaging of which was the breakdown of my marriage to the most important person in my life. If only I had been completely honest, mainly with myself, then I could have prevented my self destruction and my marriage would never have been placed in jeopardy.

Sam Harris makes a lot of interesting observations in his book, which have caused me to take pause and consider the lies I tell on a daily basis. Most people tell some lies each day, I think. Some more than others. But Sam puts forward a good case for rejecting the urge to lie (even the white lies you may tell to avoid embarrassment or offence) and to put your trust in the open and honest truth, instead.

How would your relationships change if you resolved never to lie again? What truths might suddenly come into view in your life? What kind of person would you become? And how might you change the people around you?

Introduction

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.

Known Problems:

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.

Why?

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!

RC5 Explained

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:

RC5 Protocol provided by davshomepage

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)

Toggle: 0

Address: 00000

Command: 000001

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!

Zoomed into one bit of RC5 data.

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!

Manchester Encoding

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.

It was a right pain in the backside converting from a locally hosted site to a server hosted one. I wanted to be able to just copy all my local files over to the server and job done, but that so wasn’t the case. Eventually I discovered the export and import tools, but even they were far from fool-proof. Lots of things were still not working even after I’d imported my local site content and copied the modified child theme across. That part of wordpress sucks. But, it’s up now and the site is mostly working! I have noticed a few more niggly things that I want to change though, so I’ll have to delve back into the php code another time to change those.

Pendine Sands, 13th and 14th August 2011

Introduction

The famous Campbell family have been using the long stretch of flat sands at Pendine beach in West Wales for record attempts since 1924, and the weekend of 13th/14th August 2011 continued this trend as Don & Joe Wales (Grandson & Great-Grandson of Sir Malcolm Campbell respectively) used Pendine to attempt a new land speed record for their Bluebird Electric vehicle. Their ultimate goal is to break 500MPH in an electric powered land vehicle.

DOC Members Set Up!

DOC members set up the event at Pendine Sands

I attended the event as a marshall with the Discovery Owners Club. It was our job to set up the event, patrol the measured mile to ensure that it was safe (free of pedestrians!), provide radio comms for the Bluebird team and to ferry members of the press and the Bluebird technical team safely to and from the beach. In the end over 25 members of the Discovery Owners Club volunteered for the event, providing their own time and use of their own vehicles to ensure the event’s success.

Saturday’s Runs

The Engineering team work on the Bluebird

Saturday’s runs were blighted by poor weather conditions, but the Bluebird team made the best of it with a number of exploratory runs that provided useful data for the team and an opportunity for Joe Wales to gain some experience behind the wheel, as it was only the second time the 19 year old had ever piloted the vehicle. Don Wales was keen to give his son Joe as much time behind the wheel as possible and an opportunity for him to enter the record books for the first time.

I had a pretty quiet day on Saturday as I was posted to the East-end frontier for patrol duties. We were basically there to provide radio comms to base, to ensure that no members of the public entered the measured mile area from the East side of the beach, and also to serve as a clear ‘end barrier’ for the Bluebird team. This was important because the East-end is also used extensively by the military for firearms practice. There were no planned firearms sessions that weekend but you can’t be too careful!

Sunday’s Runs & the Crash

Sunday’s blue sky put everyone in good spirits and we were all hopeful that a new record would be set. The Bluebird Electric car is theoretically capable of speeds in excess of 500MPH, but the conditions would need to be absolutely perfect in order to achieve those kinds of speeds at Pendine sands. This weekend the team hoped to break 150MPH, which would still have set a new record for that class of vehicle. The record attempts are measured over an electronically timed mile of flat sands. The final recorded speed is taken as an average of two runs; once up and and once back. This is to cancel out any effects associated with wind speed or land incline. The vehicle must make its return run within 60 minutes otherwise the record attempt is rendered void. This presents a big challenge to the team as 60 minutes is not enough time to fully recharge the vehicle’s batteries, so it is necessary to regulate use of the batteries on each run in order to optimise the recorded speed.

The day started well with Don and Joe making some exploratory runs of the mile. I had a busier day on Sunday as I was assigned to press duties, ferrying camera crews back and forth to give interviews. By 3PM I was exhausted as I hadn’t even stopped for lunch, so I parked up at base for a little bite to eat. Then, just as I began to chow down on a well deserved bacon roll, an emergency call came over the radio claiming that Bluebird had careered off course towards the sea at over 100MPH and crashed in the wet sand! This was very bad news as, being a very flat beach, the tide comes in very quickly at Pendine. The condition of the driver (Joe) was also unknown at this point.

Bluebird breaks a steering arm in a pothole

At this time I happened to be parked right next to the recovery trailer, so I wasted no time in hitching it up and claiming the recovery duties for myself! I sped down the measured mile, recovery trailer in tow, and soon reached the crash site where it was clear that Bluebird had strayed into the bumpy wet sands and crashed into a pothole. Joe, the driver, was already out of the vehicle and was fortunately unharmed.

Bluebird Recovery & Brian sets a record!!!

Me recovering the stricken Bluebird from the wet sands at Pendine beach

The Bluebird team worked quickly to remove the vehicle from the pothole and I had the pleasure of recovering it back to base. During my recovery I managed to set a record for the weekend’s slowest time through the measured mile at 8MPH!!! But, since there has never been a record set for a Land Rover towing a Bluebird, that makes it an official world record as far as I’m concerned!

Unfortunately the vehicle had suffered quite extensive damage to its steering and suspension components, which meant that the team could make no further runs for the weekend.

The team were disappointed with the crash but were able to take away a lot of useful data from the weekend’s runs. Joe Wales also gained lots more experience behind the wheel of the Bluebird. The Bluebird team conceded that the cockpit area could do with some modification to improve visibility, as currently it is difficult for the driver to see where he (or she) is going – especially on Pendine sands where there are few points of reference. For the Engineers it is always a trade-off between visibility and aerodynamics.

The team will now continue development of the vehicle (which is done with the help of Bristol University students) and return in 2012, which is the year that marks 100 years of the Bluebird.

Hack!

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++.

Test it!

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/