Protocol 9 does a straight circular mapping. Some people seem to feel that is correct. Protocol 39 does a mapping using a modified gray code that matches the old aculink reporting and my 01512 display. I believe some of the aculink parsers (ipwx, haculink, etc.) went through the same discovery process. I don't know if there are two versions of the 5-n-1, or if the people who feel the original circular mapping is correct just haven't noticed.
I'm pretty sure there's only the gray-code mapping. It comes from a plastic optical encoder disc inside the 5n1. It wouldn't make a lot of sense for them to change that for different production runs.
I agree, I wouldn't think that would make sense. I was just given those who think it is/was correct the benefit of a doubt.
Quote
In any case, it's really easy to fool yourself that the "circular" mapping sorta works, but when you really look at it in a detailed, methodical fashion, the gray-code version is correct.
Agreed.
Quote
QuoteRegarding suppressing duplicate messages: The Acurite devices send the message multiple times in each message burst. In a number of cases, the received signal strength indicator on acurite gear is not the actual signal level, or signal-to-noise ratio, but is an attempt indication of quality judging by the number of times the message was heard. Note: IIRC, Protocol 9 will suppress duplicates, but assumes that only a single 5-n-1 will ever be heard.
Hmm... on the displays they subtract a bar every time an expected data packet is missed, when it drops to zero then the display starts rescanning.
On the bridge/SmartHUB, there's an analog voltage on the RSSI pin of the radio module that represents the signal strength. I don't know the details of how they are computing that, but the bridge's microcontroller converts that into an integer up to 4.
Good to know, at this point, I don't remember where I got the impression that the RSSI interpretation was based on the number of successful receives.
Note on the 5-n-1, each message has a bit to indicate if it's the 1st, 2nd or 3rd copy.
Code: [Select]
// The sensor sends the same data three times, each of these have
// an indicator of which one of the three it is. This means the
// checksum and first byte will be different for each one.
// The bits 5,4 of byte 0 indicate which copy of the 65 bit data string
// 00 = first copy
// 01 = second copy
// 10 = third copy
// 1100 xxxx = channel A 1st copy
// 1101 xxxx = channel A 2nd copy
// 1110 xxxx = channel A 3rd copy
The 592 tower and the 6045 lightning detector don't have this property.
Currently the decoders in rtl_433 don't have a notion of signal strength. The Pulse Analyzer, enabled with -A, attempts to give some info based about signal levels and frequency offset.