Reply to thread

Message

<blockquote data-quote="CyberSimian" data-source="post: 1182835" data-attributes="member: 141969">I will try that tomorrow. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />I had assumed that the Sony IR signals were RC6 (or some other signalling protocol that uses a toggle flag) because of the effect that they have on WMC or MP when transmitted by the One-for-All remote.&nbsp; That seemed to fit in with my hypothesis about toggle codes and debounce processing.This is really strange.&nbsp; My working hypothesis was that the One-for-All flipped its internal toggle flag only if it was sending a signal for a toggling protocol.&nbsp; But if the Sony protocol is not a toggling protocol, this result suggests that the One-for-All is flipping its internal toggle flag even when the destination device does not use a toggling protocol. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite9" alt=":eek:" title="Eek!&nbsp; &nbsp; :eek:" loading="lazy" data-shortname=":eek:" />I have just performed a quick test on my production system.&nbsp; It was the same test sequence as before except I inserted a second VOLUME_UP button-press following the first one.&nbsp; With this sequence, the second press of the GUIDE button now works correctly.&nbsp; This result is consistent with the One-for-All always flipping its internal toggle flag, regardless of the destination device.It is interesting that IRSS does not suffer from this problem, and is able to interpret the signals correctly.&nbsp; Is this because IRSS does not perform debounce processing?&nbsp; The One-for-All works correctly with WMC with debounce disabled, but that results in spurious effects from contact bounce (so is not a usable solution). <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown&nbsp; &nbsp; :(" loading="lazy" data-shortname=":(" />&nbsp; I will give IRSS more of a work-out tomorrow, to see if I notice any effects caused by contact bounce.-- from CyberSimian in the UK</blockquote>

[QUOTE="CyberSimian, post: 1182835, member: 141969"] I will try that tomorrow. :) I had assumed that the Sony IR signals were RC6 (or some other signalling protocol that uses a toggle flag) because of the effect that they have on WMC or MP when transmitted by the One-for-All remote. That seemed to fit in with my hypothesis about toggle codes and debounce processing. This is really strange. My working hypothesis was that the One-for-All flipped its internal toggle flag only if it was sending a signal for a toggling protocol. But if the Sony protocol is not a toggling protocol, this result suggests that the One-for-All is flipping its internal toggle flag [i]even when the destination device does not use a toggling protocol[/i]. :eek: I have just performed a quick test on my production system. It was the same test sequence as before [i]except[/i] I inserted a second VOLUME_UP button-press following the first one. With this sequence, the second press of the GUIDE button now works correctly. This result is consistent with the One-for-All [i]always[/i] flipping its internal toggle flag, regardless of the destination device. It is interesting that IRSS does not suffer from this problem, and is able to interpret the signals correctly. Is this because IRSS does not perform debounce processing? The One-for-All works correctly with WMC with debounce disabled, but that results in spurious effects from contact bounce (so is not a usable solution). :( I will give IRSS more of a work-out tomorrow, to see if I notice any effects caused by contact bounce. -- from CyberSimian in the UK [/QUOTE]

Verification