Need help decoding Grundig Tele Pilot 81 D

goodmaker · Post by **goodmaker** » Sat Sep 18, 2004 7:20 pm

In this file (from Ir.exe): http://groups.yahoo.com/group/jp1/files ... gTP81D.txt
Made for the Kamaleon 9960 there are learned signal from the original IR Grundig Tele Pilot 81 D.
Can anybody tellme what protocol use.
In 2 signal it appears protocol "s16a" but I don´t know its characteristics.
Thanks

johnsfine · Post by **johnsfine** » Sun Sep 19, 2004 9:42 am

This one is a little harder than a typical protocol, but I should be able to create both a protocols.ini entry and support in DecodeIR fairly soon.

In case other experts are looking, what I've decided so far (looking at less than half the samples, so I'm not sure):

There are eight double bits in the signal. With a time scale of 578 the four possible forms for a double bit are:
-1,1,-3,1
-2,1,-2,1
-3,1,-1,1
-4,2

There is a lead in of: 806u,-2994u,1338u and a lead out of -100

It's a little annoying that the durations in the lead in aren't close enough to multiples of the time unit (578) to express that way. The data bits aren't really that cleanly multiples of the time unit either, so maybe I missed a clearner time unit. But they seem close enough that typical capture error can be blamed for the difference.

It's fairly hard to build a protocol based on double bits, and even harder to start all bits on a minus and end them on a plus (and have the 3 part lead in rather than two part).

So the easy way to process this may be to treat each actual "double bit" as six fake bits, where the fake bit values are just -578 and +578. That leaves the third part of the lead in very hard to get right. I wonder if the device cares about that detail. It also needs 50 bits in the signal with at best the last 18 fixed, so at least 4 bytes of hex command.

Jon, or other experts, have we seen this before that I'm forgetting? Is there an easier way than what I described above?

Rob, or others with UEI contacts, has UEI already got a protocol for this?

Post by **The Robman** » Sun Sep 19, 2004 11:23 am

They tell me that this device uses DVD/0775, which is not a very common code. I only know of it being in the URC-8060.

Here's an upgrade you can try in your URC-9960:

Upgrade Code 0 = 3B 07 (DVD/0775) DVD/0775 (KM v8.25)
12 00 BE DE FA 59 0E 17 16 1B 1A 23 22 2F 2E 27
26 CA F3 03 0F 0E 0B 06 FF 43 4A 73 7E 7F 72 82
F3 CA 4F 42 83 EF
End

Upgrade Protocol 0 = 01 12 (S3C8+) Custom Protocol for DVD/0775 DVD/0775 (KM v8.25)
47 95 11 8B 13 00 01 97 05 C8 02 A1 01 29 02 4E
00 DB 02 2A 03 7A 04 6A 76 00 01 6B 03 B6 03 40
1C 12 F6 01 4C 1E F6 01 64 38 03 5C 01 F6 FF 4D
48 C3 38 04 5C 04 F6 FF 4D 38 C4 5C 03 F6 FF 4D
C6 F8 70 26 F6 01 58 F6 01 0A 7B D4 AF 90 C3 7B
16 90 C3 7B 0C 1C 22 F6 01 6D 1C 1A F6 01 64 8B
1C 1C 1E 6C 1E 8B 0E 90 C3 7B 06 1C 1C 6C 20 8B
04 1C 20 6C 1C F6 FF 80 18 C6 F6 FF 80 5A CE AF
F6 01 6D 1C 18 8D 01 64
End

I assigned three unknown functions to the SKIP, RAND and AUDIO buttons, so if the code works, let me know what those functions are and I'll upload a KM file for you to play with.

johnsfine · Post by **johnsfine** » Sun Sep 19, 2004 12:28 pm

The Robman wrote: Upgrade Protocol 0 = 01 12

That protocol certainly looks right for those learned signals. I can't tell whether you looked at the protocol or you just went by the fact that UEI recommended that setup code.

The protocol looks like the sequence of bits in the signal are:
1 device bit
1 toggle bit
8 function bits
6 more device bits

I'll do the DecodeIR processing assuming that is correct.

The Robman wrote: I assigned three unknown functions to the SKIP, RAND and AUDIO buttons, so if the code works, let me know what those functions are and I'll upload a KM file for you to play with.

Where did you get "unknown" functions from?
Did you manually decode some of the learned signals? Or were the meaning of some of the 8060's DVD/0775 keys unclear? Or what?

If I make a Protocols.ini entry (though you seem to be ahead of me in understanding this) do you have an opinion on what I should name the protocol?

goodmaker · Post by **goodmaker** » Sun Sep 19, 2004 1:09 pm

Don´t work, with the protocol $0112 and device DVD:0775, the URC9960 becomes crazy, is blocked when pulse any fuction. Do you know the protocol s16a?

Post by **The Robman** » Sun Sep 19, 2004 1:27 pm

johnsfine wrote:That protocol certainly looks right for those learned signals. I can't tell whether you looked at the protocol or you just went by the fact that UEI recommended that setup code.

I didn't look at it at all, I just took their word for it and posted the info.

johnsfine wrote:Where did you get "unknown" functions from?

Those three functions were assigned to the M2, M3 and M4 buttons on the URC-8060.

johnsfine wrote:If I make a Protocols.ini entry (though you seem to be ahead of me in understanding this) do you have an opinion on what I should name the protocol?

I'm not ahead of you at all and don't have any opinion regarding naming. I guess we could look at the URC-8060 manual and see what DVD players really use this protocol.

johnsfine · Post by **johnsfine** » Sun Sep 19, 2004 1:27 pm

goodmaker wrote:Don´t work, with the protocol $0112 and device DVD:0775, the URC9960 becomes crazy, is blocked when pulse any fuction.

Assuming you installed the protocol and device upgrades correctly, that protocol must do some operation that is available on the 8060 and not on the 9960. Rob or I can check that and find a work around if that is true. I can't do that now. Hopefully Rob will get to that before me.

goodmaker wrote:Do you know the protocol s16a?

It's a garbage decode from old decoders built into IR.EXE. At some point I need to investigate whether garbage decodes like that are being caused by an error in DecodeIR.dll in not telly IR.exe which protocol names are covered (which error I should fix) or an error in IR.EXE in not listening to that (which one of the IR developers should fix).

Meanwhile, ignore those decodes. They're wrong. I'm working on a change to DecodeIR.dll which will give correct decodes.

johnsfine · Post by **johnsfine** » Sun Sep 19, 2004 1:34 pm

I just took a better look at the protocol hex sequence Rob posted (rather than blindly trusting Rob, which USUALLY works). One error is obvious. Fixing just that error gets this version

Upgrade Protocol 0 = 01 12 (S3C8+) Custom Protocol for DVD/0775 DVD/0775 (KM v8.25)
47 95 11 8B 13 00 01 97 05 C8 02 A1 01 29 02 4E
00 DB 02 2A 03 7A 04 6A 76 00 01 6B 03 B6 03 40
1C 12 F6 01 4C 1E F6 01 64 38 03 5C 01 F6 FF 4D
48 C3 38 04 5C 04 F6 FF 4D 38 C4 5C 03 F6 FF 4D
C6 F8 70 26 F6 01 58 F6 01 0A 7B D4 AF 90 C3 7B
16 90 C3 7B 0C 1C 22 F6 01 6D 1C 1A F6 01 64 8B
1C 1C 1E 6C 1E 8B 0E 90 C3 7B 06 1C 1C 6C 20 8B
04 1C 20 6C 1C F6 FF 80 18 C6 F6 FF 80 5A CE AF
F6 01 6D 1C 18 8D 01 64
End

Edit: Right after posting I found I'd only fixed half of that error and so I edited. So if you saw this post too soon try again. There is a good chance there are more problems I haven't caught yet.

Post by **The Robman** » Sun Sep 19, 2004 1:48 pm

I spotted the error in the KM generated protocol, so I have edited the original post. Hopefully that will work now.

goodmaker · Post by **goodmaker** » Sun Sep 19, 2004 2:15 pm

With changes the URC9960 don´t blocked now but the DVD don´t response any signal

mr_d_p_gumby · Post by **mr_d_p_gumby** » Sun Sep 19, 2004 2:42 pm

johnsfine wrote:Upgrade Protocol 0 = 01 12 (S3C8+) Custom Protocol for DVD/0775 DVD/0775 (KM v8.25)
47 95 11 8B 13 00 01 97 05 C8 02 A1 01 29 02 4E
00 DB 02 2A 03 7A 04 6A 76 00 01 6B 03 B6 03 40
1C 12 F6 01 4C 1E F6 01 64 38 03 5C 01 F6 FF 4D
48 C3 38 04 5C 04 F6 FF 4D 38 C4 5C 03 F6 FF 4D
C6 F8 70 26 F6 01 58 F6 01 0A 7B D4 AF 90 C3 7B
16 90 C3 7B 0C 1C 22 F6 01 6D 1C 1A F6 01 64 8B
1C 1C 1E 6C 1E 8B 0E 90 C3 7B 06 1C 1C 6C 20 8B
04 1C 20 6C 1C F6 FF 80 18 C6 F6 FF 80 5A CE AF
F6 01 6D 1C 18 8D 01 64
End

Not sure, but something still looks wrong about the part I highlighted above.

johnsfine · Post by **johnsfine** » Sun Sep 19, 2004 2:44 pm

I have added this protocol to DecodeIR.

After decoding the posted signals, I've changed my mind about the interpretation of a few details:

The correct sequency of double bit values is the reverse of what I first guessed. The correct encoding is:

11 = -1,1,-3,1
10 = -2,1,-2,1
01 = -3,1,-1,1
00 = -4,2

I think that UEI protocol uses neither this "correct" encoding nor its comp. But I think it does use those 4 double bits, so there is a simple (for KM or RM) translation between the bits as I want to decode them and the bits as pid112 encodes them.

I think the toggle bit is the first bit. UEI has it second because of the way they scramble the double bit encodings.

The second bit is always zero so I don't know what it is. I think it's an MSB for the function so if it was ever used (by some similar device pid112 might not be good enough).

After the first two bits are 7 function bits and 7 device bits (not 8 and 6 as UEI has) but having one device bit in with the function is trivial for RM or KM to deal with.

The values are clearly MSB. So I think the whole thing is:
{35.8k,578,msb}<-4,1|-3,1,-1,1|-2,1,-2,1|-1,1,-3|1>(806u,-2994u,1150u,T:1,F:8,D:7,-100)+

None of these details explain why the upgrade Rob posted didn't work. We may need someone with two JP1 remotes to learn the signal from one to another to see what we're getting wrong.

johnsfine · Post by **johnsfine** » Sun Sep 19, 2004 2:49 pm

mr_d_p_gumby wrote:Not sure, but something still looks wrong about the part I highlighted above.

You may be getting detailed enough to be better off emailing your concerns to Rob and to me, rather than filling this thread (though I have also been posting a lot here that could be interesting only to other experts).

At first glance I don't see the problem with the part you highlighted.

jon_armstrong · Post by **jon_armstrong** » Sun Sep 19, 2004 3:12 pm

I was a little behind John (and got a big assist from his association of the bursts) but I really think the short Off period (-487 uS) isn't a decoding error. If you sum all the bursts they all come pretty close to 3466 uS. But either way, this is how I decoded the commands:

1 00000000 1000111 OBC=000 pwr
0 00010101 1000111 OBC=021 1
1 00010110 1000111 OBC=022 2
0 00010111 1000111 OBC=023 3
1 00011000 1000111 OBC=024 4
0 00011001 1000111 OBC=025 5
1 00011010 1000111 OBC=026 6
0 00011011 1000111 OBC=027 7
1 00011100 1000111 OBC=028 8
0 00011101 1000111 OBC=029 9
1 00010100 1000111 OBC=020 0
0 01000110 1000111 OBC=070 menu
1 01001001 1000111 OBC=073 ok
0 00000010 1000111 OBC=002 play
1 00101010 1000111 OBC=042 stop
0 00000011 1000111 OBC=003 pause
1 00000101 1000111 OBC=005 fwd

I certainly don't recall this protocol before nor does this explain why it doesn't work either. So that's the next project

EDIT: I fixed the OBC's per John's subsequent comment

johnsfine · Post by **johnsfine** » Sun Sep 19, 2004 3:21 pm

I'm nearly ready to post a DecodeIR.dll that decodes this protocol.

I ran it against all the CCF files I downloaded and found three CCF files for Grundig VCRs that are all device 127 in this protocol (The DVD in this thread is device 71).

Those CCF files are:
romain-heilig_ccf.zip
luigi-palumbo_ccf.zip
markus-emmert_ccf.zip

The first of those is particularly interesting because it mainly uses a 7000 format Pronto Hex that DecodeCCF doesn't yet include. I think Eigeny named all the protocols using 7000 format, so I'll see if I can dig through his document and see if it makes sense to use the same name he did.