GI 4DTV - update proposal

Post by **The Robman** » Wed Oct 12, 2011 8:59 am

Even though we made the executor for the 4DTV protocol flexible so that if a different combination of bits was used to calculate the checksum we could handle it by changing the fixed data, it doesn't allow for an OEM using the same formula but with a different seeding value.

I have just come across some learns for a Shaw Direct Motorola DSR satellite where the checksum is the complement of what we were expecting.

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

I think the best way to handle this is to introduce a seeding value, which could be decoded by DecodeIR as a sub-device (the "unit code" is currently the device code). It would work like this, DecodeIR should calculate the 4-bit checksum as it currently does, then if the checksum in the signal is different, it should determine what 4-bit value needs to be XOR'd with the calculated checksum to come up with the found checksum, then this 4-bit value should be presented (in lsb decimal) as the sub-device code.

In RM, a new sub-device box would need to be added, then the GI2 CmdTranslator routine would need to be modified to use this value as a seed in the checksum calculation for the official version.

I have modified the hacked executor to expect the seed as the 5th fixed byte, so it would simply need to be passed into the executor.

New 4DTV PB file:
https://www.hifi-remote.com/forums/dload ... e_id=10014

I have put together a protocols.ini entry for this:

Code: Select all

[GI 4DTV Hacked2]
PID=00 A4
VariantName=hacked.S3C80
FixedData=C6 3D A5 EF 00
DevParms=Unit Code:2=0,Sub-Device:4=0
DeviceTranslator=Translator(lsb,1,4,32)
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 08 07 1C 04 28 08 87 31 02 4C 02 F0 C3 C0 C2 FB 02 B2 03 4A F6 1A EF 09 03 8D 01 46

Note: I haven't tested the new executor code yet. Any volunteers?

Post by **vickyg2003** » Wed Oct 12, 2011 9:51 am

Well I attempted to test the protocol, but the latest version of RM won't let you use variants of a built in protocol to create an upgrade. I don't have any s3c08 remotes that don't have a GI cable version built in....

Note that Rob's first link gives a zip file full of IR files with learns.

Post by **The Robman** » Wed Oct 12, 2011 9:57 am

vickyg2003 wrote:Well I attempted to test the protocol, but the latest version of RM won't let you use variants of a built in protocol to create an upgrade. I don't have any s3c08 remotes that don't have a GI cable version built in....

Huh? I'm using RM v2.02 Alpha 11 and it generates a protocol upgrade. Did you add the new entry to protocols.ini first?

Post by **vickyg2003** » Wed Oct 12, 2011 10:36 am

Huh? I'm using RM v2.02 Alpha 11 and it generates a protocol upgrade. Did you add the new entry to protocols.ini first?

Oh yes I plugged in the protocols ini.

I've been having troubles with protocols since Alpha 10.
https://www.hifi-remote.com/forums/viewt ... 8396#p98396
I'm currently ahead of you on versions. The version I was using wouldn't allow me to choose anything other than the built in version of any protocol with a variant. So since my bench remotes all had GI cable built in, I couldn't add the protocol withiout changing the pid in protocols ini to be something that wasn't in the remote already. So I did change the pid to 01FF to get it past RM, and when I dropped it into IR worked as advertised.

I used a subdevice of 15, but that really wasn't clear to me. I'll have to wait for Dave to tell me what to do from decodeIR.

Post by **The Robman** » Wed Oct 12, 2011 11:08 am

A sub-device of 0 should produce normal signals, and a sub-device of 15 should replicate the Shaw learns.

Post by **The Robman** » Wed Oct 12, 2011 12:15 pm

Vicky, do you think you would be able to write a HCS08 version of this executor? If you look at my PB file and don't understand what it's doing, let me know and I'll walk you through it. It's a lot simpler than it looks, but I took me several reads to recall what it was doing, and I wrote it.

Post by **vickyg2003** » Wed Oct 12, 2011 2:20 pm

The Robman wrote:Vicky, do you think you would be able to write a HCS08 version of this executor? If you look at my PB file and don't understand what it's doing, let me know and I'll walk you through it. It's a lot simpler than it looks, but I took me several reads to recall what it was doing, and I wrote it.

I'll give it a shot. It is good practice for me.

Post by **vickyg2003** » Wed Oct 12, 2011 9:22 pm

Hmm, I've studied the protocol and even though I didn't understand why your checksum was going into DCBUF(R03). The fact that it works is almost scary. I've never worked with a cmd-dev type of signal before, I've always worked with signals where the dev came first. So I'm not sure how DCBUF is loaded in this case to get your device code where it belongs.

GI 4DTV
IRP notation: {37.3k,992}<1,-1|1,-3>(5,-2,F:6,D:2,C:4,1,-60)+

Its more than a little confusing.

The 5 byte fixed data and the 1 byte of command going in, somehow gets into the buffer so that the first byte in the buffer gets the checksum.

Edit:
I guess this was part of the clue.

CmdTranslator=Translator(lsb,0,6) TranslatorFromDev(lsb,0,2,6)

So that's how you got the device in.

I didn't realize that it would transmit the 6th byte in the buffer (command) and then go back and send the first 4 bits of the first byte (dev) when the command-dev option was chosen. Cool!

I've got a bug in the HCS08 executor, so its going to take me a bit to figure out what I did, because my checksum is not correct.

Post by **The Robman** » Thu Oct 13, 2011 6:23 am

The hacked protocol originally just had 4 fixed bytes, I expanded it to 5 bytes to allow for the seeding byte.

I set the protocol flags up so that this protocol only has 1 device code and 1 command code. The device code byte is R03 and the command code byte is R08. As it's cmd-dev, the R08 byte gets sent first followed by the R03 byte.

The device code byte is really the 4 bit checksum. Each bit of the checksum is calculated by XORing a certain number of bits from the variable byte together. The formula that decides which OBC bits are included in each checksum bit is encoded in the fixed data. Think of the 4 bytes of fixed data as 8 nibbles, where each nibble corresponds to a bit from the OBC byte.

If the first fixed byte is 1101, for example, that means that the first OBC bit is included in checksum bits 1, 2 and 4.

In the executor code, I rotate the bits, from the OBC byte, right into the carry. If the carry is not zero, I XOR the appropriate nibble with the checksum byte.

Post by **vickyg2003** » Thu Oct 13, 2011 8:15 am

Thanks for the explanation. I've got both assembler manuals out trying to translate this. You'd think thirteen assembly instructions wouldn't be this hard to translate, even with the difference in the language style.

I'm working on this but my checksum calculations are not coming out to the desired values. I am so glad that I can just point and shoot to see that I've got a bug.

Thanks for "assigning" this to me. Its a good learning exercise, and I like debugging.

Post by **The Robman** » Thu Oct 13, 2011 9:28 am

Here's some more detail. The first 4 bytes of fixed data are "C6 3D A5 E7" which translates to the following 8 binary nibbles:

1100 0110 0011 1101 1010 0101 1110 0111

As the rightmost nibble is "0111" that tells us that the rightmost variable bit in included the 3 rightmost bits of the checksum, but is not included in the leftmost bit.

I have now added a 5th byte of fixed data and am using the first 4 bits to "seed" the checksum.

If you open the PB file, I'll refer to the instructions by their address.

Start:
FF17: W0 is my checksum holder. This instruction used to set W0 to zeroes, now it loads the 5th fixed byte into it.
FF19: W1 is the index that I use to grab the fixed bytes
FF1B: I use W2 to manipulate the variable byte

Loop1:
FF1D: load the next fixed byte into W3 (starting with R06, then R05, R04 and R03)
FF20: W4 is the index that I use to control which nibble we want to work with

Loop2:
FF22: swap W3. This ensures that we work with the right nibble first, then the left nibble
FF24: grab the right bit from the variable byte
FF26: if that bit is zero, skip the next step
FF28: XOR the selected fixed byte (W3) with the checksum holder (W0)
FF2A: repeat FF22-FF28 for the other nibble (ie, Loop2)
FF2C: repeat FF1D-FF2A for the other fixed bytes (ie, Loop1)

FF2E: load the checksum (W0) into the first fixed byte (R03). As the signal profile is cmd-dev with 1 cmd and 1 dev, R03 will be sent after the variable byte (R08).

If you load a copy of your HCS08 PB file, I can take a look to see if I can spot anything wrong with it.

Post by **vickyg2003** » Thu Oct 13, 2011 11:43 am

If you load a copy of your HCS08 PB file, I can take a look to see if I can spot anything wrong with it.

Unless you are in a big hurry, I'd prefer to beat on this for a while. Once I get it up and running, you can do your magic to make it smaller.

I'm no where near ready to throw in the towel. I thought I had run into a problem with the 'carry' flag for the rotation being clobbered by the instructions I was using, but preserving that didn't fix it. It is something really subtle. Digging in on this kind of thing is so relaxing and enjoyable that I don't want to share just yet if you don't mind.

Post by **The Robman** » Thu Oct 13, 2011 11:56 am

Remember, I'm less than a rookie on HCS08 myself, so there's no guarantee that I can fix it either. I tell you what, load up a copy so I can see where you're going with it, but I won't say anything even if I spot what's up, so you can still get to the finish line by yourself.

Post by **vickyg2003** » Thu Oct 13, 2011 2:23 pm

Well now its really BIG but its working.

Post by **vickyg2003** » Thu Oct 13, 2011 3:21 pm

Rob I updated your PB file with my assembler. Is that okay, or was that rude?

After I removed all the instruction that I had added trying to figure out my problem, I reduced it to 59 bytes, which is as small as I can make it.

Code: Select all

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 4E 64 68 8C AE 04 4E 65 67 E6 5F 6E 02 66 62 36 67 24 06 87 B8 68 B7 68 86 3B 66 F2 5B EB 4E 68 60 CC FF 5F