support for Acurite 5-n-1 weather sensor

[zerog2k]

I have an acurite 5-n-1 weather sensor, p/n VN1TX it has wind direction, wind speed, temp, humidity, and rainfall.

Using rtl_433 in analyze mode, I've been able to (mostly) reverse engineer the packet structures into usable data. Still working on a few specifics, but I can read temp, humidity, wind direction and speed. I'll work on rain gauge later.

Thanks also to a few internet postings which helped lead me in the right direction. http://www.wxforum.net/index.php?topic=18690.msg180713#msg180713 http://forum.arduino.cc/index.php?topic=145341.0

The trace of this looks very similar to postings in the arduino forum link above, but with a slightly longer data payload section.

It's pulse (width) coding. Each transmissions has a message repeated 3x with slight difference (i think a sequence id). Each message has: 4 sync? pulses, 1250 uS period, 50% duty cycle 65 data pulses, short pulse ~200-250 uS, long pulse ~350-400 uS

I'm currently trying to implement the timing in rtl_433.c, but having some trouble understanding how to setup the structure for these timings.

Not sure how i should setup the limits based upon my timings. I think the {short,long,reset}_limits should be samples, but unsure exactly if this is the low or high limit of detection, and whether its based upon 250k (default) or 1024k (mentioned in source code above device structs).

r_device acurite5n1 = {
    /* .id             = */ 10,
    /* .name           = */ "Acurite 5n1 VN1TX",
    /* .modulation     = */ OOK_PWM_P,
    /* .short_limit    = */ ?, 
    /* .long_limit     = */ ?,
    /* .reset_limit    = */ ?,
    /* .json_callback  = */ &acurite5n1_callback,
};

jens@spire:~/build/rtl_433/build$ src/rtl_433 -a
Registering protocol[01] Rubicson Temperature Sensor
Registering protocol[02] Prologue Temperature Sensor
Registering protocol[03] Silvercrest Remote Control
Registering protocol[04] ELV EM 1000
Registering protocol[05] ELV WS 2000
Registering protocol[06] Waveman Switch Transmitter
Registering protocol[07] Steffen Switch Transmitter
Registering protocol[08] Acurite 5n1 VN1TX
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
Sample rate set to 250000.
Sample rate decimation set to 0. 250000->250000
Bit detection level set to 10000.
Tuner gain set to Auto.
Reading samples in async mode...
Tuned to 433920000 Hz.
*** signal_start = 1635516, signal_end = 1689257
signal_len = 53741,  pulses = 207
Iteration 1. t: 69    min: 39 (134)    max: 99 (73)    delta 2434
Iteration 2. t: 67    min: 37 (128)    max: 98 (79)    delta 5
Iteration 3. t: 67    min: 37 (128)    max: 98 (79)    delta 0
Pulse coding: Short pulse length 37 - Long pulse length 98

Short distance: 61, long distance: 118, packet distance: 164

p_limit: 67

[00] {1} 80 : 10000000 
[01] {1} 80 : 10000000 
[02] {1} 80 : 10000000 
[03] {1} 80 : 10000000 
[04] {65} c6 88 71 00 a6 00 9f 04 00 : 11000110 10001000 01110001 00000000 10100110 00000000 10011111 00000100 00000000 
[05] {1} 80 : 10000000 
[06] {1} 80 : 10000000 
[07] {1} 80 : 10000000 
[08] {1} 80 : 10000000 
[09] {65} d6 88 71 00 a6 00 9f 14 00 : 11010110 10001000 01110001 00000000 10100110 00000000 10011111 00010100 00000000 
[10] {1} 80 : 10000000 
[11] {1} 80 : 10000000 
[12] {1} 80 : 10000000 
[13] {1} 80 : 10000000 
[14] {65} e6 88 71 00 a6 00 9f 24 00 : 11100110 10001000 01110001 00000000 10100110 00000000 10011111 00100100 00000000 

*** signal_start = 1758238, signal_end = 1778264
signal_len = 20026,  pulses = 1
Distance coding: Pulse length 25

Short distance: 1000000, long distance: 0, packet distance: 0

p_limit: 25

[00] {0} 00 : 00000000 

^CSignal caught, exiting!

User cancel, exiting...

[zerog2k]

oh here is the script im using to parse the rtl_433 -a output: https://gist.github.com/zerog2k/577aec37c9a97078c1c3

[zerog2k]

here are outputs from rtl_433 -a, with pcm and gfiles: https://onedrive.live.com/redir?resid=14DD1F51D490C59E!1103&authkey=!AKi8eKeWd8m6NdE&ithint=file%2c.tgz

[merbanan]

There is an issue where I described what values can be used in a protocol. So look through the previous issues.

[zerog2k]

Hi Benjamin, Yes I read through every issue I could, but that wasnt exactly helpful. It was specific to a different device, and was based upon an older "analysis" format (from older version of rtl_433) which doesnt exactly correspond to current output format.

I have looked at: https://github.com/merbanan/rtl_433/issues/5 https://github.com/merbanan/rtl_433/issues/23

My take so far: select a short_limit between the short and long pulse lengths as seen by rtl_433 -a For me, short pulses are about ~50 (samples?) and long pulses ~100 So I selected a short_limit of 75.

Not sure about long_limit, but per your instructions I selected long_limit and reset_limit very high, e.g., 10000.

Even with this, the bytestream output from rtl_433 -D (below) is radically different from the output of rtl_433 -a. (Note that I have turned down the BITBUFF_COLS to 5 as there was just a lot of junk/empty buffers from the demod process.)

So im not sure where to go here. I was expecting to see a buffer matrix that resembled what I see from rtl_433 -a, which has a structure which matches reality when decoded.

r_device acurite5n1 = {
    /* .id             = */ 10,
    /* .name           = */ "Acurite 5n1 Weather Station",
    /* .modulation     = */ OOK_PWM_P,
    /* .short_limit    = */ 75,
    /* .long_limit     = */ 10000,
    /* .reset_limit    = */ 10000,
    /* .json_callback  = */ &acurite5n1_callback,
};

sample output now from rtl_433 -D

jens@spire:~/build/rtl_433/build$ src/rtl_433 -D
Registering protocol[01] Rubicson Temperature Sensor
Registering protocol[02] Prologue Temperature Sensor
Registering protocol[03] Silvercrest Remote Control
Registering protocol[04] ELV EM 1000
Registering protocol[05] ELV WS 2000
Registering protocol[06] Waveman Switch Transmitter
Registering protocol[07] Steffen Switch Transmitter
Registering protocol[08] Acurite 5n1 Weather Station
Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Exact sample rate is: 250000.000414 Hz
Sample rate set to 250000.
Sample rate decimation set to 0. 250000->250000
Bit detection level set to 10000.
Tuner gain set to Auto.
Reading samples in async mode...
Tuned to 433920000 Hz.
Detected Acurite 5n1 sensor

[00] 07 2e f0 ff e8 9c 9c 48 d0 29 77 87 ff 44 e4 e2 36 80 cb bc 3f fa 27 27 11 34 00 00 00 00 00 00 00 00 : 00000111 00101110 11110000 11111111 11101000 10011100 10011100 01001000 11010000 00101001 01110111 10000111 11111111 01000100 11100100 11100010 00110110 10000000 11001011 10111100 00111111 11111010 00100111 00100111 00010001 00110100 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
[01] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
[02] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
[03] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
[04] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

Detected Acurite 5n1 sensor

[00] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
[01] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
[02] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
[03] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 
[04] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 : 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

[zerog2k]

Ok, getting even closer, but the trouble I have now is that the the bits are all inverted. I think the demod is missing first bits and getting confused - not sure why this is absolutely fine in analyze mode.

So I'm using these settings: rdevice acurite5n1 = { /* .id = / 10, / .name = / "Acurite 5n1 Weather Station", / .modulation = / OOK_PWMP, / .shortlimit = / 75, /_ .longlimit = / 230, /_ .resetlimit = / 20000, /_ .json_callback = */ &acurite5n1_callback, };

and I am printing out the second set message in the group:

Detected Acurite 5n1 sensor
A9 77 8E FF 41 7E 65 57  
56 88 71 00 BE 81 9A A8  inverted

Detected Acurite 5n1 sensor
A9 77 87 FF 95 4D 50 5E  
56 88 78 00 6A B2 AF A1  inverted

When I invert the bytes, I get the expected values, same as what is output from analyze mode. Any ideas why I'm getting bits inverted?

[merbanan]

No idea, but just invert the bits if that is correct.

[zerog2k]

Looked at this some more today. Looks like that is not a viable option. The 4 "sync" pulses always seem to run into the following leading data byte, e.g, 66 becomes A6.

I have played with a number of settings and cannot seem to come up with ones that produce same output as rtl_433 -a, so I'll have to give up on this unless someone else has better ideas.

Also, wished very much that I could override these from commandline, to support faster testing of all possible values to find ones that produced correct output. [-z override short value [-x override long value

Unfortunately, edit/recompile is a lengthy process for trying to find the sweet spot.

[merbanan]

I'll try to make some time to look at the signals.

[zerog2k]

I looked at this again, and my best guess is that the sync pulses are getting detected as leading ones, and also causing the remaining bits to invert in the message. My guess is that the pwm_p_decode function may need some extra work for this type of message. Instead I have just gone the hack route and worked with it as best I could. I have a working branch on my fork for this, but decided to factor this out into a separate file. To do that i also moved some stuff to rtl_433.h. This is alot of changes, so unless there is a big need to merge it up, I wont bother splitting it up and submitting PR for this unless there is some demand.

https://github.com/zerog2k/rtl_433/blob/acurite5n1/src/acurite5n1.h

[zerog2k]

just for continuity, submitted PR to merge upstream in #51

[helgew]

Thank you guys for all your work on this. I was curious whether you have managed to decode the rain gauge readings by now?

[helgew]

Nevermind, I found the bug :)

Please consider pulling PR72.

[Newzwaver]

Hi Did you manage to figure this project out if so can you share your findings? I have a 3in1 acurite will is work with it? thanks Tim

[rct]

The acurite 5-n-1 sensor is correctly parsed for temperature, humidity. The wind speed and wind direction I think are right or mostly right. However the rain gauge isn't being parsed correctly.

Please give it a try. You might have to experiment with the level limit -l to get decodes.

It would be good to get some samples for the 3-n-1 sensor added to the rtl_433_tests repository. When you make recordings with -a -t pleas try to include a note that says what the values should be roughly when decoding.

[rct]

As far as the 3-n-1 sensor goes, one thing that makes me think the 5-n-1 might be close is the 5-n-1 sends two separate message, which are probably compatibility related:

1. Wind speed, temperature, humidity
2. Wind speed, wind direction, rain gauge.

So looks like the first message type, would be something the 3-n-1 would send.

[aweatherguy]

I don't know if it will help any, but here's a link to a document that shows the format of the 5n1 data packets. See pages 7 and 8. There is important information there about wind speed and the rain gauge data too.

Regarding wind speed -- the sensor reports the maxiumum number of full cup rotations over any 4-second period within an 18-second reporting window. It is necessary to convert the cup rotation count into wind speed using a standard anemometer formula and this has been reverse-engineered from AcuRite software and is shown in the document.

Hope this helps!

http://www.osengr.org/WxShield/Downloads/Weather-Sensor-RF-Protocols.pdf

[helgew]

Sorry to have been absent from these discussions for so long. I am hoping to get back to rtl_433 and implement some of the reporting work that had been discussed previously.

That said, rtl_433 works well in my hands for all parameters it reports. I just checked my logs and the recent rain fall events have been reported correctly.

cheers, h.

On Oct 12, 2015, at 3:08 PM, rct notifications@github.com wrote:

The acurite 5-n-1 sensor is correctly parsed for temperature, humidity. The wind speed and wind direction I think are right or mostly right. However the rain gauge isn't being parsed correctly.

Please give it a try. You might have to experiment with the level limit -l to get decodes.

It would be good to get some samples for the 3-n-1 sensor added to the rtl_433_tests repository. When you make recordings with -a -t pleas try to include a note that says what the values should be roughly when decoding.

— Reply to this email directly or view it on GitHub https://github.com/merbanan/rtl_433/issues/42#issuecomment-147534683.

[rct]

@aweatherguy - That's a great document!

I just wish I had found it before I spent a number of hours figuring out the Acurite Tower sensor, the 592TXR. I have it figured out and have implemented the code but I need to clean it up before committing it.

I hadn't gotten to the battery testing yet, but it looks like you've got that covered.

I did see that the WxShield was decoding the 592TXR but I didn't think any of the code/information was published.

From skimming it looks like you have one set of the ID bits listed as a fixed set of unknown bits. From what I've been able to tell, the 592TXR uses 14 bits of the first two bytes as ID, where the 5-n-1, uses only 12 bits. My two tower sensors use those ID bits:

• 12053 = 0x2f15 = 0b cc10 1111 0001 0101
• 9884 = 0x269c = 0b cc10 0110 1001 1100

The first two bytes and the checksum byte do not use a parity bit while all of the rest do. This seems to be the same for the 5-n-1. The current rtl_433 code for the 5-n-1 doesn't do any parity checking. The Desert-Home fork does, but checks the ID byte for parity so it rejects some sensor ID/channel combinations.

@helgew the rain values weren't working for me, but I also found the current code to be very (or overly) sensitive to the level limit (-1). Also I was seeing false positives from the other acurite rain gauge decoder which was giving non-sensical values that I was confusing as being part of the 5-n-1 output.

I noticed a number of improvements in the Desert-Home-rtl_433 fork.

I'm currently using the PWM_TERNARY demodulator which seems pretty stable and doesn't have the problems of inverting the bit, or stumbling over the sync bits.

I briefly tried the PWM_PRECISE demod, but I couldn't find a combination of value and a level limit that would reliably decode my three Acurite devices (5-n-1 and two tower sensors). After I get the rest working well, I will revisit trying to use PWM_PRECISE.

[helgew]

Here is some additional data on the Acurite 5-n-1 from a source who prefers not to be named: Data rate is around 1.6 kbps PWM with 400us high/210us low for 1 and 210us high/400us low for 0. There is a pre-amble of four high pulses at 610us each followed by four lows of the same length.

There are some differences in the document that I have with the one that was linked to. The following is what I have and which I believe is faithfully encoded in the current master, albeit after inversion and missing first bits: The preamble bit is followed by 8 packets of 8 bits each. With the exception of the first two and the last one (which is the checksum), they all include a parity bit. The first packet contains the channel information in the firs two bits (A = 11, B = 10, C = 01), and the remaining 6 bits together with the second packet are the station ID. The third packet holds battery information (1 bit, 0 for low, 1 for normal) and message type (6 bits). Packets 4 through 7 contain data that depends on the message type: For message type 111000 they hold wind gust, humidity, and temperature. For type 110001 (18s later) they hold wind gust and rain gauge data. Wind gust is contained in the higher 7 bits and the lower 3 bits of data packets 1 and 2 respectively. If 0, the speed is 0, otherwise it is value * .23 + .28 in m/s. Temperature uses the higher 4 bits and lower 7 bits, which ranges from -40°F (0) to 158°F (2047), i.e. (value - 400) / 10 in °F. Humidity is a 7 bit number that converts directly and ranges between 1% RH to 99% RH. Wind direction is complicated essentially a lookup table of 16 directions encoded by 4 bits. The rain gauge data is a counter of bucket tips that ranges from 0 to 16383 (14 bits). Each bucket tip corresponds to 0.01 in. of rain. Data is accumulated starting with power-up. When the counter reaches 16383 it resets to 0.

My station repeats each message three times. I don’t remember if it sends a pre-amble with every repeat or what the spacing is.

hth, h.

On Oct 14, 2015, at 11:05 AM, rct notifications@github.com wrote:

@aweatherguy https://github.com/aweatherguy - That's a great document!

I just wish I had found it before I spent a number of hours figuring out the Acurite Tower sensor, the 592TXR. I have it figured out and have implemented the code but I need to clean it up before committing it.

I hadn't gotten to the battery testing yet, but it looks like you've got that covered.

I did see that the WxShield was decoding the 592TXR but I didn't think any of the code/information was published.

From skimming it looks like you have one set of the ID bits listed as a fixed set of unknown bits. From what I've been able to tell, the 592TXR uses 14 bits of the first two bytes as ID, where the 5-n-1, uses only 12 bits. My two tower sensors use those ID bits:

12053 = 0x2f15 = 0b cc10 1111 0001 0101 9884 = 0x269c = 0b cc10 0110 1001 1100 The first two bytes and the checksum byte do not use a parity bit while all of the rest do. This seems to be the same for the 5-n-1. The current rtl_433 code for the 5-n-1 doesn't do any parity checking. The Desert-Home fork does, but checks the ID byte for parity so it rejects some sensor ID/channel combinations.

@helgew https://github.com/helgew the rain values weren't working for me, but I also found the current code to be very (or overly) sensitive to the level limit (-1). I noticed a number of improvements in the Desert-Home-rtl_433 fork.

I'm currently using the PWM_TERNARY demodulator which seems pretty stable and doesn't have the problems of inverting the bit, or stumbling over the sync bits.

I briefly tried the PWM_PRECISE demod, but I couldn't find a combination of value and a level limit that would reliably decode my three Acurite devices (5-n-1 and two tower sensors). After I get the rest working well, I will revisit trying to use PWM_PRECISE.

— Reply to this email directly or view it on GitHub https://github.com/merbanan/rtl_433/issues/42#issuecomment-148139011.

[aweatherguy]

rct -- thanks for the addtional information. I'll see about updating the document accordingly. One question on parity for the 00592 -- I was seeing the status byte flip from 0x44 to 0x84 when the battery went low -- there doesn't seem to be parity in that byte. Am I missing something?

Thanks to helgew too -- I'll go through your post to and update the document as necessary.

BTW, the WxShield code is open source and you can get the current copy at the link below. WxShield only spits out the raw RF bits and the rest of the decoding is done by the WSDL program. That is also open source and you can get a copy of that at the 2nd link below. It is a large program but you only would need to look in the file "ArduinoDataParser.cs".

I'm currently working on some improvements on the decoding of PSM (pulse-spacing modulation). The long time gaps between message repeats (about 9-10ms) create problems in some receivers. They are not designed for such slow signals and may think the signal has quit. They then start adjusting AGC gains and/or data slicing thresholds during this time period and you start to see noise being detected before the next message repeat begins. Anyway, those changes are not in the source code linked below.

http://www.osengr.org/WxShield/Downloads/WxShield-Arduino-Source-v4.2.0.zip

http://sourceforge.net/projects/wmrx00/files/1.%20Windows%20Install/5.4.4.0%20BETA/WSDL-5.4.4.0-Source.7z/download

[rct]

FWIW, The current acurite.c in merbanan/rtl_433/src/devices doesn't do anything with parity checking though the bits are generally ignored with a 0x7f mask.

Note the 4 sync bits are send at the start of each message, including the 4 repeats.

I think the rain is correct. My statement that rain wasn't being decoded correctly was incorrect. The false positives from the other acurite device the 896 rain sensor were what was confusing me.

Also, I agree after looking closer at aweatherguy's document, I do see a few errors/difference.

The description above says the message type is 6 bits, (the first two bits are the battery status or battery status and parity). The current code only looks at 4 bits of the message type. I wonder if aweatherguy's analysis that there are 3 status bits (+ parity) doesn't make more sense.

Thanks, --Rob

[helgew]

I think since only the low four bits of the message type matter (high two are always 11), there is no point in looking at all six.

cheers, h.

On Oct 14, 2015, at 1:59 PM, rct notifications@github.com wrote:

FWIW, The current acurite.c in merbanan/rtl_433/src/devices doesn't do anything with parity checking though the bits are generally ignored with a 0x7f mask.

Note the 4 sync bits are send at the start of each message, including the 4 repeats.

I think the rain is correct. My statement that rain wasn't being decoded correctly was incorrect. The false positives from the other acurite device the 896 rain sensor were what was confusing me.

Also, I agree after looking closer at aweatherguy's document, I do see a few errors/difference.

The description above says the message type is 6 bits, (the first two bits are the battery status or battery status and parity). The current code only looks at 4 bits of the message type. I wonder if aweatherguy's analysis that there are 3 status bits (+ parity) doesn't make more sense.

Thanks, --Rob

— Reply to this email directly or view it on GitHub https://github.com/merbanan/rtl_433/issues/42#issuecomment-148198653.

[rct]

@aweatherguy thanks for the links to the code and the info.

As far as the 592TXR battery status byte and whether it is parity checked or not, I'll drag out the adjustable power supply and test at some point soon.

[rct]

@aweatherguy - Finally got a chance to test low battery on the 592TXR. I got the same results 0x44 (battery normal, message type 0x4). The parity implementation is correct, the high bit gets turned on to maintain the same bit parity when the battery normal bit 0x40) is not longer set.

From my tests on both the 592TXR and 5n1, all bytes other than the first two ID bytes, and the last byte, the checksum use parity checking.

I never got a chance to test the 5n1 with a low battery.