|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
3FG Expert
Joined: 19 May 2009 Posts: 3376
|
Posted: Sat Aug 13, 2011 11:00 pm Post subject: |
|
|
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
Last edited by 3FG on Sun Aug 14, 2011 1:39 pm; edited 1 time in total |
|
Back to top |
|
|
kkl
Joined: 10 Aug 2011 Posts: 65
|
Posted: Sat Aug 13, 2011 11:34 pm Post subject: |
|
|
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.php?action=file&file_id=9830. Hopefully I just screwed up something. |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3376
|
Posted: Sun Aug 14, 2011 12:01 am Post subject: |
|
|
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. |
|
Back to top |
|
|
mr_d_p_gumby Expert
Joined: 03 Aug 2003 Posts: 1370 Location: Newbury Park, CA |
Posted: Sun Aug 14, 2011 12:16 pm Post subject: |
|
|
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. _________________ Mike England |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7082 Location: Florida |
Posted: Sun Aug 14, 2011 1:30 pm Post subject: |
|
|
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. _________________ 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.
|
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3376
|
Posted: Sun Aug 14, 2011 1:43 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
kkl
Joined: 10 Aug 2011 Posts: 65
|
Posted: Sun Aug 14, 2011 2:18 pm Post subject: |
|
|
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.php?action=file&file_id=9833 |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7082 Location: Florida |
Posted: Sun Aug 14, 2011 2:27 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3376
|
Posted: Sun Aug 14, 2011 3:34 pm Post subject: |
|
|
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 |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7082 Location: Florida |
Posted: Sun Aug 14, 2011 4:14 pm Post subject: |
|
|
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. _________________ 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.
|
|
Back to top |
|
|
kkl
Joined: 10 Aug 2011 Posts: 65
|
Posted: Sun Aug 14, 2011 5:04 pm Post subject: |
|
|
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.php?action=file&file_id=9809
The Rew (><) button might not be a clean learn. Let me know if I need to re-learn it. Thanks very much. |
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3376
|
Posted: Sun Aug 14, 2011 6:17 pm Post subject: |
|
|
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)
Code: | Upgrade protocol 0 = 01 36 (S3F80) F12 Modified (RM v2.02 Alpha 6)
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
End |
My tests show that gives exactly your learned signals, including the "subdevice", and repeats until the button is released. |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7082 Location: Florida |
Posted: Sun Aug 14, 2011 6:22 pm Post subject: |
|
|
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. _________________ 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.
|
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7082 Location: Florida |
Posted: Sun Aug 14, 2011 9:25 pm Post subject: |
|
|
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. _________________ 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.
|
|
Back to top |
|
|
3FG Expert
Joined: 19 May 2009 Posts: 3376
|
Posted: Sun Aug 14, 2011 9:35 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|