Ideas for Button action with same EFC/OBC

[binky123]

Ahh, I didn't realize we were dealing with an extender. You could probably modify the extender to recognize the Learned Data type but it might not be worth it to implement it.

[The Robman]

As for the learned signals you posted, in order for them to be useful to me, I would need to either see the raw timing data or the original IR file itself.

FYI: The data posted is the raw timing data from double-clicking on the Learned entry or clicking the Edit button. You can cut-n-paste and assign it to a button within IR7.

Of course, I had forgotten that you had added that feature, thanks for the reminder.

[Nils_Ekberg]

Well, the learned signals do not work as I expected anyway. I ended up with one learn for forward and reverse that will do both the long and short press version of the OBC as the original did. But the other will only simulate the short press and do nothing on the long press. Just the opposite of what I needed.

What I need to end up with is the original OBC for short press and one OBC that only does the equivalent of the long press and I can't find anything in 005A that makes that happen when it senses a long press.

[The Robman]

OK, I've think of got something that should work for you. Use the protocol code below then edit the device upgrade and check the "protocol >FF" box.

All the normal buttons should still continue to function as they do today. In order to make a button hold and repeat even with a short press, add 128 to the OBC. In order to make it not repeat, add 192 to the OBC. (This will work for all the buttons except the numeric buttons 1 thru 7).

So, here are your new OBCs...
155 rewind
147 fast fwd

219 skip-
211 skip+

and here's the protocol code...

Upgrade protocol 0 = 01 5A (S3C8+) NEC2 hacked (PB v4.00)
43 8B 31 8B 12 CF 45 08 08 01 18 01 06 01 18 03
39 D2 DC 08 CA 08 B6 20 01 08 06 37 01 0E 46 06
03 37 03 05 B6 29 01 8B 03 E6 0D 10 E4 06 07 60
07 20 11 8D 01 49
End

The red byte above controls the minimum number of repeats needed for the FFWD and REW buttons. Right now it's set way to high at 16 (hex 10), so you should try reducing that to see what the lowest value that works is, otherwise your macros will run extra long.

Here's the PB file, for anyone that's interested...
http://www.hifi-remote.com/forums/dload ... le_id=4337

[Nils_Ekberg]

Rob you da man...

Works great. Thanks, this solved a problem that has been nagging me for awhile. Now looking at the PB file I see what you did.

Thanks again

[The Robman]

Let me know what value you end up with for the number of repeats.

[Nils_Ekberg]

Let me know what value you end up with for the number of repeats.

It looks like 9 (hex 9 also) is the minimum you can go consistently. When I drop to 8 it executes the next/previous track most of the time. So, it looks like the device is looking for at least 8 repeats but 9 makes it consistent.

By the way, it executes the FF and rewind in about the same time as the OEM remote when holding the button.

[The Robman]

Is 0x09 100% reliable, or would 0x0A be safer?

[Nils_Ekberg]

Is 0x09 100% reliable, or would 0x0A be safer?

0x09 is perfectly reliable and has not failed yet.

[clinkme]

Hello Rob!
Is your new hacked protocol compatible with Kameleon URC-8040?
Thanks in advance,
Il

[The Robman]

Sure, it will work with any S3C8 remote.

[clinkme]

Rob, thank you very much,

unfortunatelly, after my additional investigation I know that my original remote uses NEC1 protocol (seperate short code when button is held down).
So, is it possible to re-use your hack for NEC1 protocol, and if yes, can you show the right way?

Thanks again,
Il