JP1 Remotes

[jimdunn]

So...

What happened here in the end?

Or are you still trying to work it out, and need more help (or better help than we could give) ?

[vickyg2003]

Hmm, I think maybe I dropped the ball on this one. 3FG asked me to do some tests, and I reported back with what the data was showing in the keymove tab and what he wanted was in the RAW Data tab!

[3FG]

Probably Jim was asking sassafras if his problem was resolved, but I'm interested in the EFC question.

What do you mean by EFCs over 65536 "won't work"? I think your example shows that 65536 + 256 ends up being stored as a 2 byte EFC (01 00 in hex). If you enter manually 00256, doesn't the raw data look the same as if you entered 65792? Or as another example do 01981 and 67517 yield the same raw data if entered manually?

If so, then the remote is treating manual entry of EFCs like other 5 digit remotes--it takes the entered number mod 65536. The difference is most remotes convert the resulting modded EFC to a Hex data value before storing it, but the 1067A stores it as an EFC.

[vickyg2003]

Well, I consider working to be if the output is the same.

My one experience with these EFC's over 65536 on a Sony Combo protocol meant that the OBC was not the correct output.

I haven't followed through because I didn't see what output we are looking for here. I don't know what the device/OBC combo we are looking forl

I did enter 65792 in both versions of the comcast both, say the EFC is 256.

Comcast 1067B ,Aux 1360/
the hex cmd says $79 $C5, and the output is totally garbage GAP signals that alternate.

Comcast 1067A, Aux 1360/ the hex column says $46 $00 the output is .
Dennon 29 OBC 0, Dennon{2} 29, OBC 0

I had assumed that $46 $00 is not going to send out the same data as $79 $C5 and that is proving to be true. I just don't know what the output is supposed to be for this example.
_________________
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.

[3FG]

OK, gives the desired IR output is a very reasonable definition.

If you're willing to experiment a bit, let's use Audio 1758 (31758 in the 1067B). Audio 1360 has unused bits, and so some EFCs aren't valid inputs to the executor.
I did the following. I manually programmed EFcs into the 1067B and then learned the resulting signals into a 15-135. Then used RMIR to tell me the actual signal that the Comcast shot. Listed is EFC, whcih Sony protocol, device or subdevice device if Sony20, OBC, and HEx data for reference, If you want to use RM to see the EFCs under 1000, it is necessary to enter the hex data--that's a bug in RM.

[vickyg2003]

When stored in the Comcast 1067A the results were different.

[3FG]

Maybe the 1067A mods an EFC like 65792 with 65536, and if the result is less than 1000, it considers it to be a 1 byte EFC, and if further mods the resutling EFC with 256. That would mean that 65792 ends up being stored as 00 00. But 66816 converts to 01280 (> 999) and so it works?

If you get bored, you could try EFC 00999/66535 (Sony15 68 / 28) and 01000/66536 (Sony15 180 / 28) to see if that is the boundary between not working and working.

I still suppose that if you arrange to store 01 00 as the EFC in Raw Data, it will shoot Sony15 163 -- 30. Or conversely if 65792 is manually entered, I suppose that the raw data will show 00 00.

I guess that folks who don't have a cable and are trying to manually program a 1067A probably should ask Comcast to exchange it for a 1067B.

[vickyg2003]

[3FG]

So if I understand this all correctly, for the 1067A and manual entry of EFCs:

EFCs in the range 00000 to 00999 will be stored as (input EFC mod 256).
EFCs in the range 65536 to 65635 will be stored as ((input EFC mod 65536) mod 256). The resulting assignment will be treated as a one byte EFC.

Manually entered EFCs in the range 01000 to 65535 and 65636 to (89999?) are treated as two byte EFCs.

Finally, maybe it is possible to assign keymoves by IR/RMIR in the range 00256 to 00999, and have these respond as two byte EFCs,

[vickyg2003]

[3FG]

[vickyg2003]

[3FG]

[vickyg2003]

[vickyg2003]