Assumptions about OBC and EFC codes, am I 'on the money'?

[JLPicard]

I have been scouring the WIKI attempting to grasp all the terms and nuances of JP1 programming can someone verify if I am right so far?

OBC: This is the code that the Device manufacturer (sony, Panasonic...) requires to control their device's function.

EFC: This is the number code either 3 or 5 digits generated by a specific remote that via software translates into the OBC that it was programmed to control.

OBC's remain standard on one machine, one function, they don't change.

The EFC from a specific remote won't change either for that one OBC.

EFC's will be different across different remotes.

EFC's are not 'random' as we can trade EFC codes between remotes to generate the corresponding OBC.

[mdavej]

Almost. The EFC for a given OBC will be different for different protocols. For example a certain OBC will have one EFC for NEC1 and another for NEC1 Combo because combo protocols need more information to tell the remote what signal to send.

But this is all academic. Our software sorts all this out for you, so you usually don't have to worry about such details. All you really need to know is if you find OBCs on the net or learn them, you can enter them into our software which will calculate the right EFC for you. EFC's are useful for manually sending or programming functions. With our JP1 tools, you generally just copy/paste what you need without needing to understand or even know what the codes are. A few experts will know the inner workings of EFCs, but average users generally don't need to be concerned.

There's a lot of info out there, too much to digest at once. I recommend you follow the tutorials at first to learn how to use the software, then come back to the wiki for reference when you hit a wall.

[JLPicard]

Almost. The EFC for a given OBC will be different for different protocols. For example a certain OBC will have one EFC for NEC1 and another for NEC1 Combo because combo protocols need more information to tell the remote what signal to send.

PROTOCOL: A set of rules that describe how an IR signal needs to be formated. A program that momentarily takes control of the remote while it transmits (over the IR link) the button code specified in the manufacturer's code for the pressed key. Such protocols are sometimes called executors by UEI and in the Forums. The term protocol is also used to refer to the characteristics, or signature, of the IR signal.

So, one remote, one OBC, one EFC and that ONE remote can utilize different protocols depending on the complexity of the needed information by the device? The one OBC=one EFC is always the same as long as that one OBC/EFC is using the same protocol right?

And how do you find out what protocol(s) a specific remote is using? I noticed in RM when you select the remote you are working with, it does not autoselect it's corresponding protocol, that must be manually selected.

I first tried the tutorials but they are written with older versions of IR, KM and RM. Often you can sorta extrapolate and get what is intended. The other problem with a true noob is that the terms begin to get overwhelming. So I changed my approach and made the Glossary my first stop, then the Wiki, with the Glossary open side by side. That's where I am now. I don't have a cable yet. Just trying to Keep It Simple Stupid for now, and making sure I have a good grasp on the terminology. Thanks for the response!

[vickyg2003]

I have been scouring the WIKI attempting to grasp all the terms and nuances of JP1 programming can someone verify if I am right so far?

I had a difficult time understanding EFC and OBC too.

This link is how I described it.
http://www.hifi-remote.com/wiki/index.p ... s_and_OBCs

You're a bit off on your EFC understanding.

EFC: This is the number code either 3 or 5 digits generated by a specific remote that via software translates into the OBC that it was programmed to control.

An EFC is a 3 or 5 digit number that can be entered from the keypad to allow a signal to be sent.

The EFC from a specific remote won't change either for that one OBC.

The OBC sent from an EFC will vary depending what executor is being used to send the signal. The executor is determined by the setup code in use.

EFC's will be different across different remotes.

No, although the older remotes only handle 3 digit EFC's and have to be padded with two 00, 001 becomes 00001 the EFC's are the same for THE SAME SETUP CODE across remotes.

The setup code determines which protocol executor is used.

[vickyg2003]

And how do you find out what protocol(s) a specific remote is using? I noticed in RM when you select the remote you are working with, it does not autoselect it's corresponding protocol, that must be manually selected.

Its determined by the setup code.
You can look up which executor your setup code is using with the lookup tool.
http://www.hifi-remote.com/jp1/lookup/

[mdavej]

Another example might help. You get a new TV that's not in our file section. So you learn a few commands from the original remote. Our software decodes the learns and tells you that they use the NEC1 protocol. In general, every modern JP1 remote will use exactly the same NEC1 protocol and EFCs, so that does not change.

But when the signals get more complicated, so can the protocols and EFCs. Your TV might only show one sub-device (another protocol related parameter) for every command, so NEC1 will work for all commands. But it might show 2 or 3 different sub-devices, so NEC1 won't work for all commands. You can use NEC1 for some, but you'll need NEC1 Combo for all of them since it can handle multiple sub-devices. That's when EFCs start changing. But a given EFC and it's associated protocol will be the same across all remotes.

All you need to know as a beginner is to set up your remote, find your devices in our file section, open them in RMIR and pick your remote model. That's it. You don't have to worry about protocols, EFCs or OBCs at this point.

[JLPicard]

So instead of saying I have aaaah Sony BDP BX37 as a device, I can just state the protocol it requires instead (I think it's Sony20)? The protocol is tied to the device and device code. Any UEI remote that wants to control this BluRay would have to use the same protocol right?

I am having problems finding the code for my blue ray player for the Atlas 1056.

[vickyg2003]

All you need to know as a beginner is to set up your remote, find your devices in our file section, open them in RMIR and pick your remote model. That's it. You don't have to worry about protocols, EFCs or OBCs at this point.

Well even a beginner should know that you need to know is that when working from a decode, you use the OBC, not the EFC when creating your upgrade. The decodes often offer up an EFC, but that is for the vanilla flavor of the executor. Compound executors or different variants might have a different EFC, so the OBC should be used instead of the EFCs when creating upgrades with KM or RM.

[eferz]

So instead of saying I have aaaah Sony BDP BX37 as a device, I can just state the protocol it requires instead (I think it's Sony20)? The protocol is tied to the device and device code. Any UEI remote that wants to control this BluRay would have to use the same protocol right?

I am having problems finding the code for my blue ray player for the Atlas 1056.

The best thing to do if you need to find codes, is to fill out a template from this post http://www.hifi-remote.com/forums/viewtopic.php?t=49 then post it into the Code Search forum: http://www.hifi-remote.com/forums/viewforum.php?f=25. That gives us enough information to work our magic. Then one of the experts will step in and say Abracadbra Bibbity Bobbity Boo Hocus Pocus and all of your wildest dreams will come true.

[JLPicard]

Not to beat a dead horse, but I am still getting the same assumptions that I made in the OP:

OBC: This is the code that the Device manufacturer (sony, Panasonic...) requires to control their device's function.

In order to get the PLAY function to work on a Sony BDP BX37 to work there MUST be a specific OBC sent to it. No other OBC will work.

EFC: This is the number code either 3 or 5 digits generated by a specific remote that via software translates into the OBC that it was programmed to control.

I am off on this, it isn't generated, it's inputted with the keypad of a remote to generate a specific OBC, and therefore, a specific function. (PLAY)

OBC's remain standard on one machine, one function, they don't change.

Same as the first quote, the OBC is standard on a certain device. There is one and only one OBC required to get the PLAY function to work on a BDP BX37.

The EFC from a specific remote won't change either for that one OBC.

The EFC inputted into a ATLAS 5066 remote to generate the PLAY on this sony blue ray, will be the same EFC needed by all the other Atlas 5066 remotes of the same model. You can share EFC's to other uses of the same remote/device.

EFC's will be different across different remotes.

Not sure about this. Since a different remote than our ATLAS 5056, in order to control the PLAY on this sony Blue Ray, is required to generate a specific OBC, using the same protocol, does it require the same EFC or will it require a different one based on the model of the remote?

EFC's are not 'random' as we can trade EFC codes between remotes to generate the corresponding OBC.

True!

Ok the horse is dead, if the above seem correct I think I can move along. Thanks for your patience with me.

[3FG]

The Atlas 1056 B01 and older Atlas remotes are not capable of controlling a Sony Bluray player. The remotes were designed before Sony started shipping Bluray players.

We JP1ers tend to be very casual in describing concepts, and we frequently overuse words. "Device" is the worst example, and "device" has many different meanings. "Protocol" is also a source of confusion.

1) A IR protocol is a template that describes how to turn information (like OBC and device number) into a pattern of flashes. The required IR is, as you have surmised, a characteristic of the component being controlled. A Sony Bluray will only respond to a Sony IR protocol of 20 bits, with device number 26, subdevice 226, and some selected OBCs. Any remote must send commands formatted in this IR protocol in order to control the Bluray.

2) UEI remotes generate the flashes using a subroutine in the remote's firmware. This subroutine is variously called the executor, the protocol executor, or (confusingly) the protocol. (Some other remotes, and UEI remotes when learning, simply store a set of on and off durations for each IR signal.) Executors can be complicated. For example, the NEC 4DEV Combo executor can send NEC1, NEC2, NECx2, and NECx2 IR protocols. It additionally can select among 4 different device.subdevice pairs. This is convenient since Yamaha, for example, uses multiple device.subdevice pairs in their receivers.

3) There is no uniform convention on how to interpret the pattern of flashes as OBCs and device/subdevice numbers, and a single pattern of flashes can be interpreted using the first on/off pair as the least significant bit of the OBC or as the most significant bit. In the same way, a single example of a on/off pair may be interpreted as either a 0 or a 1, depending on the way the original engineers looked at the issue.

4) A setup code is an index into a table of data needed by the executor to send a particular IR command, including the ID of the required executor, and the the OBC assigned to an individual button. This data is divided into a) fixed data, which is the same for all OBCs, and b) variable or command data that is different for each OBC. There are typically 4 pages of setup codes, organized by applicability to Cable/Sat, TV, Video, and Audio. For complicated executors, the input data has to include selector bits that choose e.g. the NEC style and the device.subdevice pair.

5) Taking 2, 3 and 4 into consideration, the input data to the executor varies, depending on which executor is in use. It is possible to send NEC1 signals using the executors named NEC Combo, NEC 4DEV Combo, or simple NEC1. The input data is different for each one.

Now about EFCs and how they can be used in manually programming the remote. A given setup code will specify the executor, and the fixed data, and this is not changeable from the keypad. But we can manually enter EFCs which will specify the command data associated with a button. The EFC is just an encoded version of the command part of the input data to the excutor. Since the input data for a given IR command is different depending on the executor in use, the EFC also depends on the executor. If two models of UEI remotes both have a particular executor with corresponding fixed data (typically true if both have the same setup code), then the EFC corresponding to a IR signal will be the same for both remotes. This is usually true even for different families of UEI remotes.

Sony Bluray players use the Sony20 IR protocol. Atlas remotes have an executor which we call Sony20 since it sends the Sony20 IR protocol, and so it is tempting to think that it could therefore control Sony Bluray players. However, excepting for the 1056B03, Atlas remotes don't have the needed fixed data to describe device/subdevice 26.226. We can't change the fixed data from the keypad, so entering any EFC is futile.

Of course a JP1.3 cable will allow you to make a custom setup code with the needed fixed data, and to assign the needed command data to each button.

[vickyg2003]

I've updated the EFC-OBC topic in the wiki, with a little more information,
http://www.hifi-remote.com/wiki/index.p ... s_and_OBCs

The protocol executor (PID) is selected by the setup code.

For EFCs to work from the keypad, they require the current setup to hold the fixed data and PID for the correct protocol executor. An EFC-style keymove, will remember the setup code in use when the keymove was created.

Does that help?

[eferz]

Yep, all but one command uses 26.226 sub-device from the respective device LHD profile. But, he should be able to program one button on the remote. (iThink, LOL)

Command: Theater
EFC5: 12843
EFC: 250
Protocol: Sony15
Device: 119
Sub-device: none
OBC: 96
Hex:07 EE

[vickyg2003]

Yes, if JLPicard used a setup code such that usese the Sony(12/15/20) as Aud 1658, or TV 1217, or Video 1033, he could send the theater command with EFC 12843. Not much use. The Sony20 26.226 is only built in to the newest remotes, but with a cable its easy enough to create a new upgrade for this blu ray player with our tools.

[The Robman]

Here's one final clue that might help understanding EFCs. There is a one-to-one relationship between an EFC and the hex code that it generates to be fed into the protocol executor. It's possible for multiple executors to generate the same signal, but they might require different hex codes to do so, so therefore they would also require different EFCs.

If EFCs seem confusing, that's the general idea. UEI deliberately designed the EFC to be confusing in an attempt to hide the true data behind it (ie, the OBC, device codes, etc).

So what's the bottom line here? If your goal is simply to get your BluRay programmed, follow the advice that others gave and use the Code Search forum. If your goal is to understand how everything works, are you there yet? Can you read binary?