JP1 Remotes

I've looked at the F12 executor, and it sends signals in one of two ways.
1. It can send 2 identical signals and stop, even if the button is held down.
2. It can send 2 identical signals, wait about 80mS or so, and repeat until the button is let up.

Oddly, it decides which mode to use by looking at the 2 least significant bits of the OBC. If the the two bits are different (01 or 10), then it uses mode 1. If the the two bits are the same, then mode 2 is used. So
OBC 1,2,5,6,9,10,13,14..... will send a 2 signal burst and stop.
0,3,4,7,8,11,12.... will send 2 signals, pause, and continue until the button is let up.

I suppose that this arrangement is part of the F12 protocol, and it makes sense that motion control would benefit from not piling up commands faster than the motors can react.

But it seems that your system uses a variant in which at least 3 (maybe 4) signals are needed to get a reaction. You can try the following-- it just sends signals until you let up the button.

[F12 Modified]
PID=01 36
CmdTranslator=Translator(lsb)
CmdParms=OBC=0
DevParms=Device Code
DeviceTranslator=Translator(lsb)
FixedData=00
Code.S3C80=3C 91 11 8B 0D 05 04 08 02 76 00 BB 00 D3 02 66 42 81 F6 01 46 F6 01 0A 7B F8 AF

Edited to correct the executor

I was hopeful, but no luck. I was supposed to paste that code into the RM .ini file, right?

It behaves oddly. On my 15-2117, only every other button press works (i.e. LED lights on FF, doesn't light on FF, lights on FF, etc.). On my URC 8811, when I press a key, the LED lights, then a pause, then LED flashes twice. Don't know what that means.

.rmdu and .ir files posted at http://www.hifi-remote.com/forums/dload ... le_id=9830. Hopefully I just screwed up something.

I tested this before I posted it, but with a RCA RCRP05B, which is a much newer design. However, I think it should still work.

I think you should try making sure that every device has a valid setup code on the General tab of IR. At least some remotes won't function correctly if any of the setup codes are invalid.

3FG wrote:I've looked at the F12 executor, and it sends signals in one of two ways.
1. It can send 2 identical signals and stop, even if the button is held down.
2. It can send 2 identical signals, wait about 80mS or so, and repeat until the button is let up.

Oddly, it decides which mode to use by looking at the 2 least significant bits of the OBC. If the the two bits are different (01 or 10), then it uses mode 1. If the the two bits are the same, then mode 2 is used. So
OBC 1,2,5,6,9,10,13,14..... will send a 2 signal burst and stop.
0,3,4,7,8,11,12.... will send 2 signals, pause, and continue until the button is let up.

Yes, this behavior is actually part of the F12 protocol. DecodeIR confuses things a little by reporting this repeat mode as a subdevice. The data sheet for a Toshiba TC9148 IC details most of the technical info on F12.

3FG wrote:I tested this before I posted it, but with a RCA RCRP05B, which is a much newer design. However, I think it should still work.

I think you should try making sure that every device has a valid setup code on the General tab of IR. At least some remotes won't function correctly if any of the setup codes are invalid.

While its important that the user has valid device ids, the executor here falls into the data, since there is no RETURN after the loop. It will only work if the data it tries to execute are valid instructions and can go just anywhere it feels like.

I would have made it a custom protocol instead of making a protocols.ini adjustment. That way the upgrade can be opened by anybody, but that's probably because I'm afraid of protocols.ini.

kkl,
Vicky has pointed out the problem-- I forgot the return statement.
Use this instead:
Code.S3C80=3C 91 11 8B 0D 05 04 08 02 76 00 BB 00 D3 02 66 42 81 F6 01 46 F6 01 0A 7B F8 AF

Vicky,
I agree, it would be better to not use protocols.ini. However, I don't know how.

Still no go. The revised protocol did stop the funny LED flashing.

I think I see what the problem is though. In the "...8811-Learned.ir" file, I captured the original remote on AUX and the new protocol on DVD. The new protocol is producing codes with a sub-device of 0 rather than 1 (for those keys).

Files: http://www.hifi-remote.com/forums/dload ... le_id=9833

3FG wrote:kkl,
Vicky,
I agree, it would be better to not use protocols.ini. However, I don't know how.

I guess it all goes down to what's familar.

I was wiki-ing all day yesterday, and my next project is to write up how to add a custom protocol to a rdmu. I asked Graham how stable the current RM was, so I don't write up an obsolete process, and he said to hold off until Alpha 10 to do my screen prints.

Its a really quirky process. You have to touch a certain controls before things light up, and then its kind of a back and forth way of tacking it on. Not hard, its just quirky. Once its in RM, there are definite advantages. When I write a custom protocol lots of times its much easier to work with the HEX instead of OBCs and EFCs.

Of course there is always the back handed method, where you stick it into KM, and then open the text in RM. Its easier to paste it into KM since all the steps are on one page. You don't have to keep switching TABs.

kkl,
Yes, I threw out the parity calculation while I was removing the repeats.
Try this one:
Code.S3C80=3C 91 11 8B 0D 05 04 08 02 76 00 BB 00 D3 02 66 42 81 56 03 EF 08 04 10 C0 B4 04 C0 5B 03 46 03 10 F6 01 46 F6 01 0A 7B F8 8D 01 46

I took a look and even though all the experts say that subdevice doesn't matter, there is a bump missing on the picture.

It seems to me that most of these were 0.1 codes but I can't find the zip file that shows the complete set of learns.

So bottom line, the upgrade as is will not work until I write something to do both the 0.0 and the 0.1.


The .1 might be the parity calculation, I didn't have time to check, but I need that IR file with the complete set of learns to check my work.

Unfortunately, the revised code doesn't appear to work either.

Here's the file with all of the original remote buttons learned: http://www.hifi-remote.com/forums/dload ... le_id=9809

The Rew (><) button might not be a clean learn. Let me know if I need to re-learn it. Thanks very much.

kkl,
Would you mind checking the Output tab of RM just before you copy to IR? The protocol section should look like:
The exact name of the executor or RM don't matter. (44 bytes) My tests show that gives exactly your learned signals, including the "subdevice", and repeats until the button is released.

Here is an RDMU for you to try too.

This sends the 0.0 and 0.1 F12 signals with a minimum of 4 repeats.

If this doesn't work, I'll work to divide it into 2 close frames followed by a bigger gap and then 2 close frames again.

Well I see that I forgot to add the link to the RDMU file, but that's probably for the best. I realize that I had jumped in and never actually tested the F12 protocol. When I did, that protocol sent the proper signal with the 0.1 and all. When I compared these to the learn, I found that the signals were pretty close. However, there is a 1000u timing issue in the time between the frames. I wonder if that might be the reason the kkl's first protocol didn't work. The repeating keys, << >> and stop should have worked unless the timing was a little to far out of whack.

Vicky,
The F12 executor does compute the "subdevice" and also inserts a delay between pairs of signals. That's what the datasheet which Mike linked to calls for--about 80mS between signal pairs.

The executor that I posted (I hope the third time is the charm...) is intended to send signals with no delay (other than the normal leadout) between them.

I'm reading the datasheet and it is apparent that this protocol isn't much like normal IR signals.