Adjust timings for RCO-14-b / fht 7901 about rc-switch HOT 10 CLOSED

I was just having the same issue with my devices. Two remotes for the same system, one gaps the codes sent with 4700 microseconds and the other 4900. What's the reason for 5000?

from rc-switch.

I presume that 5000 is a legacy gap, while modern devices tend to shorten the value. If you cut it down too far though, you might start getting false positives / false readings.

from rc-switch.

Maybe the sync signal duration can be used as "duration"? In my case the sync signal is protocol 1 with 150 us pulse length where the 'low' part is 31 pulse lengths => 31*150=4650 us

from rc-switch.

Makes absolutely sense. I'll check my RC's pulse length this weekend.

from rc-switch.

I just edited my comment to clarify that I referred to the low part of the sync signal since this is what "duration" measures if I recall correctly. I'm not sure what would happen if I get noise in between though.

from rc-switch.

The RCSwitch::handleInterrupt() is attached in CHANGE mode, so it is triggered on every slope.
This code at the beginning of the routine:

long time = micros();
duration = time - lastTime;

will cancel the whole readout when noise appears within the "duration" period.

from rc-switch.

I found an hx2262 based remote and the pulse length measured by getReceivedDelay() is 321 microseconds. The "gap/duration" of hx2262 measured 9.93 milliseconds on my scope. Comparing it with 4.69 milliseconds gap of RCO-14-b/fht7901 at 150 microseconds/pulse seems to corroborate your theory.
31 * 321 = 9951
31 * pulse_length = preamble_gap

from rc-switch.

As far as I can tell, a fix for this issue has been committed. Does that help? Or would you like to propose additional changes (such as making the nSeparationLimit value somehow dynamic)?

from rc-switch.

The lower nSeparationLimit fixes it for me, but it doesn't provide a "future proof" solution. A nicer solution I assume would be to, when a signal is correctly decoded, wait the corresponding nSeparationLimit time (depending on pulse length and protocol). Should we add that as a new issue or keep this one?

from rc-switch.

Measured difference between "old" hx2262 and "new" fht7901 seems to show the tendency of RC's internal clocks to pick up the speed in newer generations of devices. On the other hand - wild shortening of nSeparationLimit yields false readouts from background noise. For now - the constant value seems to work and is described well enough. Any future adjustments should depend on real devices. Therefore I decide to close the issue and leave it to the users to discover faster RCs.

from rc-switch.