This is a follow-on from the first part, which can be found here
I am working with one of these remotes that can be found at any supermarket
The remote, known as a "MODEL A4" transmits the familiar NEC protocol in its entirety. The timing is correct in every respect. Therefore this product can be considered a proper NEC protocol handset.
The NEC protocol was invented by NEC, now Renesas, NOT Beyond Platinum
The handset is pretty much what we expect, a standard handset operated by 2 pen cells, but then they put this statement inside the battery compartment. This sort of thing annoys me: when you've taken an industry standard created by a Japanese semiconductor vendor, modified it slightly and then gave it a name and called it your own copyrighted protocol.
The transmitted data from the above handset is perfectly within specification of the protocol published by NEC/Renesas. The manufacturer has applied their own rules for the address field. Therefore, the claim to copyright is not valid.
I do wish to point out however that, this business of "copyrighting" a remote control transmission protocol, especially when it is blatantly copied from a pre-existing industry standard, is considered poor form. It has been tested in South African courts and I can safely conclude from my personal experience with litigation that Beyond Platinum have no claim to copyright. This is a clear cut case of "prior art". But I do not think that they care, considering that their website hasn't been updated in years and is still running Adobe Flash.
With reference to the frame format, any well-written decoder routine will decode these remote controls correctly as the timing follows the standard. These products transmit the full 32 bit frame in extended format, illustrated below:
In the above figure (the industry standard version) the address and command words are considered as 16 bit words and in each word, the true and 1's complement of an 8-bit address or command is encoded (the 1's complement is part of an error detection mechanism).
To extend the available space of handsets on the market (and to prevent collisions) NEC allowed for the entire address field (16 bits) to be used for a customer code. Many manufacturers use this field in this way, and a few of these manufacturers formally publish the address code in their product literature.
The same concept used to extend the address space in the address word has also been applied to the command word, and is used by many manufacturers in this way.
Decoding in firmware
Decoding the bitstream is a straightforward process using the capture/compare facility of a timer, which most modern microcontrollers are equipped with. The code used in the Alpha-X products can be found here for reference.
The one thing that you need to bear in mind is that the first part of the SOF, will rarely be measured as 9ms.
This is because of the IR receiver. Most IR receivers these days are an integrated type:
These devices are extremely easy to use and offer very compact space saving form factors. However there is one characteristic that you need to be aware of. The devices employ noise filtering to prevent false signals and ambient IR (thermal) noise from causing "chattering" on the output (which would cause a problem on a busy microprocessor). The filtering and particularly the type of decoding arrangement in the device results in a significant delay from the point in time when the first 38kHz IR pulses are received, to the point in time when a change on the output pin occurs. This is why the IR remote includes the SOF pulses, to allow this receiver to "lock on" to the signal, and why you should not attempt to accurately measure the SOF pulses or use their timing for reference.
Decoding the data
In the library I developed, we first receive the entire bitstream and then separate the ADDRESS and COMMAND fields into separate variables. When developing these routines, I added code to push the results to the debug channel:
The above made it extremely easy to explore the codes being sent by the Beyond Platinum (and other) remote controls, quickly and without effort.
Results from the Model A4
With working firmware, I got some interesting results from the A4 handset.
So we observe that they change the address for certain categories of buttons on the remote. The LSB of the address, however, remains constant. The most significant nibble of the data word remains at zero.
Now we have another feature of these remotes, and that is one where the user can change the code, to allow two remotes to operate on two separate set top boxes in the same room without affecting both. By default, the remote transmits for "TV1" and by changing the device to "TV2" the output code changes as follows.
Address Word Format
Using several different models of these remote controls (which are functionally similar but aimed at different models of STB) I was able to determine the formatting of the address word:
Now the command field, appears to be a bunch of proprietary codes. And what is interesting that, a power button, for example, has the same command code across various models. Therefore, the command codes from various buttons are:
If there is a requirement, I will document all the codes, but for now, this is sufficient for us to be sure we are decoding properly and we can have an idea of where to modify the protocol to ensure we don't clash with the remotes in South African homes.
The Beyond Platinum remotes, will transmit packets for as long as you hold the button down. This is a very bad idea, because it then means a remote pushed in between the couch cushions will then sit and transmit until the batteries are depleted.
When a button is pressed on these remotes, two identical packets are sent, and the same packet is repeated endlessly if the button is held down. They do not use the repeat coding provided for in the NEC protocol specification. I guess this is due to the poorly performing IR decoding software used in the STB (Google shows many complaints about that key aspect).
Adapting this to Alpha-X
To ensure that nothing clashes, i.e. conflicts or unwanted interference, I took the NEC protocol and defined my own code as follows: