JP1 Remotes

vickyg2003 · Posted: Sun Apr 25, 2010 3:57 pm Post subject: EFC considerations

I know its best if when we design an executor if we can make it work with a 3 digit EFC, because those upgrades are more versitile. But what about when we are using 5 digit EFCs. I know that some HEX can't be translated into EFC's. That is I've seen some times in RM where we needed to tweak the hex to get the desired signal, but the 5 digit EFC didn't change. So it would seem that sometimes 5 digit EFC's can't be made, but I would like to know how to avoid that.

Anyone care to fill me in? What make the hex unusable with a 5 digit EFC?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

mr_d_p_gumby · Posted: Sun Apr 25, 2010 6:19 pm Post subject:

A 5-digit EFC can fully represent one or two bytes of hex data, and vice versa.

vickyg2003 · Posted: Sun Apr 25, 2010 6:45 pm Post subject:

Oh

, you are going to make me find that post aren't you! I looked for it before I posted the question so I'd have an example but gave up.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

The Robman · Posted: Sun Apr 25, 2010 7:16 pm Post subject:

I was going to say everything that Mike said.

For 1-byte protocols, there is a 1-to-1 relationship between EFC3 values and the 1-byte hex codes.

For 2-byte protocols, there is a 1-to-1 relationship between EFC5 values and the 2-byte hex codes.

Obviously, in both cases, there are more EFC values available than hex codes because of the "wrap around" effect.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

vickyg2003 · Posted: Mon Apr 26, 2010 7:57 am Post subject:

Wow, that shows how one little miss-step can lead me to go off with a wrong idea and run with it. I had seen one place in RM where the 5 digit efc was not different when the first byte of hex was changed. I had read a response from Rob where he had disagreed with a 5 digit EFC that was generated from the Lookup Table, but missed the part later in the post where he stated they were both yielded the same signal, and then read something in the XMP-1 descriptions about EFC's not being able to be calculated, and my own observation that Official 2-byte executors seemed to have the stationary data in byte1 instead of byte2, made me leap to the conclusion that 5 digit couldn't cover the whole range of 2 digit hex.

Rolling Eyes

Now after all that the place where found that the 5 digit efc's were not even the same! I had miss-read them. Rolling Eyes

Duh!
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

vickyg2003 · Posted: Sun Jan 16, 2011 9:48 pm Post subject:

Okay, I'm back on this again. I do believe there are EFC's and HEX that is not allowed by our tools.

I've been working on determining some 5 digit EFC's, Some will not work, so I tried entering the hex for the keymoves, but that's not allowed either, it automatically changes certain signals.

http://www.hifi-remote.com/forums/dload.php?action=file&file_id=9292

The Play in this file sends the correct signal if its in an upgrade, however if you put it on a keymove key, you get a different signal.

With a sony combo

The hex for this code is 59 E9 the

The 5 digit EFC is 65580

Play obc=026 Dev=151 EFC= 65580 hex=59 E9

If the upgrade uses this play function for a keymove it can't be done.

From the key board EFC 65580 does not yield the desired output.

As a keymove EFC 65580 does not yield the desired output.

Even if you try to enter the hex directly, as soon as you enter $59, $E9, IR changes the hex to $00 $2C and the EFC becomes 00044 which is the equivalent of 65580.

My Bravia upgrade using the sony combo has several codes that don't work.

So are we sure there are not some HEX that we dont want to use because of EFC considerations?
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

mr_d_p_gumby · Posted: Mon Jan 17, 2011 9:18 pm Post subject:

Some of the early JP1.x remotes did not implement 2-byte keymoves properly, and only use the first hex byte. I think the remote you're using falls into this category.

The general rule we established for entry of EFCs is that if the number (not the number of digits) entered is < 1000, it is taken as a 3-digit EFC that will produce only 1 hex byte. Numbers 1000 or more generate 2 hex bytes. When calculating the EFC from 2 hex bytes, if the result is less than 1000, then we add 65536 to the result.

For the remote you are using, the RDF tells IR & RM that the remote cannot use a 2-byte keymove, so it truncates it to a 1-byte value. The only way around this is to use the other type of keymove (button #), with a helper upgrade to implement the 2-byte hex value.
_________________
Mike England

JP1 Group at Yahoo!, JP1 Files Area

3FG · Expert Joined: 19 May 2009 Posts: 3367

The remotes in question are the Comcast 1067A and URC-9960. Both accept 5 digit EFCs and store them as 2 bytes of EFC.
From Version 4 of the RDF spec (written by mr_d_p_gumby):
This is the second modification of the keymove format, and is rarely encountered. It is basically an expansion of the first modification to allow for use of 5-digit EFC numbers. Processing of keymoves is exactly the same as discussed above, with the exception that keymoves with two command bytes may contain a 5-digit EFC (in hex) when the first byte is not zero. In this case, the remote pre-processes both bytes before loading them into the protocol buffer by calling a routine to do EFC-to-HEX conversion.

Taking this at face value, then only EFCs ranging from 00000 to 00255 (or 65536 to 65791) will be treated as one byte, and manual entry of EFCs outside those two ranges should work as two byte EFCs.
Using IR and/or RM, the ranges from 00000 to 00999 and 65536 to 65791 would be unavailable.

BTW, for the Sony 12/15/20 Combo executor, EFCs 00000 to 00255 are all OBC 26, for all 255 possible devices.

vickyg2003 · Posted: Tue Jan 18, 2011 1:46 pm Post subject:

Now I understand why Greg and Graham had so much trouble getting my keymoves to work on 5 digit EFC remotes.... That was all lost on me.

I didn't realize that there were different formats. Now its all making sense.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.