Zenith protocol (having trouble using upgrade with 15-2116/7

shargrov · Post by **shargrov** » Mon Oct 13, 2003 5:57 pm

I've installed the following upgrade for the Zenith HD-SAT520.

Upgrade Code 0 = 72 08 (SAT/0520)
22 00 FE FA 00 A1 07 40 44 48 4C 50 54 58 5C 60
64 00 00 2E 24 04 38 6C 70 0C 7C 3C 18 30 78 34
70 1C
KeyMoves
2F F3 72 08 08
End

I first learned groups of commands to the remote and used the EFCs (as displayed in IR) in KM to create the upgrade. Then pasted this back into IR. All seemed to work well and I can now assign the new code (0520) to the SAT button. However, none of the buttons work. When I learned the buttons they worked fine. Any ideas what my problem is?

Thanks,
Steve

Mark Pierson · Post by **Mark Pierson** » Mon Oct 13, 2003 6:09 pm

shargrov wrote:I first learned groups of commands to the remote and used the EFCs (as displayed in IR) in KM to create the upgrade.

Your upgrade is using the Zenith protocol. Is that what IR reported as the protocol when you looked at the Learned Signals?

shargrov · Post by **shargrov** » Mon Oct 13, 2003 6:20 pm

Yes, the first line displayed Zenith. There was also a second line that displayed Async13:564-598:FF.FD..FF.FD

shargrov · Post by **shargrov** » Tue Oct 14, 2003 7:42 am

Can anyone provide more detail on the Zenith protocol parameters: signal length, long record, and style?

I've tried a few different combinations with no luck.

Post by **The Robman** » Tue Oct 14, 2003 8:59 am

If you post your file with the learned signals in it to the Diagnosis Area, we should be able to see exactly what the signal looks like. If this SAT is really a PVR and therefore uses the RECORD button, please also include a learned version of that button.

I forget exactly how IR displays Zenith signals, so I don't recall if it specified the length.

In KM, the first parm is the length of the signal in bits, with 6 being the default. The second parm specifies whether a long RECORD signal is needed. Zenith VCRs require that the RECORD button be held down for several seconds for it to work, so there is a feature built into the Zenith protocol that does this for you, VCR/0039 is an example of this. The final parm specifies which of two styles to use, and I'm sorry to say that I have completely forgotten what this means. Hopefully one of the Jo(h)ns can remind me.

Then, once we've got that last piece, I think this should be added to the KM protocols file (it's our bad for not including it before)

johnsfine · Post by **johnsfine** » Tue Oct 14, 2003 9:08 am

It's in the ReadMe for DecodeIR.

Since Zenith has no device number and IR's decoding interface has no way to report "signal length", my decoder reports the signal length as a device number.

It also reports the extra half-bit of data in each signal as "subdevice". KM calls that extra half bit "style".

The decoders for "Async" and "Sharp" tend to get confused by Zenith signals and think they've decoded something. If you know you have a Zenith signal but get an Async or Sharp decode, you should ignore that decode.

Post by **The Robman** » Tue Oct 14, 2003 9:14 am

So maybe we should change KM to use the fake device and sub-device codes, rather than the more accurate (but potentially more confusing) descriptions that it currently uses.

The style bit affects the EFC, does DecodeIR handle that?

Also, do you happen to recall what the style bit actually does?

johnsfine · Post by **johnsfine** » Tue Oct 14, 2003 9:40 am

The "subdevice" seems to be the top bit of the hex command computed by decodeIR, so it does get encoded in the EFC.

I have only a vague recall of how Zenith uses that bit, so I could be all wrong in this, but I think I remember that it is used to distinguish between different types of device, thus someone decided to make it part of the device level info rather than part of OBC level, even though it goes into the hex command rather than fixed data in the actual implementation.

shargrov · Post by **shargrov** » Tue Oct 14, 2003 7:18 pm

Okay, the IR file is in the diagnostic folder. It is called IR_Zenith_SAT_debug.txt. I IR learned all the signals that would fit in memory. This is not a PVR so there is no record feature.

Thanks for the help guys.

johnsfine · Post by **johnsfine** » Tue Oct 14, 2003 8:29 pm

It seems straightforward. What do you need help with? The signal length is 6 (decoded as device as described above). The "style" is 0. The EFCs are computed by the decoder. It should be quite easy to set up in KM.

The last signal (down) looks like the batteries on the zenith remote were dying as you learned it. Probably it could be manually decoded, but relearning is a better idea. Batteries partially recover when left unused for a few hours and/or I could be wrong about the problem being due to weak batteries, so the relearn might work without changing batteries. If you have further learning problems, change batteries.

shargrov · Post by **shargrov** » Tue Oct 14, 2003 8:59 pm

I thought it was straigtforward also. However, the upgrade that I included in the original post does not work. I'll post the KM file (KM_Zenith_SAT_debug.txt) in the diagnostics folder.

The down signal is not an issue. That was the last one that I got in before the memory was full. I learned it successfully the first time but had to relearn a few signals so that I could post the file. The IR file is just a sample of the Zenith signals.

Steve

shargrov · Post by **shargrov** » Wed Oct 15, 2003 8:50 am

New Inormation

I used an additional remote to learn the signal generated by the upgrade, and compared this to the signal generated by the OEM Zenith remote, using IR. The protocol was Zenith but the length was 5 for the upgrade, not 6. Also the frequency was 40201 for the upgrade signal and 40000 for the learned signal from the OEM Zenith remote.

I tried to compensate by increasing the length in KM from 6 to 7 but this gave me a learned length of 7 instead of 5. I have feeling that the frequency for this protocol may have changed but I'm not sure how top address this.

johnsfine · Post by **johnsfine** » Wed Oct 15, 2003 10:53 am

That difference in frequency doesn't matter at all.

That difference in length does matter. I looked at the upgrade you posted in the diagnostic folder. I looked at the version you posted at the start of this thread. I looked at how KM handles your upgrade and I looked at previous data I have on protocol 0022. I have no clue how that upgrade could send 5 bit Zenith instead of the correct 6 bit Zenith.

It will be quite a while before I would get a chance to try duplicating your results (learn the signals from that upgrade from one JP1 remote to another). Hopefully someone else will volunteer to try that, since it seems the logical next step in diagnosing the problem.

How did the hex command (or OBC and subdevice) vary between what the upgrade should have sent and what the other remote learned? If it changed the length from 6 to 5, I assume it changed the OBC or subdevice. How it changed those might tell me why it changed the length.

David Ritchie · Post by **David Ritchie** » Wed Oct 15, 2003 5:11 pm

Hello,
I have the Zenith hdv-420 STB. Over on the Yahoo JP1 group under files/device codes/hdtv is a KM upgrade for the 520 called "Zenith-DTV-1080 (update).txt " I tried it on my 420 and it works fine. Since it was made for the 520, it should work great for you. Might want to give it a try.

Dave

jon_armstrong · Post by **jon_armstrong** » Wed Oct 15, 2003 6:23 pm

AFAIK, all the Zenith HD STB's use the same command set.

As David has said that file should work and it also has the discrete power commands and every command that exists (AFAIK).

If that doesn't work. I'll test it and your device upgrade but it may take a few days.

John and Rob, IIRC the difference in the lead-in is what differentiates the TV and cable box since they both use 5-bits. The VCR, Cable box and HDTV STB use the short lead-in and they are seven, five, and six bits respectively. There are some Zenith HDTV's that use 7-bits and the TV lead-in to differentiate from VCR's. There is also an old setup code for a seven bit TV_0016 in the 1994 that uses the short lead-in -- go figure...

Happily, LG Electronics has acquired Zenith and appears to be using NEC protocols on some of the more recent products.

JP1 Remotes

Zenith protocol (having trouble using upgrade with 15-2116/7

Zenith protocol (having trouble using upgrade with 15-2116/7

Re: having trouble using upgrade with 15-2116/7

device codes