General Instruments Jerrold SRC II Cable Box

[mr_d_p_gumby]

Whomever is in charge of protocols might want to have a look at that KM drop down box Jerrold protocol, as it does not seem to agree with DecodeIR.exe's version of what a Jerrold protocol should look like.

I just checked KM's S3C8 0006 Jerrold protocol code byte-for-byte, and it agrees with all other sources for this protocol.

1) Steve messed up in testing and the original KM upgrade would have worked if tested properly.
2) 5% speed difference somehow matters.

I'll add my vote to this assessment.

[mr_d_p_gumby]

Question: If a protocol has no frequency what frequency does the remote use? I am guessing that when a protocol has no frequency listed, any frequency will work?

No, it does not use a "frequency" at all in these cases. The frequency being referred to here is an IR carrier frequency upon which the data stream is modulated, much like an AM radio station. Some protocols (like the Jerrold being discussed here) do not use a carrier frequency at all. Instead, they simply transmit a series of single IR pulses of a specific width.

[johnsfine]

Question: If a protocol has no frequency what frequency does the remote use? I am guessing that when a protocol has no frequency listed, any frequency will work?

A frequency tells the remote to break up any "On" period into smaller pulses. (The Off periods aren't affected).

Your PB file says 39.8 at 32%, which would mean any "On" is broken into an alternation of 8 microseconds actually on and 17 microseconds off.

Your PB file then says a '1' is 20 uS "On" and 8012 uS "Off". The 20 uS "On" becomes 8 uS actually on and 12 uS off (the 25uS period of the frequency is cut short without even one cycle completing).

So the frequency specified never really appears in the IR signal. By specifying it you changed 20-8012 into 8-8024.

Clearly nothing cares about that 8012 vs. 8024. It maybe somewhat surprising, but your Jerrold device doen't care about the 8 vs. 20 either. Pulses that short are never reproduced accurately anyway, so the Jerrold just expects to see a single short pulse. It doesn't care how long the short pulse is.

The Pid 0006 version uses 7660 instead of that 8012. That's further off than the learning logic in your UEI remote would have mislearned it. I'd think it would be further off than your Jerrold remote would have mistransmit it (so your Jerrold design might actually be that much slower than typical). But I still don't like the idea that your device actually cares about that difference.

[usblipitor]

John,

Thank you for your note! I now understand frequency! (1/40)x.32=8 µS, (1/40)x.68=17 µS. I only put in a frequency because I thought it was a needed field. When I removed the Frequency from my protocol builder spreadsheet, the protocol still worked. So the frequency is not needed, you are correct, as usual!

However, I revised my KM device upgrade using the canned Jerrold protocol and it still did not work. I have uploaded the KM file and the IR file for the upgrade that did not work, and called it: 00_Jerrold_CableBoxDoesNotWork.zip

On a somewhat different tangent, I noticed that you could decipher the canned Jerrold protocol pretty well and noted it was similar to the one I designed. How did you do this? I can see my settings for the protocol I designed by just looking at what I put in protocol_builder_spreadsheet. But what tools are needed to decipher the built-in Jerrold protocol? If it requires assembler, I am not afraid, but a bit rusty (used to program 8086 assembler in engineering school 20 years ago before I went to medical school). What tools do you suggest I need? If it is just eyeballing it, where can I read about protocols further? The barry gordon doc was helpful in explaining protocols but not in interpreting the assembler code. I vaguely recall seeing a disassembler somewhere, would this be useful to me?

I just have to say this. IMHO, you are one bright guy. (Ditto for Jon, Jason, Gregg, Mark, Tommy, Rob, Nils, David, Mike, Tommy again, and Hal, in no particular order!) Thank you, and all the other JP1 giants. You all have wonderful brains.

[johnsfine]

On a somewhat different tangent, I noticed that you could decipher the canned Jerrold protocol pretty well and noted it was similar to the one I designed. How did you do this?

Unfortunately I did it by just looking at the hex. If I'd done it right we would have had the answer sooner.

You can paste a protocol into position G24 in in the protocol builder and press the Decode button. It will interpret most aspects of the protocol that PB is capable of reproducing. On some protocols that totally misses the point, but on others (including this one) that tells you everything.

UEI usually has the '1' and '0' definitions reversed vs. the most sensible interpretation of the protocol. It looks like both DecodeIR.DLL and KM are coded based on the assumption that those bits are reversed in Pid 0006. But the Pid 0006 provided by KM does not reverse them (and I think the Pid 0006 built-in on other models doesn't either).

Your upgrade has those bits reversed (at least vs. KM's pid 0006) and that is probably what makes it work, because some aspect of KM or DecodeIR is definitely getting the bits backwards as you go from a learned signal to an upgrade. I'll need to check a few details later to see where this polarity ought to be corrected.

[usblipitor]

Unfortunately I did it by just looking at the hex. If I'd done it right we would have had the answer sooner.

You are a genius for being able to look at the hex and see anything. Sort of reminds me of Neo looking at the matrix!
Any suggestions as to where I can go to learn more about the hex code that makes up a protocol? What part of the assembly code means what?
Many many many thanks!