GI 4DTV - update proposal

[The Robman]

It looks like you just re-loaded my file, I don't see your HCS08 code in there.

[vickyg2003]

It looks like you just re-loaded my file, I don't see your HCS08 code in there.

Oops, I guess I saved it to a different folder. Try again.

[The Robman]

Nice, I got it this time. I have a suggestion as to how you might be able to save a few bytes. Given that you have to use a buffer byte for the checksum anyway, why not use DCBUF rather than DCBUF+8. Then, rather than supplying the seeding value in DCBUF+4, supply it in DCBUF.

If you think it's a good idea, I could re-arrange the S3C8 version so that the first byte is the checksum seed also.

[The Robman]

Well, I took a crack at changing both versions to use the 1st byte for the checksum instead. I have no idea if I got either of them right, but here it is:

https://www.hifi-remote.com/forums/dload ... e_id=10019

and here's the protocols.ini entry for it:

Code: Select all

[GI 4DTV Hacked3]
PID=00 A4
VariantName=hacked
FixedData=00 C6 3D A5 EF
DevParms=Unit Code:2=0,Sub-Device:4=0
DeviceTranslator=Translator(lsb,1,4,0)
CmdTranslator=Translator(lsb,0,6) TranslatorFromDev(lsb,0,2,6)
CmdParms=OBC:6=0
Notes=hacked version (with seeding byte)
Code.S3C80=3D 91 51 8B 12 F5 45 04 08 01 F4 05 C8 01 F4 01 E0 C3 3C 09 C4 03 D4 1C 04 28 08 87 31 03 4C 02 F0 C3 C0 C2 FB 03 B4 C3 03 4A F5 1A EE 8D 01 46
Code.HCS08=20 15 1F 4A 51 F5 45 04 08 01 F4 05 DC 01 F4 01 F4 C3 3C 09 C4 03 E8 8C AE 04 4E 65 67 E6 60 6E 02 66 62 36 67 24 06 87 B8 60 B7 60 86 3B 66 F2 5B EB CC FF 5F

[vickyg2003]

I just tested the HCS08, it works and its smaller.

[The Robman]

Cool. That saved 6 bytes from the HCS08 version and 3 bytes from the S3C8 version.

[vickyg2003]

I tested the s3c8 version too, and that works as advertised as well.

[The Robman]

thank you

[3FG]

I've 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: Select all

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)
A=1^3^4^7
B=0^1^2^4^6^7
C=0^1^3^5^6
D=0^2^4^5

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.

[The Robman]

THis is probably a question for 3FG, Barf or Mathdon, but I've been trying to figure out how the 4dtv signal matches up with the Hamming codes. I can see now that what I was calling a "seed" value before was really just the missing bit of the unit code. But what I can figure out is how to make the right checksum generate using the info on the Hamming wiki page.

Obviously, one main problem when talking about binary is (a) are you reading it left-to-right or right-to-left, and (b) when you talk about positions, is the first position 0 or 1 ?

I have put together a spreadsheet here which has all the 4dtv codes that I know of, plus the 8 Shaw setup codes that Dave talked about in the last post. I can still generate the right checksum using my formula but not using the Hamming formula. You can see that I made two attempts, one assuming they were reading L-R and another R-L.

https://www.hifi-remote.com/forums/dload ... e_id=25849

[3FG]

Hi Rob,
The exact order of the bits isn't important; the key is that "Each data bit is included in a unique set of 2 or more parity bits". Here is a table that shows how to map your designation onto the wiki page:

Code: Select all

7	6	5	4	3	2	1	0	A	B	C	D
x			  x	x		 x		 1			
x	x		 x		 x	x	x		 1		
	 x	x		 x		 x	x			  1	
		  x	x		 x		 x				   1
d1  d3  d8  d7  d2  d6  d4 d10  p1  p2  p3  p4

Note that d5, d9, and d11 aren't directly used in the Hamming representation of GI 4DTV, but as I tried to explain back in 2012, they threw away some of the error checking capability to get unit numbrs. BTW, in case you look at source code, another way of describing the bits is used in the GI3.java translator and DecodeIR.cpp. It labels the leftmost bit (the one sent first in an IR transmission) as bit 0 and runs up to bit 11, but that was just for my convenience.

[Barf]

FWIW, this is the IRP form used in IrpTransmogrifier (and thus IrScrutinizer and RemoteMaster):

Code: Select all

{37.3k,992}<1,-1|1,-3>(5,-2,F:6,D:2,C0:1,C1:1,C2:1,C3:1,1,-60)*
{
C0=D:1:2 + #(F&25) + #(D&1),
C1=D:1:2 + #(F&43) + #(D&3),
C2=D:1:2 + #(F&22) + #(D&3),
C3=D:1:2 + #(F&44) + #(D&2)
}[D:0..7, F:0..63]

My understanding is that the protocol was designed D to be two bits (D:1:2 = 0), then "someone" decided to slap on another bit by selectively inverting the checksum to indicate that the new bit was 1.

Here is a useful command:

Code: Select all

irptransmogrifier render --name 'F=52,D=0' g.i.4dtv -r | irptransmogrifier  analyze  --radix 2 --input -

which generates the output

Code: Select all

{37.3k,992,msb}<1,-1|1,-3>(5,-2,A:12,1,-59m){A=0b1011001100}

It works by invoking IrpTransmogrifier first to render a signal, than pipes the generated output to another instance of the program which "analyzes" it, and generates the payload data as bits ("radix 2"). Another useful command is

Code: Select all

irptransmogrifier render --name 'F=52,D=0' g.i.4dtv -r| irptransmogrifier  analyze --lsb -w F:6,D01:2,C0:1,C1:1,C2:1,C3:1 --radix 2 --input -

which generates

Code: Select all

{37.3k,992,lsb}<1,-1|1,-3>(5,-2,F:6,D01:2,C0:1,C1:1,C2:1,C3:1,1,-59m){C0=0b1,C1=0b1,C2=0b0,C3=0b0,D01=0b0,F=0b110100}

[The Robman]

I totally hadn't anticipated that the Hamming bits would be out of sequence, now that you've provided the bit labels I see that the formula exactly matches the one that I've been using. And regarding that extra virtual bit that is being used for the unit code, I would label that d11 as it needs to be in all 4 checksum bits.

Now that I have full clarity, I think my original proposal for this thread is valid. My hacked 4dtv executor uses just 1 variable bit, which limits us to 8 variable bits, so we need a way to supply that 9th bit, and that's what I was calling the seeding byte earlier. One option would be to just supply the one bit as fixed data, kinda like how the RC5 executor has one bit as fixed data, which would allow the user to mix and match unit codes within the allowed range. Or, I could have 3 bits of fixed data and 6 bits of variable, which would meet most people's needs.

[3FG]

I'm not at all clear what problem you're trying to solve. The GI [4DTV Official] entry in protocols.ini is already setup using the GI3 translator to provide 3 bits of unit number (device number) in fixed data, and 6 bits of OBC. That would seem to match your

Or, I could have 3 bits of fixed data and 6 bits of variable, which would meet most people's needs.

Note that the official 00A4 executor is setup to simply take 12 bits of variable data and no fixed data, so we could imagine a different translator to provide multiple unit numbers in one upgrade, but that doesn't require a new executor. Nor do I perceive any need for this unit number flexibility. I doubt that any new setboxes will use this IR protocol.

Going into soapbox mode, it is my opinion that we should avoid hacked executors whenever possible, and this is an example that illustrates the point. The official executor is implemented in every known processor used in UEI remotes, while the hacked ones aren't. Upgrades using the hacked executors are thus not fully portable across remotes.

[The Robman]

I wrote the hacked version of the 4dtv executor back when we really tried to always have a single variable byte whenever possible, and just to see if I could. Kevin Timmerman made the first attempt where he calculated the checksum using assembler, but it was a complicated piece of code, then I came up with the idea of feeding the formula into the executor by way of the fixed data.

I was trying to find Kevin's original code when I stumbled back across this old thread, which led me to wanting to understand the Hamming connection. I am curious how you spotted the Hamming thing, what with the bits not being in sequence.

I disagree about always wanting to use official executors. Remember the ReplayTV and Tivo executors, but used 2 variable bytes unnecessarily, so we saved folks a lot of memory by making our own versions available, plus we added a lot of goodies into the ReplayTV exec. Do you recall the case of the Apex DVD player where you had to press a SHIFT button in order to get the arrow buttons to work? So we wrote an exec that would do that for you, and UEI even cloned it and make an official version. Even with 4dtv, the official exec unnecessarily uses 2 bytes where I was able to make a version that uses 1. I know remotes have more memory now, but there was a time when it was hard to squeeze everything in and that's where our homemade execs really helped.