JP1 Remotes

I have a Zenith TV which responds to TV/0017 for channel, volume, and power functions. I never had the original remote. I looked in the file section and found no upgrades for Zenith TV's that used the Zenith protocol, so I went on an EFC hunt and found nothing. I tried an old Philips universal remote, and found a partially working code. It decoded to a Zenith 5.1, which was all well and good until I got to the Display code, which turns up the same function as the Surf. So either DecodeIR is having a problem, or this is a new variant.

Can someone take a look at this code summary and see if these really do decode to be Zenith 5.1?

https://www.hifi-remote.com/forums/dload ... le_id=8220

I'm hoping someone is up to the puzzle. It sure is difficult.

Decode IR says

Zenith
UEI protocol: 0022
IRP notation: {40k,520,msb}<1,-1,1,-8|1,-10>(S:1,<1:2|2:2>(F:D),-90m)+
EFC translation: MSB
An unusual protocol, in that the number of bits in the function code is variable. It is represented in DecodeIR as the device code. There are also two lead-in styles, decoded as subdevice values 0 and 1. Style 1 aka "double-start" is usually used in TV's, other appliances use 0 aka "single start". If the device code is >8 then the bytes given in the Misc field as E = ... follow the OBC in the function code value.

Edit: I shot the working volume and power keys from that TV/0017 and it is coming up as Zenith 5.1 also.

Vicky,
This link at Remote Central has an Excel file which shows the exact encoding for a few of the Zenith discrete functions, with both single and double starts. Unfortunately, the more common functions aren't shown. But it may still help in trying to decode.

Mostly these are 7 bit codes, rather than 5 bits.

Well mystery solved. The Phillips Magnavox was failing, this morning the batteries were dead. (Those were brand new batteries!) Now I just need to figure out how to use RM and KM to build my files, and should be good to go.

3FG, I can't seem to figure out those spreadsheet, and even though I'm not going to need any discretes, I'd like to check them out for completeness.

Rob, these signals appear to be double bumps and single bumps, is that how you read these, a double bump is a 1 and a single bump is a zero?

First off, here are the times rounded to the nearest 500, just to make them easier to decode:

1: +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -120500 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -120500 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -392000
2: +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -120500 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -566500
3: +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -120500 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -566500
4: +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -120500 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -120500 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -389000
5: +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -120500 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -392000
6: +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -120500 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -120500 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -389000
7: +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -120500 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -120500 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -4000 +500 -500 +500 -4000 +500 -5000 +500 -5000 +500 -500 +500 -4000 +500 -5000 +500 -500 +500 -389000

If I'm reading the IRP correctly, you edit for 0 by replacing "+500 -500 +500 -4000 " with 0^ and edit for 1 by replacing "+500 -5000 " with 1^.

You'll still have to edit for the last digit before the leadout, so next replace "+500 -500 +500 -" with 0^- and replace "+500 -" with 1^-. Then take out the ^ symbols.

The results should look like this:
1: 00101010101 -120500 00101010101 -120500 00101010101 -392000
2: 00101100110 -120500 00101100110 -566500
3: 01010101010 -120500 01010101010 -566500
4: 01010011010 -120500 01010011010 -120500 01010011010 -389000
5: 01001010101 -120500 01001010101 -392000
6: 01010010110 -120500 01010010110 -120500 01010010110 -389000
7: 01010011010 -120500 01010011010 -120500 01010011010 -389000

Obviously, anything after the first leadout time are repeats.

Taking a closer look at the binary, I notice that after the first 0, the data comes in pairs, it's either 01 or 10.

1: 0-01-01-01-01-01
2: 0-01-01-10-01-10
3: 0-10-10-10-10-10
4: 0-10-10-01-10-10
5: 0-10-01-01-01-01
6: 0-10-10-01-01-10
7: 0-10-10-01-10-10

So if we treat the initial 0 as fixed data, then treat the variable data as 01=0 and 10=1, we would get this:

1: 0-00000
2: 0-00101
3: 0-11111
4: 0-11011
5: 0-10000
6: 0-11001
7: 0-11011

The Robman wrote:If I'm reading the IRP correctly, you edit for 0 by replacing "+500 -500 +500 -4000 " with 0^ and edit for 1 by replacing "+500 -5000 " with 1^.

Good, I'm glad you had to stop and think on that too!

You'll still have to edit for the last digit before the leadout, so next replace "+500 -500 +500 -" with 0^- and replace "+500 -" with 1^-. Then take out the ^ symbols.

The results should look like this:
1: 00101010101 -120500 00101010101 -120500 00101010101 -392000
2: 00101100110 -120500 00101100110 -566500
3: 01010101010 -120500 01010101010 -566500
4: 01010011010 -120500 01010011010 -120500 01010011010 -389000
5: 01001010101 -120500 01001010101 -392000
6: 01010010110 -120500 01010010110 -120500 01010010110 -389000
7: 01010011010 -120500 01010011010 -120500 01010011010 -389000

Obviously, anything after the first leadout time are repeats.

Yep I see that.

Taking a closer look at the binary, I notice that after the first 0, the data comes in pairs, it's either 01 or 10.

1: 0-01-01-01-01-01
2: 0-01-01-10-01-10
3: 0-10-10-10-10-10
4: 0-10-10-01-10-10
5: 0-10-01-01-01-01
6: 0-10-10-01-01-10
7: 0-10-10-01-10-10

How you EVER EVEN noticed that is beyond me. That is a skill/art that continues to elude me.

So if we treat the initial 0 as fixed data, then treat the variable data as 01=0 and 10=1, we would get this:

1: 0-00000
2: 0-00101
3: 0-11111
4: 0-11011
5: 0-10000
6: 0-11001
7: 0-11011

So is why this is ZENITH "5"? I went back to the lookup tool and looked at some of the other possibilities for Zenith protocols and I see Zenith 6 and Zenith 7. So if something decoded as Zenith 7, it would have 7 data bytes?

vickyg2003 wrote:How you EVER EVEN noticed that is beyond me. That is a skill/art that continues to elude me.

Sure, that's why I spell out each step so you can see what I'm doing.

I don't recall the various Zenith formats, nor what the UEI executors can replicate, so I can't comment on your Zenith questions. I just decoded the data that you posted.

There appears to be a bug in DecodeIR (2.41) wrt this protocol. First, the source and Graham's article says bitorder lsb, while DecodeIR.html, as well as Makelearned's Zenith.irp says msb. Secondly, it appears that S is getting flipped, 0 gets 1 and vice versa. Code inspection verifies this: A "long" sequence reports S = 1, while a "short" gets S = 0 .

Feeding the codes of Rob's first post to DecodeIR reports D=5 (ok), S=1 (not ok), and F in order 31, 26, 0, 4, 15, 6,4, which is not at all consistent with Rob's text. Thirdly, the F appear to come out with the bits permutated.

Happy if someone can clarify.

Well. of course function numbers are somewhat arbitrarily determined--one can reverse the order of the bits and complement the bits, so for any physical IR signal, there are 4 possible function numbers. Note that Rob's numbers above are simply the complement of the numbers reported by DecodeIR.dll. He said that he simply decoded the signals, and didn't try to match the numbers up with our tools or the UEI executors.

We have several consistent sources for the Zenith function numbers:
1) The spreadsheet linked in the 2nd post of this thread
2) UEI EFCs
3) RemoteMaster
4) KeymapMaster
5) DecodeIR.dll
All of these use or report the same function numbers for a given function.
Inspection of learned Zenith codes shows that the MSB of the function numbers is sent first.
The "subdevice" number (0 or 1) is also consistent across items 2-5 above. All of these use the convention that S=0 means a single start or short. I suspect that convention arises from the behavior of the UEI Zenith executors, which use the most significant bit of the Hex data as a flag to determine short versus long.

I don't have a Zenith.irp file in my MakeHex directory, so I don't know about that, but I will say that the IRP notation doesn't correspond to the above behaviors. (i.e simply reversing the assignment of zero and ones) would make every thing consistent.

I don't see why you conclude that the DecodeIR.dll source implies that the order is LSB, and I'm not sure what the IRPSpec document says about the order.

Thanx 3FG for your answer. So it makes sense to consider 1-5 in your listing as correct, and the irp-notation as wrong, and the one you suggested as correct. Some specific comments:

Well. of course function numbers are somewhat arbitrarily determined--one can reverse the order of the bits and complement the bits, so for any physical IR signal, there are 4 possible function numbers.

That is probably clear to most readers of this forum; flipping the bit order or complementing "just" permutates the set of input commands. However, to do systematic work, we have to agree one one convention.

I don't see why you conclude that the DecodeIR.dll source implies that the order is LSB,

... so I tell you: I did not "conclude" but read the comment in the source code, which give the incorrect, lsb-version. Line 4494.

and I'm not sure what the IRPSpec document says about the order.

At your service. It is pretty obvious that the author (Graham) did not write "lsb" as typo.

I hope to get agreement on an IRP form for Zenith which is consistent with the rest of our tools, because I plan to release an augemented version of DecodeIR.dll and .html soon.

I've taken some learned Zenith signals from a CCF file at Remote Central.

Here's the learned Power On for model DPDP40V22
0000 0067 0000 0011 0015 0014 0015 00A4 0015 00CD 0015 0013 0015 00A4
0015 0013 0015 00A4 0015 00CC 0015 0013 0015 00A4 0015 00CC
0015 0013 0015 00A4 0015 00CC 0015 00CD 0015 0013 0015 1327

The spreadsheet linked in post #2 gives the following IR signal for Power On for this model:
5-BIT DATA, DOUBLE-START 0 1 1 1 0 === 0E

DecodeIR decodes this signal as 5.1, OBC 14 = 0E. All of our Zenith upgrades show Power as OBC =14 (quite possibly because the original signals were learned and decoded by DecodeIR....)
But if we take the IRP form as shown in DecodeIR.html we get the correct bit sequence, but the complement of the function number. Rob, in his post above, uses this IRP form, and also gets OBCs which are the complement of the output of DecodeIR.

Here's the details of the decoding:
0000 0067 0000 0011 Freq=40KHz, 17 (0x11) repeating burst pairs
0015 0014 0015 00A4 S=0
0015 00CD 0015 0013 0015 00A4 1
0015 0013 0015 00A4 0015 00CC 0
0015 0013 0015 00A4 0015 00CC 0
0015 0013 0015 00A4 0015 00CC 0
0015 00CD 0015 0013 0015 1327 1

Extracting Ratio Wide from the CCF for model D60W gives:
0000 0067 0000 0016 0015 00CC 0014 0014 0014 00A4 0014 00CC 0014 0014 0014 00A4
0014 00CC 0014 00CC 0014 0014 0014 00A4 0014 0014 0014 00A4 0014 00CC 0014 0014
0014 00A4 0014 00CC 0014 00CC 0014 0014 0014 00A4 0014 0014 0014 00A4 0014 0EAC

The spreadsheet says the D60W has the following IR signal
RATIO WIDE 7-BIT DATA, SINGLE-START 1 1 0 1 1 0 1 === 6D

DecodeIR gives Ratio Wide as 7.0 OBC 109 = 6D
0000 0067 0000 0016 Freq=40KHz, 22 (0x16) repeating burst pairs
0015 00CC S=1
0014 0014 0014 00A4 0014 00CC 0
0014 0014 0014 00A4 0014 00CC 0
0014 00CC 0014 0014 0014 00A4 1
0014 0014 0014 00A4 0014 00CC 0
0014 0014 0014 00A4 0014 00CC 0
0014 00CC 0014 0014 0014 00A4 1
0014 0014 0014 00A4 0014 0EAC 0
Again, the result is the complement of the OBCs used in our tools.

If we change the IRP form to then the bits are complemented and the IRP form is consistent with the output of DecodeIR, the spreadsheet, and our upgrades.

Comments?