Need help decoding Grundig Tele Pilot 81 D

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

jon_armstrong wrote:I really think the short Off period (-487 uS) isn't a decoding error.

I agree that the signals are far too consistent to blame any significant error on capture problems. You can easily blame up to 28 uS on differences in interpretation of what On/Off boundaries mean as they intersect with 35.8 Khz modulation. But that isn't quite enough either.

Something else is going on that generally increases the pulse widths and decreases the gap widths relative to the one sixth of a bit unit that I tried to use in expaining it.

I doubt the actual device would care about the timing detail difference between clean 1/6 bit units and the actual timing. Anyway, we're not likely to write a new protocol for this since UEI already did. I expect their timing is closer to correct than my 1/6 bit version.

DecodeIR certainly would never care about timing details that subtle. So the only place that would matter is if we made a .IRP file for MakeHex from this protocol.

jon_armstrong wrote: 0 00010101 1000111 OBC=005 1

You manual decoding is pretty good. Your translation of binary to decimal is a little flawed. 10101 is 21, not 5.

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

I uploaded the new DecodeIR (not really tested or documented) to
http://home.comcast.net/~john.fine/ir/Decode_IR_DLL.zip

So whoever tests that upgrade remote to remote can no easily compare the decode of the results to the decode of the original.

goodmaker · Post by **goodmaker** » Sun Sep 19, 2004 3:47 pm

I put more learned signals in http://groups.yahoo.com/group/jp1/files ... 81D(2).txt , the firsts keys (DVD: Up{front} to DVD: 8) are pressed (in the original) shortly, and the rest of keys (DVD: 7 to DVD: 1) are pressed long. You can see the diference. In case it serves as something.

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

I checked Eigeny's document. He calls this protocol "Grundig16ac" when that bit that I've seen only zero is zero, and "Grundig16bd" when it isn't zero (so someone contributing data to the Pronto firmware development has seen this bit nonzero even though I haven't).

We have no protocol named "Grundig" so I'd consider calling it that. But so many Grundig devices use Blaupunkt protocol that I think naming a protocol "Grundig" would make people assume incorrectly and use that when they should use Bluapunkt. Maybe naming it "Grundig16" would reduce that risk and increase the association with anyone else who has already looked at Eigeny's work.

Edit: I forgot to mention that all the Pronto samples for this and the 7000 format built into the Pronto are all for a seriously lower frequency modulation that the DVD learned signals, which I think match the UEI protocol.

I assume that means UEI and the Pronto firmware are both right and the Grundig DVD uses the same protocol structure as the Grundig VCR but at a different modulation frequency.

johnsfine · Post by **johnsfine** » Sun Sep 19, 2004 4:06 pm

goodmaker wrote:the firsts keys (DVD: Up{front} to DVD: 8) are pressed (in the original) shortly, and the rest of keys (DVD: 7 to DVD: 1) are pressed long. You can see the diference. In case it serves as something.

I had already jumped to the conclusion that this was a fairly ordinary repeating signal, even though most of the learns are non repeating.

The short presses are each two frames long and the long presses are each enough repeating frames of the 9960 to learn the repeat pattern.

I expect Grundig has a two frame minimum for short presses. It probably would be nice if we did too.

I don't know (short of testing some really quick presses) whether UEI noticed that and included it in their protocol.

Anyway, that's a subtle detail to worry about after the rest is all working.

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

Perfect, with the new decodeIR.dll the IR.exe recognizes in the learned signal the protocol "pid112" and the device DVD:0775 control fine my DVD Grundig (IR tele pilod 81D) with (finally) my URC9960.
Ony one more help, please: in the Key Map Master 8.28 the protocol "pid0112" does not appear and I can´t create an upgrade device, what can I do?

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

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

I'm currious what changed after that. Now you say it does work in the 9960.

goodmaker wrote: Ony one more help, please: in the Key Map Master 8.28 the protocol "pid0112" does not appear and I can´t create an upgrade device, what can I do?

Rob was planning to post a KM file for you after you verified that the upgrade worked (and maybe after you answered what those functions were that he asked about).

I don't know how hard it would be for Rob to make that upgrade use OBC codes compatible with the decodes. In a protocols.ini entry for RM it would be pretty easy. In KM it might be more trouble than it's worth.

I should be able to fix DecodeIR so that it gives EFC numbers that are compatible with both whatever Rob is doing in KM and whatever might be done in RM. Then you could add any functions Rob misses into the upgrade by EFC number.

Mark Pierson · Post by **Mark Pierson** » Sun Sep 19, 2004 4:36 pm

goodmaker wrote:Perfect, with the new decodeIR.dll the IR.exe recognizes in the learned signal the protocol "pid112" and the device DVD:0775 control fine my DVD Grundig (IR tele pilod 81D) with (finally) my URC9960.

I see in the latest file you posted, there are signals learned to the DVD device. You also have the DVD and VCR device buttons set to DVD/0775. When you say that the upgrade works, are you referring to codes sent while in DVD or VCR mode? The learned DVD signals will override the upgrade if you test via the DVD button.

jon_armstrong · Post by **jon_armstrong** » Sun Sep 19, 2004 4:47 pm

johnsfine wrote:You manual decoding is pretty good. Your translation of binary to decimal is a little flawed. 10101 is 21, not 5.

I fixed it, it was actually semi-automated with a spreadsheet, but it was only looking at the bottom nibble of OBC as I'm sure you recognized.

goodmaker · Post by **goodmaker** » Sun Sep 19, 2004 4:48 pm

The VCR set to DVD/0775 by error. I only work with Kamaleon URC9960 to control a DVD Grundig Livance GDP3200 with original IR Tele Pilot 81D. I haven't any VCR. And at this moment works fine with the more popular keys.

johnsfine · Post by **johnsfine** » Sun Sep 19, 2004 5:00 pm

http://home.comcast.net/~john.fine/ir/Decode_IR_DLL.zip
I uploaded DecodeIR.dll again with a few changes including:

1) Renamed "pid112" to "Grundig16"

2) Computed the EFC number to be compatible with KM (once someone posts the basic upgrade for KM).

johnsfine · Post by **johnsfine** » Sun Sep 19, 2004 5:18 pm

I really think the bit boundaries and bit encodings that DecodeIR.dll now has for this protocol are correct (matching what the designers at Grundig had in mind when they set it up).

But those bourdaries and encodings are quite inconvenient relative to what UEI built into pid_112.

The OBC is misaligned by one bit from the hex command and within each pair of bits UEI has the second bit first and the XOR of the two bits second.

That will make for a very tricky protocols.ini entry to translate the low 6 device bits plus an "OBC>127" flag into fixed data and to translate the low 7 bits of OBC and the high bit of device into the hex command.

I expect it's too messy to be worth KM doing the same, so for KM, I should change DecodeIR to also compute the fixed data byte, so a KM upgrade can use fixed data and EFC rather than device and OBC.

jon_armstrong · Post by **jon_armstrong** » Sun Sep 19, 2004 5:53 pm

Would it be easier to fix the protocol since very few remotes have it anyway?

Mark Pierson · Post by **Mark Pierson** » Mon Sep 20, 2004 2:51 pm

johnsfine wrote:The DVD in this thread is device 71

I'm still not sure if the upgrade works for goodmaker, or if it was really the learned signals that are being sent based on his last uploaded IR file...

[bad upgrade code removed - MP]

Goodmaker, if you try this code, either assign it to a different device button than DVD -or- make sure you delete the learned signals before uploading to the remote for testing.

johnsfine · Post by **johnsfine** » Mon Sep 20, 2004 3:20 pm

Mark Pierson wrote: I'm still not sure if the upgrade works for goodmaker, or if it was really the learned signals that are being sent based on his last uploaded IR file...

I agree. We really haven't seen a clear answer to that question.

Mark Pierson wrote: Anyway, I think Rob's upgrade posted earlier was using a Device Code of 143.

I'm pretty sure Rob's upgrade had the right device number. Remember the translation from device number to fixed data for this protocol is VERY messy and no one has yet written anything to let KM or RM do that translation (I plan to write the messy protocols.ini entry for this pretty soon).

Mark Pierson wrote: The code below uses the 71 that John mentions:

I manually translated device number 71 to fixed data and got 0E. That matches what Rob had and doesn't match what Mark just posted, so I advice against wasting time on Mark's version.

Mark Pierson wrote: Goodmaker, if you try this code, either assign it to a different device button than DVD -or- make sure you delete the learned signals before uploading to the remote for testing.

Very good advice for testing Rob's upgrade to make sure you're really testing it and not accidentally testing the learned signals.