For more remote OOK temperature sensors, occasionally transmissions arrive malformed, and can therefore not be detected as such or properly decoded. The Oregon Scientific THN128 protocol V1 sensor perfoms two transmissions spaced some 200ms apart. When the first transmission is received properly, it is easy to record the raw RSSI and OOK data from a RFM69 during the transmission of the repeated signal. I have recorded two of the transmissions where the first part was succesful, and the second part contained an error.
The errors are in the marked area’s. It appears that such a bit-error is a noise spike that only takes one sample in both cases. Although it is a bit early to proof, it is very likely that failures to detect weak OOK signals are often short time-scale (high frequency) noise on the OOK signal.
Recording a histogram of all ON and OFF durations of the second transmission, including the preceeding gap after the end of the first transmission gives better insight in the high frequency noise.
The OFF (ZERO) peak at 1080µs belongs to the received OOK signal. The large distribution at the left hand side of the graph is noise. The red part indicate signal ON (ONE), and tend to be short between 40 and 100µs. For the OFF state the noise tail is a bit longer. It is clear that most noise energy is below the 200µs tiem-scale. Most remote control and sensor OOK pulse durations are above the 300µs time scale, so it should be possible to filter out the high frequency ON/OFF flips to clean-up the signal.
So could the reception be improved by getting rid of this type of short spikes on the intended signal? I have been thinking about this. When not using an interupt driven approach to detect ON to OFF and OFF to ON transitions, but by just polling the DATA (DIO2) pin of the RFM69, I can easily implement a kind of moving average filter for the two-valued data. Sampling at for exmaple 40µs and averaging the last 5 samples removes spikes of one and two sample duration. I tested this and it improves the reception of weak signals way better then I expected. I am now collecting more data on the improved performance.