JP1 Remotes

The difference between those learns is the TV version sends the signal twice, and the CBL sends it 4 times. I wonder why the number of repeats is different? Did you hold the button for a shorter time? You can check if the remote is repeating or just sending short bursts by looking at the output with a cell phone or other digital camera. I have a RS 15-135 that sends some F12 signals repeatedly and others just once.

Edited: This following is not useful, because 0181 sends on device number 5 and not 0!
The 2116 has a setup code Audio (Tuner) 0181 which offers all of the OBCs that you've learned. I think it would be a good idea to try it just to see where the problem is.

I think 0181 send the following OBCs:
Stop 5
Play/Pause 9
#1 17
#2 33
#3 65
#4 129
#5 6
Ch+ 8
FFWD 16
Ch- 4

I almost certainly held each button for a different length of time because I wanted to get at least some captures that worked.

Can the number of repeats be built into the device upgrade?

I can capture with a URC 8811. Would that make a difference?

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.