 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
 Posted: Mon Dec 13, 2010 5:38 pm Post subject: |
 |
|
Rob, I don't see what you are seeing. I had looked at the learns Chris posted before I left, and I'm seeing a toggle bit thqat changes with each press of a button, just like I expected. It has that same PITA toggle bit that the RC5 protocol had.
_________________
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 |
|
 |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Mon Dec 13, 2010 7:48 pm Post subject: |
|
|
OK, I re-downloaded the IR file to take a look. I was looking for a toggle that changes with a button-down and a button-up, which wasn't there.
I see the normal toggle, but it's present in both the OEM signals and the upgrade signals, so it didn't appear to be an issue. I see that it didn't toggle for the last learn of the upgrade signal, but I assumed that was caused by a non-learned button press in between.
| Code: | OEM learns (freq=35555)
Left +2700 -900 1110 -900 +900 10000000 00001111 0 0000100 00100000 -70200
Down +2700 -900 1110 -900 +900 10000000 00001111 1 0000100 00011111 -70200
Right +2700 -900 1110 -900 +900 10000000 00001111 0 0000100 00100001 -70200
Up +2700 -900 1110 -900 +900 10000000 00001111 1 0000100 00011110 -70200
JP1 learns (freq=36036)
Up +2700 -900 1110 -900 +900 10000000 00001111 1 0000100 00011110 -70200
Left +2700 -900 1110 -900 +900 10000000 00001111 0 0000100 00100000 -70200
Down +2700 -900 1110 -900 +900 10000000 00001111 1 0000100 00011111 -70200
Right +2700 -900 1110 -900 +900 10000000 00001111 1 0000100 00100001 -70200 |
_________________
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 1:17 pm; edited 2 times in total |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Mon Dec 13, 2010 8:19 pm Post subject: |
|
|
| The Robman wrote: | OK, I re-downloaded the IR file to take a look. I was looking for a toggle that changes with a button-down and a button-up, which wasn't there.
I see the normal toggle, but it's present in both the OEM signals and the upgrade signals, so it didn't appear to be an issue. I see that it didn't toggle for the last learn of the upgrade signal, but I assumed that was caused by a non-learned button press in between.
|
And that's where I was going with this. When the remote and the equipment get out of synch, the equipment doesn't react. I learned this long before you taught me about protocols. I had an RC5 learn, and the learned button would sometimes work, but they would NEVER work two times in a row. because the toggle was in the wrong state, so the equipment would not listen. So sometimes my learns would work, but most of the time they wouldn't. Hence I HAD to learn about upgrades and keymoves. But even with upgrades, the equipment often required two presses of a button, to get the button and the equipment on the same page. Then things would work as expected, and subsequent keypresses worked correctly. I found RC5 equipment couldn't be macroized, since half the time the toggle bit would be in the wrong state so the macros would skip a step, more often then it would execute all the steps. You probably noticed that I don't ever like to "give up", but I did let the RC5 protocol defeat me. I got rid of most of my rc5 equipment, and have made it rc5 a deal-breaker when it comes to new equipment purchases.
_________________
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 |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Mon Dec 13, 2010 9:41 pm Post subject: |
|
|
Just because a device uses the RC5 protocol doesn't mean that the device requires the toggle to be set correctly, sometimes the devices are more "forgiving" than the RC5 protocol requires.
Anyway, back to the issue at hand, Chris wasn't using learned signals, he was using an upgrade, which means the toggle would work. Sure, it could get out of sync once in a while, but no more so than the OEM remote, which apparently always worked.
_________________
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: Mon Dec 13, 2010 10:20 pm Post subject: |
|
|
| The Robman wrote: | Just because a device uses the RC5 protocol doesn't mean that the device requires the toggle to be set correctly, sometimes the devices are more "forgiving" than the RC5 protocol requires.
Anyway, back to the issue at hand, Chris wasn't using learned signals, he was using an upgrade, which means the toggle would work. Sure, it could get out of sync once in a while, but no more so than the OEM remote, which apparently always worked. |
Well yes, not all equipment requires the toggle bit to be set correctly, but if it does, then this problem becomes an issue. Its a bigger issue with the universal remote than with the OEM remote. The OEM remote has a dedicated toggle register, while the universal is sharing the toggle register. Perhaps a picture will do better than my verbal description. Here is a capture from a universal remote using a toggling protocol, but since its a universal remote it loses track as it does its universal thing. When I sent the NEC signal, the toggle lost state.
If the equipment requires toggles to be in the correct state, then it will ignore the signal set in line 4.
With the comments that I read about the "state machine" kind of made me think that they were enforcing state in the release that's giving Chris the problems, but again they may have been talking about something completely different. It's too technical for me.
_________________
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: Mon Dec 13, 2010 11:14 pm Post subject: |
|
|
| vickyg2003 wrote: | | The Robman wrote: | OK, I re-downloaded the IR file to take a look. I was looking for a toggle that changes with a button-down and a button-up, which wasn't there.
I see the normal toggle, but it's present in both the OEM signals and the upgrade signals, so it didn't appear to be an issue. I see that it didn't toggle for the last learn of the upgrade signal, but I assumed that was caused by a non-learned button press in between.
|
And that's where I was going with this. When the remote and the equipment get out of synch, the equipment doesn't react. I learned this long before you taught me about protocols. I had an RC5 learn, and the learned button would sometimes work, but they would NEVER work two times in a row. because the toggle was in the wrong state, so the equipment would not listen. So sometimes my learns would work, but most of the time they wouldn't. Hence I HAD to learn about upgrades and keymoves. But even with upgrades, the equipment often required two presses of a button, to get the button and the equipment on the same page. Then things would work as expected, and subsequent keypresses worked correctly. I found RC5 equipment couldn't be macroized, since half the time the toggle bit would be in the wrong state so the macros would skip a step, more often then it would execute all the steps. You probably noticed that I don't ever like to "give up", but I did let the RC5 protocol defeat me. I got rid of most of my rc5 equipment, and have made it rc5 a deal-breaker when it comes to new equipment purchases. |
When I first ran into RC5 some years ago, I hated it much as you do, but eventually I came to realize that RC5 or RC6 toggle isn't always as bad I first thought. I have a macro that my 8910 runs to turn on closed caption on my Magnavox TV. It works perfectly. I know that this TV requires toggle on almost every key and the macro does left, left, left, down, down, etc sequence. The 8910 properly toggles the toggle bit for each step of the macro. The toggle state should be much easier to deal with in a macro, than for general button pushes, since a macro executes fairly quickly and unless one of a repeated cmd gets lost, the remote should send out the proper toggle state on each step and the device responds as it should, assuming that none of the cmds is a learned key. For non-macro use, I think the secret to dealing with toggle is that most devices keep track of toggle on a last key basis. So, you can always cancel the device's expectation, by sending a different key first. Doing that, you can even make learned RC5 or RC6 work.
A common problem is the power key. You turn the TV off by sending pwr key with T=0 and the TV is now expecting pwr with T=1 for the next time. If the remote gets an errant pwr key press with T=1, that the TV doesn't see, the TV will not respond to the next press after that of the pwr key, since it's expecting T=1 and the remote will send T=0, but you can cancel that expectation, by sending any other key first. So, just send the 0 key followed by pwr and the TV will always respond to the pwr key, since the 0 cancels the expectation of the toggle bit being in a particular state for the pwr key.
In addition to the RC5 on my Magnavox TV, my kids also have an XBOX 360 that uses the MCE form of RC6 and it absolutely requires adherence to the toggle rules. I have a home automation controller that sends IR cmds to the 360 and that controller can only do learned IR. So, I can't do much of anything with it, unless I deal with the toggle problem as described above, by sending a dummy key to make the 360 forget the expected toggle state for a given key, before sending that key.
On a side note, for Windows Media Center PCs using MCE remotes, there is actually an option to turn off the toggle expectation so that the receiver will always accept either toggle state on every keypress. Some Philips engineer probably rolls over in his grave every time a Windows PC ignores the toggle bit state.
A.A. |
|
| Back to top |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3367
|
| Posted: Mon Dec 13, 2010 11:29 pm Post subject: |
|
|
There's a lot of equipment that uses RC-5 or variants with toggle bits. To me, it's obvious that most of it work fine with universal remotes. Yes, the RC-5 IR protocol call for the remote to flip the toggle bit with each distinct keypress, but I suppose that the receiver of the IR signal keeps track of the toggle not with a toggle bit of its own but rather with a machine having three Toggle States:
A) None Established
B) Zero
C) One
and also have a Last Command register.
If no IR signal is received for, say, 0.2 seconds, the state would be set to None Established. This means that the receiver would be in state A nearly all of the time. When it receives an IR signal, it would transition to state B or C depending on the value of the received toggle bit, and store the command in the Last Command register.
If it receives a subsequent IR signal (before 0.2 seconds have elapsed) which is different in any way (toggle bit or device/OBC) the Toggle state would be set to the value of the toggle bit in the new command, and the Last Command register updated.
Conversely If the the new signal is identical to the one in the Last Command register (including the toggle bit) then it would be treated as a repeat.
With this approach, it is nearly impossible for the equpment to be confused. The only issue in macros would be to make sure that the 0,2 seconds elapse before sending a re-iterated command. |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Tue Dec 14, 2010 7:28 am Post subject: |
|
|
| cauer wrote: |
For non-macro use, I think the secret to dealing with toggle is that most devices keep track of toggle on a last key basis. So, you can always cancel the device's expectation, by sending a different key first.
On a side note, for Windows Media Center PCs using MCE remotes, there is actually an option to turn off the toggle expectation so that the receiver will always accept either toggle state on every keypress. Some Philips engineer probably rolls over in his grave every time a Windows PC ignores the toggle bit state. |
Yes, you can usually get the equipment to work by simply pressing the key twice. Once you are in synch everything should run as expected. When I ran into the piece of equipment that absolutely couldn't be controlled I suspected that it used a different toggle for the arrow keys and power, than it did for the other keys.
Interesting about the Media Center. Its nice to know they will let you bypass the state checking.
| 3FG wrote: | | There's a lot of equipment that uses RC-5 or variants with toggle bits. To me, it's obvious that most of it work fine with universal remotes. |
Obviously you run in a different crowd than I do. I still go in to peopleys homes and they torture me by having a basket ful of universal remotes that each only control one piece of equipment. Given that level of sophistication, the pressing of a button 2x to get it to work has it "work fine", and then of course once its in the correct state it works flawlessly.
I like the None Established, Zero, One toggle state that you outlined below, but I can guarantee you that none of my toggling equipment followed that rule. Hence I won't buy equipment with toggling protocols any more. I want a high level of automation in my remotes, and toggling protocols just make that too difficult.
But thanks for the reminder, we're looking at TV's this afternoon, so I'm going to slide a learner in my purse to help me eliminate models!
Back to xnappo's case, he is having to press some keys 2x to get the thing to react. That would seem to indicate he's running into a toggling issue too. A second key press isn't all that awful, unless its a L o n g keypress, and Chris has already solved that issue.
_________________
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: Tue Dec 14, 2010 8:07 am Post subject: |
|
|
| vickyg2003 wrote: |
Back to xnappo's case, he is having to press some keys 2x to get the thing to react. That would seem to indicate he's running into a toggling issue too. A second key press isn't all that awful, unless its a L o n g keypress, and Chris has already solved that issue. |
Hi Vicky, actually I am not dealing with a LONG keypress - just any normal keypress. And pressing down twice when navigating my 100s or directories of MP3s or other general menus was totally annoying and unacceptable.
I think you are probably spot-on with your comments about the code being re-written to be state-machine based. I bet the older version of LIRC was like Media Center and ignored it, while the new code strictly follows the rules.
One thing I don't get though... You and others comments make it sound like the only time I should have to press the key twice is when I switch from one device to the other. However that is not the case - just sitting on the XBMC device, it missed 1/3-1/4 of the down presses (without my change to force it to ignore repeated headers anyway).
I think they have something screwed up in their state-machine when it comes to repeated signals and they are not saving the toggle bit from a debounced signal - instead only setting toggle from the first burst.
Would that make sense? Of course the OEM remote doesn't have this problem - perhaps there is something it sends on a debounce type press?
I am using the term 'debounced' here to mean a signal that was repeated, but in too short a time frame for it to really count as a long press.
xnappo
P.S. I emailed the developer from the gossamer site and asked if he could pop by. Otherwise this could be a long game of Suduko  |
|
| Back to top |
|
|
vickyg2003
Site Admin
Joined: 20 Mar 2004
Posts: 7073
Location: Florida
|
| Posted: Tue Dec 14, 2010 9:22 am Post subject: |
|
|
| xnappo wrote: | One thing I don't get though... You and others comments make it sound like the only time I should have to press the key twice is when I switch from one device to the other. However that is not the case - just sitting on the XBMC device, it missed 1/3-1/4 of the down presses (without my change to force it to ignore repeated headers anyway).
|
When only staying in one mode, with no punch through, the toggle bit should flip back and forth just like the OEM remote. So yes, I might be wrong here, since this problem isn't plaguing the OEM remote.
Too bad you don't have a Widget. A widget really makes it clear what's happening and why its doing it.
It could very well be that there isn't a final timeout on the signal, and the UEI remote is letting the presses be too close together. If you take a breath between key presses does this improve performance?
| Quote: |
P.S. I emailed the developer from the gossamer site and asked if he could pop by. Otherwise this could be a long game of Suduko |
I like sudoku,  but this is a good idea.
_________________
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 9:28 am Post subject: |
|
|
| 3FG wrote: | There's a lot of equipment that uses RC-5 or variants with toggle bits. To me, it's obvious that most of it work fine with universal remotes. Yes, the RC-5 IR protocol call for the remote to flip the toggle bit with each distinct keypress, but I suppose that the receiver of the IR signal keeps track of the toggle not with a toggle bit of its own but rather with a machine having three Toggle States:
A) None Established
B) Zero
C) One
and also have a Last Command register.
If no IR signal is received for, say, 0.2 seconds, the state would be set to None Established. This means that the receiver would be in state A nearly all of the time. When it receives an IR signal, it would transition to state B or C depending on the value of the received toggle bit, and store the command in the Last Command register.
If it receives a subsequent IR signal (before 0.2 seconds have elapsed) which is different in any way (toggle bit or device/OBC) the Toggle state would be set to the value of the toggle bit in the new command, and the Last Command register updated.
Conversely If the the new signal is identical to the one in the Last Command register (including the toggle bit) then it would be treated as a repeat.
With this approach, it is nearly impossible for the equpment to be confused. The only issue in macros would be to make sure that the 0,2 seconds elapse before sending a re-iterated command. |
In my experience with RC5 and RC6 protocol, there is no timeout. The device will remember the last toggle state forever. It can be pretty annoying when you press the power key to turn off your TV, it goes off, then sometime hours later the pwr key gets accidentally pressed again in a situation where the TV can't see the IR from the remote. At that point, the remote and the TV are out of sync with respect to the expected toggle state on the next pwr key press. So, the next day when you want to turn the TV on, you press pwr and the TV dutifully ignores it since the toggle state is wrong. Press pwr again and the remote switches to the toggle state the TV is expecting and the TV pwrs on. Sending a dummy key before pwr, will always cancel the expected toggle state for the pwr key, since the device only remembers toggle state for the last key. It should be obvious from that, that it doesn't even matter what toggle is sent for the dummy key.
If the RC5/6 designers were implementing a timeout, then there's no point in the whole toggle scheme in the first place. The problem that RC5 and RC6 are atempting to solve, is the elimination of accidental repeats. Suppose that you have a remote and device with a no-toggle protocol. You press the "1" key and the remote sends out 5 copies of the IR for the "1" key. Now, sometime during the reception of these 5 copies, the device misses one of the 5 "1"s. Since the device saw the "1"s stop and then start again, it thinks you've pressed the "1" key twice and you get "11". With RC5 or RC6, you can have a dropout in reception for a key that you're holding down, sending a continuous stream of "1"s and the device will see the same toggle bit over and over and realize that there is just one keypress involved and not multiple keypresses of the "1" key.
Other protocol designers have solved the repeat problem differently, sometimes through timeouts, with the assumption that if a significant period of time has elapsed during which no signal is received, they just assume that any new reception is a second keypress and not a momentary dropout in reception. That can and does work, but it probably needs some fine tuning to get it acceptable. It's easy to contrive a test to make it fail. Press and hold the "1" key down continuously and then place you hand in front of the IR emitter on the remote for 1 second and then remove your hand from in front of the emitter. If 1 second exceeds the timeout, then the device will think that you pressed the "1" key again and will think that you're trying punch in channel 11. If you make the timeout long enough to avoid those situations, then you may be ignoring legitimate double-presses of the "1" key. It's not perfect, but many protocols do use this technique.
Some forms of the NEC protocol use dittos to distinguish between long key presses with a momentary dropout and multiple key presses of the same key. I believe that some other protocols even go so far as to send one code for first keydown, a different code while it's held down and a third code on key release.
Getting back to the problem at hand here, I'd be surprised if the problem that you're seeing is due to RC5/6 toggle, as your remote handles the toggle state correctly. Successive presses of a key, cause the code to be sent with opposite toggle to the previous key press. So, there should not be any issue with the device ignoring key presses due to the wrong toggle being sent.
A.A. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Tue Dec 14, 2010 9:28 am Post subject: |
|
|
Obviously it's up to the OEM to decide how strictly to enforce the toggle rules, so it will vary by device, but I think the typical situation where someone posts about learned signals not working properly is only an issue for cases where the same button is pressed twice in a row. For example, selecting channel 2-2 wouldn't work, but selecting channel 2-3 would work, because when you press a different button the toggle is not enforced. I think the purpose of the toggle bit was to help the device tell the difference between a repeating button and repeated presses of the same button.
Vicky raises a good point that the toggle in a JP1 remote is shared, so pressing a button for an un-related device will toggle the toggle bit, but for devices that follow the rule that I just outlined, that wouldn't be a problem.
Chris, here's an experiment that you can do, 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. The idea here is to change the toggle setting in the OEM remote without the device knowing that you did it, to get them out of sync. First try this using the same button all the time (like MUTE-MUTE-[MUTE]-MUTE-MUTE), then try it again with different buttons.
My guess is that when you do it using the same button, the first press after the covered press won't work but the next one will. Then when you use different buttons, my expectation is that all uncovered presses will work. If that turns out to be true, it would confirm that you need a simple toggle which needs to alternate for subsequent presses of the same button but is not enforced for different buttons. If the 2nd test doesn't go as I expect, and the first uncovered press doesn't work but the next one does, this will confirm that the toggle needs to be set correctly even for different buttons, which is more problematic for a universal. To get this to work reliably would probably require setting aside a dedicated register in the remote's memory, in which case it would be better to fix it in the device's firmware, if that's an option.
It just occurred to me that there's a 3rd test that you can do, if the 1st test went as I expected. You could repeat the 1st test, only this time, after the covered button press, don't press any buttons for a couple of minutes and then press the same button again. This will confirm whether the toggle has a timeout feature, as Dave (3FG) suggested.
_________________
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 10:18 am Post subject: |
|
|
| The Robman wrote: | Obviously it's up to the OEM to decide how strictly to enforce the toggle rules, so it will vary by device, but I think the typical situation where someone posts about learned signals not working properly is only an issue for cases where the same button is pressed twice in a row. For example, selecting channel 2-2 wouldn't work, but selecting channel 2-3 would work, because when you press a different button the toggle is not enforced. I think the purpose of the toggle bit was to help the device tell the difference between a repeating button and repeated presses of the same button.
Vicky raises a good point that the toggle in a JP1 remote is shared, so pressing a button for an un-related device will toggle the toggle bit, but for devices that follow the rule that I just outlined, that wouldn't be a problem.
Chris, here's an experiment that you can do, 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. The idea here is to change the toggle setting in the OEM remote without the device knowing that you did it, to get them out of sync. First try this using the same button all the time (like MUTE-MUTE-[MUTE]-MUTE-MUTE), then try it again with different buttons.
My guess is that when you do it using the same button, the first press after the covered press won't work but the next one will. Then when you use different buttons, my expectation is that all uncovered presses will work. If that turns out to be true, it would confirm that you need a simple toggle which needs to alternate for subsequent presses of the same button but is not enforced for different buttons. If the 2nd test doesn't go as I expect, and the first uncovered press doesn't work but the next one does, this will confirm that the toggle needs to be set correctly even for different buttons, which is more problematic for a universal. To get this to work reliably would probably require setting aside a dedicated register in the remote's memory, in which case it would be better to fix it in the device's firmware, if that's an option.
It just occurred to me that there's a 3rd test that you can do, if the 1st test went as I expected. You could repeat the 1st test, only this time, after the covered button press, don't press any buttons for a couple of minutes and then press the same button again. This will confirm whether the toggle has a timeout feature, as Dave (3FG) suggested. |
I verified Vicky's claim that the remote changes toggle state for keys that belong to a different device. 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. Pip, play, pip, pip and the TV ignores the 2nd pip since the remote sent the same toggle for the 1st and 2nd pip codes. The play key in this case goes to a Panasonic DVR. The Panasonic DVR is not using RC5 or RC6. Pip, (cover remote) pip, wait 5 minutes, pip and the TV fails to detect the 2nd and 3rd pip. Of course, it's expected that it doesn't detect the 2nd pip keypress since I had covered the emitter on the remote for the 2nd pip keypress. Pip, (cover remote) pip, down arrow, pip and the TV responds to the 3rd pip, demonstrating that receiving any other key for the TV cancels the expected toggle state for the pip key.
A.A. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Tue Dec 14, 2010 10:57 am Post subject: |
|
|
| 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.
_________________
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 |
|
|
3FG
Expert
Joined: 19 May 2009
Posts: 3367
|
| Posted: Tue Dec 14, 2010 12:00 pm Post subject: |
|
|
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. |
|
| 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
