Author Topic: Receiving Acurite 6045M Lightning detector with rtl_433  (Read 795 times)

0 Members and 1 Guest are viewing this topic.

Offline rct

  • Senior Member
  • **
  • Posts: 60
  • W2RCT
Receiving Acurite 6045M Lightning detector with rtl_433
« on: April 22, 2018, 12:33:06 PM »
A heads up to anyone using rtl_433 (and an RTL-SDR) to receive the Acurite 6045M lightning detector:

For rtl_433 downloads starting 2018-04-22, the lightning sensor ID value for the 6045M that is output from rtl_433 has changed. You will see a different ID value from earlier versions. So, if you are storing historical data, you might need to perform a mapping/renaming at the point where you upgrade rtl_433 versions.

Sorry for the inconvenience, this was necessary because my original guess for a 12-16 bit ID was incorrect, though it was similar to what the other Acurite devices I've decoded have used.  As reported in some of the earlier messages here, the 0x6F or 0xAF is *not* part of the ID.  That change happens when the battery is low.

So, if your ID before was 0x976F (or 0x97AF),  It will now be 0x097 (151 decimal).  You might have already seen your ID change when your battery level dropped below around 2.4 Vdc.

(For those interested in the low level details: I was using the 2nd and 3rd bytes of the message for ID.  Now I'm using the lower nybble of the 1st byte and the 2nd byte for a 12 bit ID.   In the 3rd byte, bit 0x40 is battery OK/Low. The bit 0x80 is a parity bit so it changes as well.  So far in the all the messages I've seen the lower 6 bits have been invariant, set to 0b101111.  This might be a fixed message type for the consoles to use.  But please let me know if you see anything different.

The new ID value i'm using is 12 bits, which is also based on the unproven assumption that they would use more than 8 bits for the sensor ID, similar to other sensors. For all the sensors I've seen so far the upper nybble of that sensor is has been all zeros. I would appreciate hearing if anyone sees an ID > 255.)

For those who've written parsers, more changed than just the ID, the output now uses JSON (or KV, CSV) like the other sensors.

The new output looks like:

Code: [Select]
{"time" : "2018-04-22 11:49:17", "model" : "Acurite Lightning 6045M", "id" : 151, "channel" : "A", "temperature_F" : 67.100, "humidity" : 28, "strike_count" : 48, "storm_dist" : 0, "active" : 1, "rfi" : 0, "ussb1" : 1, "battery" : "OK", "exception" : 0, "raw_msg" : "c0976f9c507b30c01d"}

Additional status bits have been broken out that were part of msg_type and L_status in the old decoding.

  • Active - Whether the sensor is in active detection mode, transmitting every 8 seconds, or low power standby mode.
  • RFI Detected - This is loosely correlated to the Yellow LED on the sensor.  Short intervals of RFI on are a normal occurrence for me.  Long periods of RFI on means something is interfering with the sensor, so it may need to be relocated
  • USSB1 - "Unknown Strike Status Bit 1" - This bit toggles during strike detection activity and may be related to the validity of the distance calculation. This bit is generally cleared when the sensor beeps to indicate it has detected a strike.

Regarding the storm_dist field: I need help (observations) from people with comptible Acurite displays who are also running rtl_433 to o come up with a formula to convert this to miles or kilometers.

Note: see the teardown thread by George Nincehelser that included a link to AS3935 for some clues about how the sensor is approximating the distance to storm edge.  According to the graph in the datasheet and observations, the approximation behaves like a step function.

I don't have an Acurite console that supports the 06045M, so I've had to make a number of guesses. I was hoping the hub would have supported it by now.  From what I've been able to determine, there are 5 bits in the Acurite message for the estimation of the distance to the edge of the storm.  This gives the values 0-31 (0x1f).   0x1f is invalid, that's the value at power up.

The value in the distance field is certainly invalid at times. I think the USSB1 bit == 0 as well as distance == 0x1f indicate whether the value is valid or not. I believe the USSB1 bit clears for a short period after a strike to indicate the current value is invalid. 

Regarding the exception and raw_msg fields:
  • raw_msg contains the raw bytes received in the message.  So if I've gotten anything wrong we still have the data to try to figure it out.
  • The exception field should generally be zero.  It will be one if something in the message differs from what I've previously seen, which might yield additional decoding clues

Sorry this has been so lengthy, I wanted to put the information out there for others that might be interested.