A while ago, I worked on decoding some of those infra-red DSTV decoder remotes (the ones you find for 100 bucks at almost every supermarket) to see what is cooking there and whether the remote could be used for other applications. Well yes, they speak standard protocols.
Unfortunately, the code I did for that is now lost :( [hard disk failure], but I have recovered enough to be able to document everything again.
I am designing a system for my Alpha-X kit so I am looking closely at protocols. The most widely used one is the NEC protocol, and until recently I didn't even know it had a predecessor.
So in looking at a remote control, I know that, I will have to roll my own (I don't think it would be good form to use MonoChoice's remote on my product- wouldn't go down too well would it? Probably be on the business end of their lawyers). So I am going to have to design my own handset from scratch.
As a starting point I began to look at the venerable, old µPD1986 (incidentally used in the remote for those ancient, analogue M-NET decoders). I happen to have one of the chips, so I hooked it up on a breadboard like this:
Now, the above rudimentary "remote" actually works, except there is one problem, it transmits a small frame, and according to the datasheet, its basically a function of the key matrix:
So all we have is a 5 bit code, and no error correction or any way of detecting an error. That kind of explains why those decoder boxes were so susceptible to interference from other remote controls. The basic fact here is that this is not going to fly, so we need to implement the current NEC protocol.
A fun fact: This simple frame is 9mS in duration, which means it fits exactly into the start pulse of the current NEC protocol. That is not a coincidence!
Before we move on to the current protocol, let's look at how the µPD1986 actually achieves the battery life it does (typically years of operation from a set of AAA cells)
The current NEC protocol
The NEC protocol currently in use looks like this:
So the above, is fairly self-explanatory, and it is apparent that four bytes are being transmitted. This is the 'expanded' version of the protocol, virtually in use everywhere, even on the Apple TV remote.
Now, with the proliferation of products on the market, the address field is expanded to use both bytes i.e. the full 16 bits, and so forms a customer code. Indeed some manufacturers publish their codes in the public domain, most don't though.
The Command bytes however, are vendor dependent. Some manufacturers use the above i.e. Command, Command Inverse, others use their own schemes.
The biggest problem of course is that NOBODY can tell me, nor can I find online, a comprehensive list of customer codes assigned by NEC/Renesas, nor can I find information to apply for such a code formally.
Because of this, and to ensure we don't get interference, I am going to "borrow" off of MonoChoice's code, and implement my own thing. In this way my remote codes would be unique enough to not clash with anyone's equipment, now or in the future. Details to follow in the next part!