Scientific Atlanta 3100HD Cable box

JohnParks · Post by **JohnParks** » Fri Jan 09, 2004 12:59 pm

The Robman wrote:I've just created a master file of all the known SA Explorer codes. I used the 2000 and 8000 upgrades from Yahoo, plus the user and UEI codes from my site.

I only found 8 OBCs unaccounted for and I have listed these in the functions sheet.

Great list Rob, thanks for your effort.

I tried the 8 mystery codes, no luck. I'll try codes 60 to 100 or so then quit. Wouldn't think there's much point in going further.

Post by **The Robman** » Fri Jan 09, 2004 1:00 pm

There were a couple of functions in the 8000 file that I suspect are mislabelled, those being the PIP functions. Could someone either confirm that these are correct or let me know what they should be.

Same goes for any of the other functions in the master list.

JohnParks · Post by **JohnParks** » Fri Jan 09, 2004 1:40 pm

The Robman wrote:I've just created a master file of all the known SA Explorer codes. I used the 2000 and 8000 upgrades from Yahoo, plus the user and UEI codes from my site.

I only found 8 OBCs unaccounted for and I have listed these in the functions sheet.

Does this mean after trying the eight and not getting a responce, trying any other codes would be pointless?

Post by **The Robman** » Fri Jan 09, 2004 2:06 pm

JohnParks wrote:Does this mean after trying the eight and not getting a responce, trying any other codes would be pointless?

What other codes? These 8 OBCs represent the only gaps in the 0 thru 63 sequence.

That being said, you should also try all of the listed functions to see if they really do what they proclaim to do.

JohnParks · Post by **JohnParks** » Fri Jan 09, 2004 2:41 pm

I'm up to code 150. Still no luck. Don't guess there's any point to trying SA on this?

Post by **The Robman** » Fri Jan 09, 2004 3:42 pm

JohnParks wrote:I'm up to code 150. Still no luck. Don't guess there's any point to trying SA on this?

Huh? What sort of code is 150, and OBC or an EFC? There are only 64 OBCs in this protocol.

JohnParks · Post by **JohnParks** » Fri Jan 09, 2004 3:52 pm

usblipitor wrote:Mark, would this work?

press CBL (that has your 0477 code in it)
press SET-0-0-0 and see what happens.
press SET-0-0-1 and see what happens.
.
.
press SET-2-5-5 and see what happens.

Write them all down. Even if you don't find a code for closed captions, you might find other codes you did not know existed.

Good Luck,
-Steve

Then why did I do this? Could there be another protocol for this device?

Post by **The Robman** » Fri Jan 09, 2004 4:00 pm

Did you read any of my posts in this thread?

JohnParks · Post by **JohnParks** » Fri Jan 09, 2004 4:07 pm

As you may note, I can't even spell protocol. How do know there aren't any more... I'm lost!

Post by **The Robman** » Fri Jan 09, 2004 4:53 pm

OK, let's step back a bit here. The protocol is use here is the "Panasonic (Old)" protocol, which only supports OBCs 0 thru 63. Now, as you know, most UEI protocols support 256 EFCs. So, the way they implemented this protocol is let's you combine up to three different device codes. This is what we call a "quickie combo" protocol.

In this case, all three device codes are set to the same value, so when you test EFCs from 000 thru 255, you will actually test each OBC three times, plus you will test 64 EFCs that won't generate a valid signal.

So, in an attempt to save you from all this hassle, I created a master file of OBCs and I even took it a stage further and identified which OBCs were missing. This reduced the whole mystery down to just 8 OBCs that needed testing.

Post by **The Robman** » Fri Jan 09, 2004 4:56 pm

JohnParks wrote:
usblipitor wrote:Mark, would this work?

press CBL (that has your 0477 code in it)
press SET-0-0-0 and see what happens.
press SET-0-0-1 and see what happens.
.
.
press SET-2-5-5 and see what happens.

Write them all down. Even if you don't find a code for closed captions, you might find other codes you did not know existed.

Good Luck,
-Steve
Then why did I do this? Could there be another protocol for this device?

That's my bad, I should have deleted Steve's post.

JohnParks · Post by **JohnParks** » Fri Jan 09, 2004 9:54 pm

Hay Rob - So what you are saying is that when "Panasonic (Old)" was invented only 8 bit registors were available. So they used 6 bits for the command code and 2 bits for the device code. Now that 16 bit registers are the norm protocols now use 8 bits for the command and 8 for the device. So that's the reason that some protocols have 8 and some have 16. Right? When you look at it from the receivers prospective this makes sense. Adapting new technology ( the remote ) to old technology (the receiver) you have to kinda have to put a square peg in a round hole.

johnsfine · Post by **johnsfine** » Sat Jan 10, 2004 7:08 am

JohnParks wrote:So what you are saying is that when "Panasonic (Old)" was invented only 8 bit registors were available. So they used 6 bits for the command code and 2 bits for the device code. Now that 16 bit registers are the norm protocols now use 8 bits for the command and 8 for the device. So that's the reason that some protocols have 8 and some have 16. Right?

I think you are misunderstanding a bunch of aspects of this.

Panasonic(Old) protocol uses 6 bits for the command and 6 bits for the device.

When UEI impliments a protocol, they usually put the device information in "fixed data" (Data that is the same for all signals in a whole setup code) and command information in the "Hex Command" (Data that is different for each function in the setup code).

Sometimes the device manufacturer uses a few different device numbers for commands for one device. Then UEI usually creates some sort of "combo" protocol. In that case, either they put part of the device information in the Hex Command, or they put multiple versions of the device information in the fixed data and then put a selection field in the Hex Command to pick which version of Device information is used.

If the command is just 6 bits long, they typically put three versions of the device information in the fixed data and use two bits in the hex command to select.

The number of bits in a register of the micro processor used doesn't have much effect on the structure chosen. UEI has continued using microprocessors with 8 bit registers across the period in which they drifted from almost all hex commands being 8 bits toward having a significant minority be 16 bits.

When the original device manufacturer designed Panasonic(Old) they weren't using Microprocessors at all. The IR signals were encoded and decoded but simpler electronics.

JohnParks · Post by **JohnParks** » Sat Jan 10, 2004 10:49 am

Thanks John for your response. I think from now on I will just ask very specific questions. The subtleties of update, modified, advanced, OBC's, EFC's, Hex, et al. codes and their implementation are eluding me. I hope this is the dark before the dawn.

JohnParks · Post by **JohnParks** » Sat Jan 10, 2004 11:09 am

The Robman wrote:OK, let's step back a bit here. The protocol is use here is the "Panasonic (Old)" protocol, which only supports OBCs 0 thru 63. Now, as you know, most UEI protocols support 256 EFCs. So, the way they implemented this protocol is let's you combine up to three different device codes. This is what we call a "quickie combo" protocol.

In this case, all three device codes are set to the same value, so when you test EFCs from 000 thru 255, you will actually test each OBC three times, plus you will test 64 EFCs that won't generate a valid signal.

So, in an attempt to save you from all this hassle, I created a master file of OBCs and I even took it a stage further and identified which OBCs were missing. This reduced the whole mystery down to just 8 OBCs that needed testing.

Rob, could we start from here? Can I use the 'set' method mentioned by Steve to test the 8 codes for cc?