DecodeIR.dll Problem

[jon_armstrong]

There apparently is a new 32 bit version of the Nokia (aka Nokia Quad) protocol that makes DecodeIR.dll decode as three instances of the 24 bit protocol. Details in this thread.

[johnsfine]

I updated the decoder, but I didn't know what to do with the extra byte. Usually in these cases I make the subdevice 16 bits.

That didn't give desirable results in the CCF file I had (previously misdecode) for this protocol

frank-moors_ccf.zip

Any suggestions on what to do with 4 bytes within our rather rigid device/subdevice/OBC system?

In that CCF, the bit right before the OBC varies. That's the high bit of the subdevice as presently decoded. But that's clearly wrong.

From the CCF I'd guess toggle bit. But that IR file from the other thread seems to contradict that guess.

Did we have an rational basis for making Nokia LSB (I don't recall)? If it is something like a subdevice bit, it's likely to be least significant.

Another bad theory is that it's an extra OBC bit. But the other 8 OBC bits all seem to be real, so there would be 9, which is rather inconvenient.

Did I miss some check bits somewhere, or misdecode these entirely or something?

[jon_armstrong]

In that CCF, the bit right before the OBC varies. That's the high bit of the subdevice as presently decoded. But that's clearly wrong.

From the CCF I'd guess toggle bit. But that IR file from the other thread seems to contradict that guess.

Maybe Im missing something. In that file there were two different patterns. This is the way I decoded it:

The first column is the order in the text output from ccf2efc. The first group was the Nokia Quad with an extra 8-bits (four burst pairs) for a total of 32 bits. In msb first the bytes in hex.

01 21 20 2A 67 Freeze
02 21 20 2A 0D ð
03 21 20 AA F6 Zoom
04 21 20 2A FF A/V ð
05 21 20 AA 0C Power Toggle
06 21 20 AA 10 Vol+
07 21 20 AA 11 Vol-
12 21 20 2A 5C OK
13 21 20 AA E8 Í
14 21 20 2A 54 Menu

The arrow keys had 6 burst pairs and the order in the file and then the binary.


11 01 01 00 00 11 00 Down Arrow
09 01 01 00 00 10 00 Left Arrow
10 01 01 00 01 00 00 Right Arrow
08 01 01 00 01 01 00 Up Arrow

Did we have an rational basis for making Nokia LSB (I don't recall)? If it is something like a subdevice bit, it's likely to be least significant.

I just looked and it had numerals 0 through 9 that lined up to MSB first OBC's 0 through 9.

Another bad theory is that it's an extra OBC bit. But the other 8 OBC bits all seem to be real, so there would be 9, which is rather inconvenient.

This statement makes me think we decoded it differently. The learns were pretty poor and I had to manually adjust the burst pairs to get the gaps to line up.

Did I miss some check bits somewhere, or misdecode these entirely or something?

Maybe the third byte AA / 2A is a toggle??
Manybe one manufacturer is using a different coding scheme? We probably don't have enough data points.

I would suggest U or X for some sort of mystery/check byte or a unit code and call it D:8,S:8,U:8,F:8 until we see more of it.

[The Robman]

Maybe we need to go back to the guy who has this device and borrow his remote. Of course, we could also check with UEI to see if they've already captured this device and created an official code for it. Sure it's not as much fun but sometimes it just pays to take the easy way out!

[jon_armstrong]

Maybe we need to go back to the guy who has this device and borrow his remote. Of course, we could also check with UEI to see if they've already captured this device and created an official code for it. Sure it's not as much fun but sometimes it just pays to take the easy way out!

Well I was actually going to pursue that in the link posted above, but CraigH was dilligent and found a file in the diagnosis area that was for Foxtel that I had kludged in PB.

But, maybe I figured out the AA/2A. I think it's like a keyboard and has a make and break command. Invariably those are always 128 decimal apart. You really don't need the break key except in unusual circumstances.

Regarding a COMPLETELY DIFFERENT Protocol:

Look at this

I really think this uses 16 different burst pairs (four bits) and has 16 bursts per command for a total of eight bytes.

If so this is what the last four bytes look like. The first four agree with the fixed data:

00 00 00 00 OBC=0
07 80 00 01 OBC=1
06 80 00 02 OBC=2
04 80 00 04 OBC=4
03 80 00 05 OBC=5
02 80 00 06 OBC=6
01 80 00 07 OBC=7
00 80 00 08 OBC=8
0F 80 00 09 OBC=9
09 80 00 0F OBC=15
07 80 00 10 OBC=16
06 80 00 11 OBC=17
04 80 00 13 OBC=19
03 80 00 14 OBC=20
0A 00 00 15 OBC=21
09 00 00 16 OBC=22
08 00 00 17 OBC=23
0F 80 00 18 OBC=24
06 00 00 19 OBC=25
04 00 00 1C OBC=27
0C 80 00 1C OBC=28
00 00 00 1F OBC=31

If you sum up the nibbles from right to left you get the bottom nibble of zero. Come to think of it the second byte may be a make and break too.

Note: I re-tested and 00 is the make and 80 is the break.

[johnsfine]

I would suggest U or X for some sort of mystery/check byte or a unit code and call it D:8,S:8,U:8,F:8 until we see more of it.

I put "X=" with the third byte value (42 or 170) in the misc column. I'm not thrilled, because people will probably ignore the misc column, but I couldn't come up with anything better.

For the arrows, I hadn't initially noticed how different they are. I can't see the correspondense between what you described and what my decoder now sees. Each arrow is a strange sequence of short (6 bit-pair) frames. Obviously my 4/8 split into dev and OBC is totally wrong and I am looking at the multiple frames seperately, which is clearly wrong. But I don't know how to aggregate or otherwise interpret it without better samples.

I don't even know for sure which device it is in that CCF. The CCF says it's the "Beamer", which I assume means projector. But the projector is Philips and there is a Nokia d-box in the same config but2 I thought the Nokia d-box protocol was well established (and not this) by other CCF's. There are too few functions to make sense for either.

I put the working copy of the DLL in

http://john.fine.home.comcast.net/ir/DecodeIR_test.zip

Please try it and tell me what should be changed.

[jon_armstrong]

I put "X=" with the third byte value (42 or 170) in the misc column. I'm not thrilled, because people will probably ignore the misc column, but I couldn't come up with anything better.

It's a lot better than before. I still think the top bit in that byte is a make/break indicator, but we certainly don't have enough data to reach that conclusion.

For the arrows, I hadn't initially noticed how different they are. I can't see the correspondense between what you described and what my decoder now sees. Each arrow is a strange sequence of short (6 bit-pair) frames. Obviously my 4/8 split into dev and OBC is totally wrong and I am looking at the multiple frames seperately, which is clearly wrong. But I don't know how to aggregate or otherwise interpret it without better samples.

I just manually decoded it again and the pronto hex sequences for the arrows are extremely long. You decoder shows alternating device bits and if you look at the hex, it just isn't there. It does look like the behavior changes. Perhaps if you press harder/hold down longer the slew rate changes??

Here is the first command that occurs in the file for an arrow key:

Code: Select all

0000 0072 0088 0008 
000F 000A 0006 0010 0006 000A 0006 000A 0006 000A 0006 0016 0006 000A 0006 035A 
000F 000A 0006 0010 0006 000A 0006 000A 0006 000A 0006 0016 0006 000A 0006 035A 
000F 000A 0006 0010 0006 000A 0006 000A 0006 000A 0006 0016 0006 000A 0006 035A 
000F 000A 0006 0010 0006 000A 0006 000A 0006 000A 0006 0016 0006 000A 0006 035A 
000F 000A 0006 0010 0006 000A 0006 000A 0006 000A 0006 0016 0006 000A 0006 035A 
000F 000A 0006 0010 0006 000A 0006 000A 0006 000A 0006 0016 0006 000A 0006 035A 
000F 000A 0006 0010 0006 000A 0006 000A 0006 000A 0006 0016 0006 000A 0006 035A 
000F 000A 0006 0010 0006 000A 0006 000A 0006 0010 0006 0016 0006 000A 0006 0354 
000F 000A 0006 0010 0006 000A 0006 000A 0006 0010 0006 0016 0006 000A 0006 0353 
000F 000A 0006 0010 0006 000A 0006 000A 0006 0010 0006 0016 0006 000A 0006 0354 
000F 000A 0006 0010 0006 000A 0006 000A 0006 0010 0006 0016 0006 000A 0006 0353 
000F 000A 0006 0010 0006 000A 0006 000A 0006 0010 0006 0016 0006 000A 0006 0354 
000F 000A 0006 0010 0006 000A 0006 000A 0006 0010 0006 0016 0006 000A 0006 0353 
000F 000A 0006 0010 0006 000A 0006 000A 0006 0016 0006 0016 0006 000A 0006 034D 
000F 000A 0006 0010 0006 000A 0006 000A 0006 0016 0006 0016 0006 000A 0006 034E 
000F 000A 0006 0010 0006 000A 0006 000A 0006 0016 0006 0016 0006 000A 0006 034D 
000F 000A 0006 0010 0006 000A 0006 000A 0006 0016 0006 0016 0006 000A 0006 034D 
000F 000A 0006 0010 0006 000A 0006 000A 0006 001C 0006 0016 0006 000A 0006 0347


The decoder returns this both in the exact same sequence as the ccf file decode with ccf2efc:

(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):2:4 EFC=242
(Nokia12):2:4 EFC=242
(Nokia12):2:4 EFC=242
(Nokia12):2:4 EFC=242
(Nokia12):3:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):0:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):1:4 EFC=242
(Nokia12):2:4 EFC=242
(Nokia12):2:4 EFC=242
(Nokia12):2:4 EFC=242
(Nokia12):2:4 EFC=242
(Nokia12):3:4 EFC=242

I don't even know for sure which device it is in that CCF. The CCF says it's the "Beamer", which I assume means projector.

here is a link to the projector. I think "beamer" is German slang for Projector.

I put the working copy of the DLL in

http://john.fine.home.comcast.net/ir/DecodeIR_test.zip

Please try it and tell me what should be changed.

I think the length of the pronto hex is throwing off your Nokia12 decodes. Let me know if you need more data.