JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

METechs Drapery Control
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - Protocol Decodes
View previous topic :: View next topic  
Author Message
3FG
Expert


Joined: 19 May 2009
Posts: 3206

PostPosted: Sat Aug 13, 2011 11:00 pm    Post subject: Reply with quote

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
View user's profile Send private message
kkl



Joined: 10 Aug 2011
Posts: 45

PostPosted: Sat Aug 13, 2011 11:34 pm    Post subject: Reply with quote

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
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3206

PostPosted: Sun Aug 14, 2011 12:01 am    Post subject: Reply with quote

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
View user's profile Send private message
mr_d_p_gumby
Expert


Joined: 03 Aug 2003
Posts: 1370
Location: Newbury Park, CA

PostPosted: Sun Aug 14, 2011 12:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6560
Location: Florida

PostPosted: Sun Aug 14, 2011 1:30 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3206

PostPosted: Sun Aug 14, 2011 1:43 pm    Post subject: Reply with quote

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
View user's profile Send private message
kkl



Joined: 10 Aug 2011
Posts: 45

PostPosted: Sun Aug 14, 2011 2:18 pm    Post subject: Reply with quote

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
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6560
Location: Florida

PostPosted: Sun Aug 14, 2011 2:27 pm    Post subject: Reply with quote

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. Wink

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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3206

PostPosted: Sun Aug 14, 2011 3:34 pm    Post subject: Reply with quote

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
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6560
Location: Florida

PostPosted: Sun Aug 14, 2011 4:14 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
kkl



Joined: 10 Aug 2011
Posts: 45

PostPosted: Sun Aug 14, 2011 5:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
3FG
Expert


Joined: 19 May 2009
Posts: 3206

PostPosted: Sun Aug 14, 2011 6:17 pm    Post subject: Reply with quote

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
View user's profile Send private message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6560
Location: Florida

PostPosted: Sun Aug 14, 2011 6:22 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 6560
Location: Florida

PostPosted: Sun Aug 14, 2011 9:25 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
3FG
Expert


Joined: 19 May 2009
Posts: 3206

PostPosted: Sun Aug 14, 2011 9:35 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - Protocol Decodes All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 2 of 7

 
Jump to:  
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
Get Smart! the band's official homepage Rockabilly Central