Weather Station Hardware > AcuRite Weather Stations

Receiving Acurite 6045M Lightning detector with rtl_433

(1/5) > >>

rct:
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: ---{"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"}

--- End code ---

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.

semrick:
It's been awhile since the above post was written, but if you're still wondering how to adjust the lightning distance values from the 6045M to match the output in miles on the console, I think I've figured it out. After six lightning strokes this afternoon, the console distance is always 5 less than the 6045M storm_dist value. So it looks like you just have to subtract 5 from the storm_dist to get the value that the console shows (Miles, on my console).

That seems like an arbitrary conversion - why would it return the distance plus 5 miles? But that's what I'm seeing anyway. Looking through my database of values collected for the last month, I see the lowest value from the 6045M so far was 8, which I guess makes sense. I would expect to see values 5 or greater always.

Just thought I throw that out there, in case anyone was still wondering.

Storm017:
I don't think subtracting 5 from the distance in km will provide an accurate reading in miles, again I might be wrong. I just convert from KM to Miles:
Mi = km / 1.609344.

Had several storms just roll through and here is what I captured.

semrick:
No, subtracting five doesn't convert from km to miles - but I think the 6045M sends the distance in miles. Here's why:

I have an Acurite console, which shows the last lightning distance in miles and a SDR radio connected to my Raspberry PI. I was trying to match what was coming back from the radio, the "storm_dist" value, with what it showed on the console. At first I assumed the storm_dist was kilometers, since it was always higher than the value on the console. I tried converting KM to miles, using the appropriate formula - but it never matched the value on the console. Finally, I got six readings from a passing storm from both sources and even graphed the console value (in miles) against the storm_dist values to try to figure out the conversion. Then I smacked my forehead when I realized every console value was exactly 5 less than the corresponding storm_dist value. So the console must be subtracting 5 from the value it gets from the 6045M - no idea why.

Console Value6045M Value121725302227232817221520
I have a few weeks of data collected and the lowest distance reading I have so far is 8 - maybe Acurite noticed that the value never goes below 5, so they subtract 5? Just a guess. I'll have to collect more data to see if the value indeed never goes below five.

Storm017:
The 06045M is based off a AS3935 chip (https://www.mouser.com/pdfdocs/AMS_AS3935_Datasheet_v4.pdf) which outputs the distance in KM. I don't know why Acurite would convert the distance to miles in 06045M.

I do have two different types of consoles that are set on KM. Both consoles detected 12 KM strike, when I switch both over to display Miles the console displays 7 miles. Yes, 5 difference, but if you convert KM to Miles you get 7.45645, which is round down to 7.  I believe the decoding of the 06045M is still being worked on.

Navigation

[0] Message Index

[#] Next page