D encoding scheme

From JP1 Remotes
Jump to: navigation, search

D encoding scheme

I (3FG) have been doing some work on DecodeIR, and this was one of the items on the To Do list. I prefer an approach different to the one proposed in this thread. Some background: The GI 4DTV IR protocol has an error correcting feature which is usually termed a Hamming Code. If any single bit of the 12 bits of IR signal is wrong, the scheme detects the error and allow the IR receiver to fix it. Rob described the pattern of bits that make up each parity bit while explaining an executor for this protocol. Code:

If the actual signal is represented like this: "76543210 ABCD" where "76543210" is the OBC portion of the signal
and "ABCD" is the checksum portion: The formula for the checksum is as follows (where ^ means XOR)

Note that this is a different pattern from the one shown in the Wikipedia article, because the article shows the parity bits interleaved with the data bits in order to demonstrate the concept better. At the receiving end, parity is calculated for each of the 4 groups including the sent parity bit. The result is called the error syndrome and it will be zero if there is no single error.

4DTV has a slight wrinkle, because it is a subset of a Hamming (15,11) with three of the possible 11 data bits left unused. This means that for no error or only single bit errors, the syndrome can't reach the values 0xF, 0xB, or 0x9. It appears that GI took advantage of that in assigning unit numbers, so that a zero syndrome implies units 0-3 and a 0xF syndrome implies units 4-7. The Shaw website discusses how to address the various unit numbers, and the URC 551 remote (URC-2050 in UEI terminology) uses setup code 0869 for unit 0, and setup codes 1870 - 1876 for units 1 - 7. I've looked at the signals these setup codes shoot, and they follow this behavior.

It seems to me that besides unit numbers 0-7, the 4DTV IR protocol could provide an additional 8 unit numbers, using the syndromes 0xB and 0x9. But we don't know how those would be assigned, so I haven't tried to implement that. If the manufacturer uses any other scheme, it would break the error correcting feature. And if they do that, there's no reason to think they would retain the seemingly complicated check sum rule. So I see little upside to an approach that assumes that there is a seed associated with 4DTV. The downside of such an approach is that it would complicate the usage of the executor and the interpretation of results from DecodeIR.

I've made a GI3 version of the GI2 translator, which accepts unit numbers 0 to 7. The user interface for the official executor looks the same, and the existing KM/RMDU files all still work. DecodeIR reports unit numbers 0-7 as the device. If an incorrect syndrome is detected, it reports both the syndrome and the actual checksum in the Misc field, while the device is listed as 0-3.

Transcribed from this post:

Personal tools