 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
cauer29
Joined: 03 Feb 2010
Posts: 236
|
 Posted: Tue Dec 14, 2010 2:06 pm Post subject: |
 |
|
| 3FG wrote: | cauer29,
I can't resist poking back at you. I think you said is that if a timeout scheme is implemented using 0.2 seconds, there is no point to a toggling protocol at all. On the other hand, if you do some fine tuning, and make the delay 1 second, that's completely different, and will work, although not perfectly. 
The RC-5 IR protocol is fine. It just defines the signals that the remote sends. The designer of the receiving equipment can choose to ignore the toggle, or enforce a rigid rule (as you and Vicky have described), or take an intermediate course which requires a litttle more effort to implement. If the latter is done using a timeout scheme, the designer should choose a value which is appropriate to the intended use of the equipment. Moveable curtains probably would use a longer timeout than a AV receiver.
I think (but don't know for sure) that Marantz uses a timeout. |
I'm not following your reasoning. If you use a 0.2 second timeout, then what good does a toggle protocol do? The timeout already takes care of distinguishing between long key press with dropout Vs. multiple keypress. So, what does a toggle bit add to the equation? Neither the timeout method, nor the toggle bit method are robust. I suppose that a combination of the 2 could work better than either separately. Still, in comparison to the NEC ditto scheme, toggle or timeout seem pretty weak.
I'm guessing that when Philips first came up with the RCx protocol with the toggle bit, they weren't expecting a variable implementation. The duct tape and bailing wire came later, when it became clear that the toggle bit solution caused more problems than it fixed. I've had many different pieces of equipment over the years that used RC5 or RC6 protocol and none of them used a timeout along with toggle. I have seen some variation as to which keys a device requires toggle. Some allow any toggle state for number keys, but enforce toggle for pwr key.
A.A. |
|
| Back to top |
|
 |
3FG
Expert
Joined: 19 May 2009
Posts: 3367
|
| Posted: Tue Dec 14, 2010 4:01 pm Post subject: |
|
|
I agree with you that the NEC1 approach is good. (I haven't yet seen the inner beauty of NEC2.)
Dropouts don't figure into my thinking at all. I'm not aware of any IR protocol which is even moderately robust to dropouts--the usual result is a corrupted signal, rather than a nicely excised frame.
The RC-5 toggle is a way to recognize repeats. RC-5 receivers need a timeout to recognize repeats well. Receivers of protocols which send a complete signal for repeats can tell if the signal is intended to be a new instance of the same signal if there is a delay between the repeats. But that approach requires the signal generator (the remote, usually) to provide a delay, and is in principle slower. The toggle allows a new instance to be sent immediately. |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Tue Dec 14, 2010 5:23 pm Post subject: |
|
|
This has been a good exchange on the merrits of toggles. I learned about this from Jon Armstrong, and he's been gone (RIP) for 6 years now, so its about time we had a strong toggling discussion again.
Xnappo,does your Atlas remote work, reliably, if you say 1000 between key presses?
_________________
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 |
|
|
cauer29
Joined: 03 Feb 2010
Posts: 236
|
| Posted: Tue Dec 14, 2010 11:02 pm Post subject: |
|
|
| The Robman wrote: | | cauer29 wrote: | | I verified Vicky's claim that the remote changes toggle state for keys that belong to a different device. |
Thanks for verifying but it really wasn't necessary because we knew that to be the case as we've seen the code that generates the toggle bit. It just grabs the LSB from a button press counter.
| cauer29 wrote: | | On this TV, pressing pip, pip, pip always cycles through various pip screens. Pip, (cover remote) pip, pip fails to detect the 2nd and 3rd pip key presses. That shows that the TV is enforcing toggle for this key. |
Could you try another experiment, try pressing 1-2-3 and cover the 2. If your TV allows the toggle to be reset whenever a different button is pressed, you should tune to channel 13. |
1, (cover remote) 2, 3 results in switching to channel 13, though you have to get the timing just right since the TV is picky about pauses betwen button pushes when entering channel numbers. Without a bit of practice, the TV would give up a short time after the 1, while I was covering the remote and pressing the 2. I was able to get the 1, cover 2, 3 out fast enough and it always went to channel 13.
A.A. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
| Posted: Tue Dec 14, 2010 11:10 pm Post subject: |
|
|
Cool, so that confirms that your TV only enforces the toggle when the same button is pressed repeatedly and doesn't enforce it when different buttons are pressed.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
cauer29
Joined: 03 Feb 2010
Posts: 236
|
| Posted: Tue Dec 14, 2010 11:21 pm Post subject: |
|
|
| 3FG wrote: | I agree with you that the NEC1 approach is good. (I haven't yet seen the inner beauty of NEC2.)
Dropouts don't figure into my thinking at all. I'm not aware of any IR protocol which is even moderately robust to dropouts--the usual result is a corrupted signal, rather than a nicely excised frame.
The RC-5 toggle is a way to recognize repeats. RC-5 receivers need a timeout to recognize repeats well. Receivers of protocols which send a complete signal for repeats can tell if the signal is intended to be a new instance of the same signal if there is a delay between the repeats. But that approach requires the signal generator (the remote, usually) to provide a delay, and is in principle slower. The toggle allows a new instance to be sent immediately. |
Dropouts might no figure into your thinking, but they were pivotal to the thinking of the Philips engineers that decided to use a toggle code for RCx protocols.
Technically, timeouts are not needed to recognize repeats in RC5. The toggle function already does that. The timeout only helps to deal with accidental unseen button presses or errant toggle code behavior by the remote; ie 1, play, 1. The remote technically should not change toggle state on the play button if it's not an RCx protocol, but as we know, the UEI remotes do change toggle state and this makes the second 1 ignored. That causes problems for macros, as you'd have to slow them down enough to exceed the timeout, else the 2nd 1, would not be recognized. Then again, not all RCx protocol devices even have a timeout. In fact, I've never run across one that does, though I believe you when you say that they do exist.
A.A. |
|
| Back to top |
|
|
cauer29
Joined: 03 Feb 2010
Posts: 236
|
| Posted: Tue Dec 14, 2010 11:26 pm Post subject: |
|
|
| The Robman wrote: | | Cool, so that confirms that your TV only enforces the toggle when the same button is pressed repeatedly and doesn't enforce it when different buttons are pressed. |
When you think about it, if the device receives a different key, then by definition, it doesn't have to bother checking the toggle code, since a different key can't be a repeat.
A.A. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
| Posted: Wed Dec 15, 2010 1:18 am Post subject: |
|
|
| cauer29 wrote: | | When you think about it, if the device receives a different key, then by definition, it doesn't have to bother checking the toggle code, since a different key can't be a repeat. |
Right, but someone mentioned earlier in this thread that their device did enforce the toggle even for different buttons, the example given being the power button.
[EDIT]Just went back and looked, it was you here.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Last edited by The Robman on Wed Dec 15, 2010 8:37 am; edited 1 time in total |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
| Posted: Wed Dec 15, 2010 1:20 am Post subject: |
|
|
| cauer29 wrote: | | That causes problems for macros, as you'd have to slow them down enough to exceed the timeout, else the 2nd 1, would not be recognized. |
Or, given that you know how the UEI toggle works, you could structure the macro in such a way that the toggle is set the way you want it.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Wed Dec 15, 2010 8:18 am Post subject: |
|
|
Test Results:
| Quote: |
use the OEM remote to control your device then cover the IR window with your hand and press a button once, then uncover the window and see if the next press of a button works.
|
Yes, this works 100% of the time with the OEM remote. Can't get the OEM remote to exhibit the problem
| Quote: |
then try it again with different buttons.
|
This works 100% of the time too.
| Quote: |
Xnappo,does your Atlas remote work, reliably, if you say 1000 between key presses?
|
I experimented with various delays. A 1-1000,2-1000,3-1000 works all the time. So whatever the problem is, the state machine in the receiver is timing out after a while.
| Quote: |
Instead of pressing down-down-down, press down-left-down (I just made this one up  )
|
No change. Down success rate is ~66%. Left success rate is 100%
Just a reminder of the help text from 'our' MCE protocol in case it is of any use:
| Code: |
The MCE toggle bit actively toggles when this protocol is used, so you do not need the Windows registry change that disables debounce (to work with learned signals in which the toggle bit isn't active). The RC6 toggle bit is a different bit than the MCE toggle bit. The RC6 toggle bit is always zero in MCE signals.
|
Holding right/down results in very slow, erratic repeats (almost like it is waiting for the timeout?) while left/up repeats smoothly. There is no difference at all with the OEM remote.
irw reports like this (you can see when it times out and resets the repeat count to 0):
| Code: |
000000037ff07be1 00 Up mceusb
000000037ff07be1 01 Up mceusb
000000037ff07be1 02 Up mceusb
000000037ff07be1 03 Up mceusb
000000037ff07be1 04 Up mceusb
000000037ff07be1 05 Up mceusb
000000037ff07be1 06 Up mceusb
000000037ff07be1 07 Up mceusb
000000037ff07be1 08 Up mceusb
000000037ff07be1 09 Up mceusb
000000037ff07be1 0a Up mceusb
000000037ff07be0 01 Down mceusb
000000037ff07be0 00 Down mceusb
000000037ff07be0 01 Down mceusb
000000037ff07be0 02 Down mceusb
000000037ff07be0 03 Down mceusb
000000037ff07be0 00 Down mceusb
000000037ff07be0 01 Down mceusb
000000037ff07be0 00 Down mceusb
|
Some more codes and what works/does not work:
| Code: |
Hex: Works:
00 Y
01 N (particularly bad)
02 Y
03 N
04 Y
05 N
06 Y
07 N
08 Y
09 N
1E Y
1F N
20 Y
21 N
|
Okay... So definitely a pattern now. Seems like signals that end in '1'? I checked every code and even always works, odd always fails.
I also tried this using 'our' version of the protocol instead of the Atlas version - and got the same result.
| Quote: |
Typically you can copy this out of the protocol upgrade window, (even if its invisible) and paste it into the decode window in PB. Then press the Decode button
|
I can't get this to work. I copied this from RM:
| Code: |
Upgrade protocol 0 = 01 2A (S3F80) MCE (RM v2.00)
40 9A 41 8B 0D 00 05 35 01 A8 00 DC 00 00 00 00
00 C3 76 03 02 6B 08 76 00 01 6B 03 B6 06 80 76
03 01 6B 0B 56 03 FE 76 00 01 6B 03 46 03 01 1C
12 F6 01 4C 38 03 F6 FF 7A F6 FF 55 B0 C6 87 36
04 F6 FF 7E 6E 37 64 F6 C6 F8 88 00 F6 01 58 F6
01 0A 7B DB AF 76 03 01 6B 0B F6 FF 70 F6 FF 70
F6 FF 75 8B 10 1C 1A F6 FF 75 F6 FF 75 F6 FF 70
1C 16 8D 01 4C 1C 1A 8D 01 4C 4C 04 8B 02 4C 08
37 3F 08 F6 FF 75 F6 FF 70 8B 06 F6 FF 70 F6 FF
75 90 C3 4A EB AF
End
|
But when I hit decode, it does not work.
xnappo
Last edited by xnappo on Wed Dec 15, 2010 10:41 am; edited 2 times in total |
|
| Back to top |
|
|
cauer29
Joined: 03 Feb 2010
Posts: 236
|
| Posted: Wed Dec 15, 2010 10:40 am Post subject: |
|
|
| The Robman wrote: | | cauer29 wrote: | | When you think about it, if the device receives a different key, then by definition, it doesn't have to bother checking the toggle code, since a different key can't be a repeat. |
Right, but someone mentioned earlier in this thread that their device did enforce the toggle even for different buttons, the example given being the power button.
[EDIT]Just went back and looked, it was you here. |
I must not have been clear in my original example.
My example with the pwr key was:
pwr (t=0)
pwr (t=1) with remote covered
pwr (t=0)
The 3rd pwr is ignored by the TV since no other keys had been received in the interim and the toggle bit for the 3rd pwr key was the same as for the first. And on this TV, it does not matter how much time elapses between button presses. Overnight delays between button presses still result in the TV not responding to the 3rd pwr key. The 2nd pwr key does not even have to be the pwr key. It can be any key, as long as the TV does not "see" it. The only function of that key in this sequence, is to get the remote to change toggle state.
If the sequence was:
pwr (t=0)
any key (t=1) with remote covered
any key (t=0) with remote covered
dummy key (t=1)
pwr (t=0)
Then the TV will respond since even though the 2nd pwr key has the same toggle bit as the 1st. The dummy key received by the TV, cancels the expected toggle state for the all keys except the dummy key itself. Given the behavior of UEI remotes, "any key" in the above sequence does not even have to be one that sends the RC5 protocol for this TV. The only function for the "any key"s in this sequence is to setup the toggle state for the uncovered keys that follow. You can see that if you change the sequence to:
pwr (t=0)
dummy key (t=1)
pwr (t=0)
Then any number of errant unseen keypresses on the remote can be inserted after the 1st pwr key but before the dummy key and the TV will respond to the 2nd pwr key. If the number of unseen keypresses is an odd number, then the toggle bit would always be different on the 2nd pwr key and if it was even number, the toggle bit would be the same, but it doesn't matter, as the dummy key cancels the TV from expecting a particular toggle state for all but the dummy key itself.
A.A. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21234
Location: Chicago, IL
|
| Posted: Wed Dec 15, 2010 11:12 am Post subject: |
|
|
I think I had in my mind that POWER-ON and POWER-OFF where discrete codes rather than the same button. Anyway, are you saying that the TV will register the DUMMY button even when it's off?
For example, would this work...
1) POWER (t=0) - this turns the TV off
2) DUMMY (t=1) - does nothing
3) POWER (t=0) - turns the TV back on
If this does work, you could add the DUMMY button before the POWER button in all of your macros, and it should work. Actually, we could modify the executor itself to always send the DUMMY command before all other commands, as a way of resetting the toggle. That is, assuming that we can find a good DUMMY code that does nothing but is recognized by the device.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Wed Dec 15, 2010 11:39 am Post subject: |
|
|
| xnappo wrote: | Some more codes and what works/does not work: | Code: | Hex: Works:
00 Y
01 N (particularly bad)
02 Y
03 N
04 Y
05 N
06 Y
07 N
08 Y
09 N
1E Y
1F N
20 Y
21 N
|
Okay... So definitely a pattern now. Seems like signals that end in '1'? I checked every code and even always works, odd always fails.
I also tried this using 'our' version of the protocol instead of the Atlas version - and got the same result. |
Cool, the MCE is phase encoded. This means that the off time and the on time switch places between 1 and zero. <-1,+1|+1-1> So when an odd number is sent the quiet time between signals is 444uS longer than it between even numbered codes and that's just enough longer, for your equipment to stop listening for a repeat.
I think that gap number you showed in your lirc stuff needs to be 300 shorter or longer. But I'm not quite sure since lirc is not my thing.
_________________
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 |
|
|
xnappo
Expert
Joined: 30 Dec 2003
Posts: 861
|
| Posted: Wed Dec 15, 2010 11:47 am Post subject: |
|
|
| vickyg2003 wrote: | Cool, the MCE is phase encoded. This means that the off time and the on time switch places between 1 and zero. <-1,_1,+1-1> So when an odd number is sent the quiet time between signals is 444uS longer than it between even numbered codes and that's just enough longer, for your equipment to stop listening for a repeat.
I think that gap number you showed in your lirc stuff needs to be 300 shorter or longer. But I'm not quite sure since lirc is not my thing. |
I have played *a lot* with the gap number and while it does make it behave 'different' I haven't found a number that works well.
Are you saying to try 104700/105300? I certainly have not tried those exact numbers, I have been changing it by the 1000s not the 100s.
Thanks,
xnappo |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Wed Dec 15, 2010 11:56 am Post subject: |
|
|
| Quote: | can't get this to work. I copied this from RM:
Code:
Upgrade protocol 0 = 01 2A (S3F80) MCE (RM v2.00)
40 9A 41 8B 0D 00 05 35 01 A8 00 DC 00 00 00 00
00 C3 76 03 02 6B 08 76 00 01 6B 03 B6 06 80 76
03 01 6B 0B 56 03 FE 76 00 01 6B 03 46 03 01 1C
12 F6 01 4C 38 03 F6 FF 7A F6 FF 55 B0 C6 87 36
04 F6 FF 7E 6E 37 64 F6 C6 F8 88 00 F6 01 58 F6
01 0A 7B DB AF 76 03 01 6B 0B F6 FF 70 F6 FF 70
F6 FF 75 8B 10 1C 1A F6 FF 75 F6 FF 75 F6 FF 70
1C 16 8D 01 4C 1C 1A 8D 01 4C 4C 04 8B 02 4C 08
37 3F 08 F6 FF 75 F6 FF 70 8B 06 F6 FF 70 F6 FF
75 90 C3 4A EB AF
End
But when I hit decode, it does not work. |
It works for me. What version of Excel? Do you have the VBA Analysis Toolpak options turned on? Mike has upgraded some of the tools not to need this, but others are still on the waiting list.
This should have an added a Decode Tab, and changed a few entries in the the main spreadsheet.
_________________
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 |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
