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

0 Members and 1 Guest are viewing this topic.

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • 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.

Offline semrick

  • Member
  • *
  • Posts: 5
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #1 on: July 07, 2020, 03:51:49 PM »
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.

Offline Storm017

  • Senior Contributor
  • ****
  • Posts: 172
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #2 on: July 08, 2020, 12:36:27 PM »
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.


Offline semrick

  • Member
  • *
  • Posts: 5
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #3 on: July 08, 2020, 04:19:51 PM »
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 Value
1217
2530
2227
2328
1722
1520

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.
« Last Edit: July 08, 2020, 04:26:48 PM by semrick »

Offline Storm017

  • Senior Contributor
  • ****
  • Posts: 172
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #4 on: July 08, 2020, 05:35:24 PM »
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.

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #5 on: July 08, 2020, 06:00:42 PM »
I've made a bit of progress on this once the Acurite Access added support for the 6045. I had mentioned it in other groups/threads.

I'm in the US, MyAcurite and my Acurite Access are set to imperial (US) unit so I see miles. It would be really helpful if someone else with rtl_433 and an acurite access set to metric/SI units could record the KM output from the Access and correlate it with the raw values output via rtl_433.

From the AS3935 datasheet there are 16 possible values.  The AS3935 uses 6 bits (0-63) and sends the storm distance in KM.  The Acurite message uses 5 bits (0-31).  The Access values look close to the KM values converted to Miles, but there are errors that are greater than rounding up/down.

The raw values I've seen via rtl_433: 0, 4, 5, 7, 8, 10, 12, 15, 17, 20, 22, 24, 27, 31   

31 is used to indicate an invalid value.  This is what the unit sends after it has been powered up before it detects any lightning.  In theory, there should be 16 values, so I'm missing 2.

These are the raw message to miles values I've correlated.

Code: [Select]
Raw    Access - Miles
0           1  (1 mile is the lowest the Access/MyAcurite reports - storm is directly overhead)
4           3
5           4
7           5
8           6
10          7
12          9
15         11
17         12
20         15
22         17
24         19
27         22
31         na


4 of the 6 mappings @semrick provided via console observations match what I've captured using the Acurite Access:

Code: [Select]
Raw    Access - Miles
17         12
20         15
22         17
24         19
27         22


Since I've had the ability to capture with the Access, the highest raw value I've seen is 27.   So the two additional mappings @semrick provided may be the two I haven't caught. The mappings for 28 and 30 fit in nicely.   

25 miles is the max distance the 6045 reports according to the specs.  A value of 30 for that (given than 31 is the max and is used to indicate an invalid value) makes sense.

You'll notice the offset is less than 5 at lower values.  The offsets range from 1-5.  It looks like it is based on a curve rather than linear.

So if I add @semricks two observations to mine, the (possibly complete?) raw distance value to miles mapping table is:

Code: [Select]
Raw    Access - Miles
0           1  (1 mile is the lowest the Access/MyAcurite reports - storm is directly overhead)
4           3
5           4
7           5
8           6
10          7
12          9
15         11
17         12
20         15
22         17
24         19
27         22
28         23
30         25
31         na

« Last Edit: July 08, 2020, 06:34:26 PM by rct »

Offline Storm017

  • Senior Contributor
  • ****
  • Posts: 172
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #6 on: July 08, 2020, 07:02:37 PM »
@rct I don't have the acurite access, but could provide rtl_433/Console data in KM, if that will help.   Looks like the AS3935 reports approx every 2 miles starting at 25 miles until the storm is approx 7 miles, then reports approx every 1 mile until it is overhead. But on my console I already saw 40+KM.

@semrick Do have the acurite access?

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #7 on: July 08, 2020, 07:12:36 PM »
I believe the decoding of the 06045M is still being worked on.

I did the decoding/implementation of the 6045m in rtl_433.  I'm at least 90% confident that I have the right raw bits in the message for the storm distance but I couldn't come up with the mapping because I didn't have a console and nothing seemed to make sense. So I've left the storm_dist as is for now while I've collected data.

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.

As mentioned in the previous message, I've got the Acurite Access which is sending messages to My Acurite in miles, so that's what I've been correlating against. I haven't been interested in trying to get the Access and MyAcurite to report in metric/SI while thunderstorms are few and far between. 

The AS3935 does output in KM, it uses a 6 bit field (0-63) where Acurite decided to use only 5 bits (0-31).

According to the datasheet there are only 16 possible values for storm distance in KM:  1, 5, 6, 8, 10, 12, 14, 17, 20, 24, 27, 31, 34, 37, 40, 63.
(1 == storm directly overhead, 63 == out of range/invalid)

Things would have been much simpler if Acurite just send those values over the wire and left 6 bits in the message for it. 

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. 

My working theory is that the 6045 is doing something close to dividing the KM value reported by 1.2 to get the value that goes in the message.  So multiplying the raw value by 1.2 seems like it would work ok for many of the observations I have which have been skewed by rounding to miles introducing additional error.  (Mapping the values and trying to come up with a divisor gives values between 1.13 and 1.37)

However, getting KM by multiplying the raw value by 1.2 and then converting to miles for those who want US units, would wind up with a number of values that won't match the Acurite console/My Acurite.

I think people will expect that they'd get values that matches what Acurite consoles/My Acurite is using.



« Last Edit: July 08, 2020, 07:30:17 PM by rct »

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #8 on: July 08, 2020, 07:18:39 PM »
@rct I don't have the acurite access, but could provide rtl_433/Console data in KM, if that will help.   Looks like the AS3935 reports approx every 2 miles starting at 25 miles until the storm is approx 7 miles, then reports approx every 1 mile until it is overhead. But on my console I already saw 40+KM.

@semrick Do have the acurite access?

I'm interested in any reliable correlations between the raw value and KM, especially at the far end of the range.

40 KM / 25 Miles is supposed to be the max according to the 6045 specs.   Have you seen a value over 40 KM?

The biggest gap in my observations are the longest distances.

Offline Storm017

  • Senior Contributor
  • ****
  • Posts: 172
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #9 on: July 08, 2020, 07:32:19 PM »
Quote
Have you seen a value over 40 KM?

On the Acurite Console 06047-RX, I seen it display "40+KM". Maybe that correlates with "63".

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #10 on: July 08, 2020, 07:37:40 PM »
Quote
Have you seen a value over 40 KM?

On the Acurite Console 06047-RX, I seen it display "40+KM". Maybe that correlates with "63".

Interesting.  What does it display in miles at that point 25 M or 25+ Miles?

Does it also display 40 KM without the '+'?

Offline semrick

  • Member
  • *
  • Posts: 5
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #11 on: July 08, 2020, 08:43:35 PM »
Quote
@semrick Do have the acurite access?
No, I have an Acurite 06058M console, but since it doesn't have a way to output the data, I got an rtl radio so that I could play with the data. I've got the console set to show lightning distance in miles.

Quote
The AS3935 does output in KM
Interesting - so the Acurite 6045M must be modifying the data that the A3935 outputs, since the raw values don't seem to be quite KM or miles.

Quote
You'll notice the offset is less than 5 at lower values.  The offsets range from 1-5.  It looks like it is based on a curve rather than linear.
Also interesting. So I can't just subtract 5 all the time - at least not below raw 17. Looks like I should just map the observed raw values to the observed miles values. 

I haven't had a storm go by close enough since I set this up to see the lower values - thanks to everyone sharing what they've learned.

Offline Storm017

  • Senior Contributor
  • ****
  • Posts: 172
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #12 on: July 08, 2020, 09:38:14 PM »
Quote
Have you seen a value over 40 KM?

On the Acurite Console 06047-RX, I seen it display "40+KM". Maybe that correlates with "63".

Interesting.  What does it display in miles at that point 25 M or 25+ Miles?

Does it also display 40 KM without the '+'?

It actually displayed the "+" sign. Next time I see it displayed, will grab a photo and switch over to miles to see if a "+" sign also appears.

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #13 on: July 09, 2020, 10:20:44 AM »
Quote
@semrick Do have the acurite access?

Also interesting. So I can't just subtract 5 all the time - at least not below raw 17. Looks like I should just map the observed raw values to the observed miles values. 

@semrick - see the raw to miles table at the end of my post above.

I think I have most of the mappings figured out. 

As soon as I'm a little more confident I'll update rtl_433 to output either storm_dist_km or storm_dist_miles.

Offline semrick

  • Member
  • *
  • Posts: 5
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #14 on: July 09, 2020, 11:51:01 AM »
Thank you rct, I think you've got it nailed down. It fits all the information. The sixteen possible km values from the AS3935 chip match exactly the miles shown on my console for each one when converted from km to miles. Well, except for 34 (27 raw). If I convert that to miles, I get 21.1266, but the table and my console show that as 22. Not going to quibble about that one - close enough.

I got some more data from lightning last night (beeping woke me up!  :roll:), all of the data I've collected so far is limited to one of those 16 possible values. I haven't seen them all yet, but nothing has gone outside of those 16.

I think what I'll do for now is create an integer array indexed by the raw value and populated with the miles values from your table. I can fill in the miles values for the raw entries that are not part of the 16 - just in case. I can figure out the "missing" miles values by converting the "missing" chip km values to miles.

Thanks for all your work on this - an amazing feat of reverse engineering!

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #15 on: July 09, 2020, 01:24:32 PM »
Thank you rct, I think you've got it nailed down. It fits all the information. The sixteen possible km values from the AS3935 chip match exactly the miles shown on my console for each one when converted from km to miles. Well, except for 34 (27 raw). If I convert that to miles, I get 21.1266, but the table and my console show that as 22. Not going to quibble about that one - close enough.

I think 22 could be an error on Acurite's part. The pattern from the chip's datasheet says that value should be 22, not 21.  However it is interesting (and possibly reassuring) that both the access and your 6058 console show the same value.  Also I was missing the two highest values, which you filled in. With that I'm much more confident about the decoding.

I've put what I've observed/captured/learned in a google sheet - https://docs.google.com/spreadsheets/d/1kYRO3SoMUyp2MKIzyurYnS-NA1Q8UYGJgUASGcMLxcE/edit?usp=sharing in case anyone wants to take a look/comment/point out obvious errors in my math.

I think what I'll do for now is create an integer array indexed by the raw value and populated with the miles values from your table. I can fill in the miles values for the raw entries that are not part of the 16 - just in case. I can figure out the "missing" miles values by converting the "missing" chip km values to miles.

Thanks for all your work on this - an amazing feat of reverse engineering!

At this point, I'm planning to update rtl_433, and output "storm_dist_km".  I think KM is the native format for the sensor.  I've also convinced myself that converting KM to Miles using offsets for the conversion doesn't introduce rounding errors that would cause people to think the decoding was incorrect.

I will use an array of offsets. See the Google sheet. I've also made guesses for missing values so there should be a somewhat reasonable output should any other values turn up.

Question - What should the value of storm_dist_km be when the raw value is 31 (out of range/invalid)?

I think I've only seen the 6045 send a distance of 31 after it powers up before any lightning has been detected.   The AS3935 uses 63 (the highest 6 bit value).

My inclination is to either set it to '-1' or not include storm_dist_km if the raw value is 31. Thoughts welcome.
« Last Edit: July 09, 2020, 01:31:57 PM by rct »

Offline semrick

  • Member
  • *
  • Posts: 5
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #16 on: July 09, 2020, 01:36:33 PM »
Quote
My inclination is to either set it to '-1' or not include storm_dist_km if the raw value is 31.   Thoughts welcome.
I'd vote for -1.

Offline Storm017

  • Senior Contributor
  • ****
  • Posts: 172
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #17 on: July 09, 2020, 02:11:59 PM »
Quote
My inclination is to either set it to '-1' or not include storm_dist_km if the raw value is 31.   Thoughts welcome.
I'd vote for -1.

I would not include it in "storm_dist_km".  This way won't need to deal with a "-1" in the database.

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #18 on: July 09, 2020, 05:16:23 PM »
Well, except for 34 (27 raw). If I convert that to miles, I get 21.1266, but the table and my console show that as 22. Not going to quibble about that one - close enough.

I think 22 could be an error on Acurite's part. The pattern from the chip's datasheet says that value should be 22, not 21.  However it is interesting (and possibly reassuring) that both the access and your 6058 console show the same value.

If anyone with a console catches a distance of 22 miles, I'd be very interested if you can flip the display over to SI/KM and see whether you get 34 KM or a different value.

Offline Dahc

  • Member
  • *
  • Posts: 2
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #19 on: July 14, 2020, 08:47:23 AM »
Is it possible the least significant bit has another meaning? If we shift current values right by one bit things line up except for the 3-mile range.

Code: [Select]
| Current | Binary | Theory | Binary | Distance |
|---------|--------|--------|--------|----------|
| 0       | 00000  | 0      | 0000   | 1        |
|         |        | 1      | 0001   | 3        |
| 4       | 00100  |        |        | 3        |
| 5       | 00101  | 2      | 0010   | 4        |
| 7       | 00111  | 3      | 0011   | 5        |
| 8       | 01000  | 4      | 0100   | 6        |
| 10      | 01010  | 5      | 0101   | 7        |
| 12      | 01100  | 6      | 0110   | 9        |
| 15      | 01111  | 7      | 0111   | 11       |
| 17      | 10001  | 8      | 1000   | 12       |
| 19      | 10011  | 9      | 1001   | 14       |
| 20      | 10100  | 10     | 1010   | 15       |
| 22      | 10110  | 11     | 1011   | 17       |
| 24      | 11000  | 12     | 1100   | 19       |
| 27      | 11011  | 13     | 1101   | 21       |
| 28      | 11100  | 14     | 1110   | 23       |
| 30      | 11110  | 15     | 1111   | 25       |

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #20 on: July 14, 2020, 01:21:02 PM »
Is it possible the least significant bit has another meaning? If we shift current values right by one bit things line up except for the 3-mile range.

Code: [Select]
| Current | Binary | Theory | Binary | Distance |
|---------|--------|--------|--------|----------|
| 0       | 00000  | 0      | 0000   | 1        |
|         |        | 1      | 0001   | 3        |
| 4       | 00100  |        |        | 3        |
| 5       | 00101  | 2      | 0010   | 4        |
| 7       | 00111  | 3      | 0011   | 5        |
| 8       | 01000  | 4      | 0100   | 6        |
| 10      | 01010  | 5      | 0101   | 7        |
| 12      | 01100  | 6      | 0110   | 9        |
| 15      | 01111  | 7      | 0111   | 11       |
| 17      | 10001  | 8      | 1000   | 12       |
| 19      | 10011  | 9      | 1001   | 14       |
| 20      | 10100  | 10     | 1010   | 15       |
| 22      | 10110  | 11     | 1011   | 17       |
| 24      | 11000  | 12     | 1100   | 19       |
| 27      | 11011  | 13     | 1101   | 21       |
| 28      | 11100  | 14     | 1110   | 23       |
| 30      | 11110  | 15     | 1111   | 25       |

Thanks for looking into this.  Over the course of looking at this I tried a number of different theories. There were many that worked except for a few values.

I may not be understanding your theory. Here's what I consider the givens:

The values that the AS3935 produces from the data sheet, which happen to be in KM (16 possible values, 6 bits needed, see table 17, page 21):

1, 5, 6, 8, 10, 12, 14, 17, 20, 24, 27, 31, 34, 37, 40, 63

Raw values received so far. There only appear to be 5 bits available in the message unless I've missed something.

0, 4, 5, 7, 8, 10, 12, 15, 17, 20, 22, 24, 27, 28, 30,  31

So what I think we need is an operation that will map between those. 

The specs say the range of the 6045 is 25 miles or 40 KM.

With 5 bits there is enough to linearly represent 0-25 miles. However you'd need 6 bits for 0-40 KM without some sort of scaling.

The possible values from the AS3935 aren't linear. There are 4 that are spaced 2 KM apart, and 8 that are 3 KM apart.

Offline Dahc

  • Member
  • *
  • Posts: 2
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #21 on: July 14, 2020, 05:17:55 PM »
I'm wondering if it's a 4 bit counter rather than a 5 bit.

Code: [Select]
0   1   2   3   4   5   6   7   8
CI II  BB  HH  ST  TT  LL  DD  KK

Byte 7:

  Byte 7 - Edge of Storm Distance Approximation & other bits
  - Bits PLRDDDD?  (P = Parity, L = Strike LSB, S = Status, D = Distance, ? = ??)
  - 0x80 - even parity
  - 0x40 - LSB of 8 bit strike counter
  - 0x20 - RFI (radio frequency interference)
  - 0x1E - distance to edge of storm (theory)
  - 0x01 - ???

Code: [Select]
| Reading | Binary | Distance |
|---------|--------|--------|
| 0      | 0000   | 1        |
| 1      | 0001   | 3        |
| 2      | 0010   | 4        |
| 3      | 0011   | 5        |
| 4      | 0100   | 6        |
| 5      | 0101   | 7        |
| 6      | 0110   | 9        |
| 7      | 0111   | 11       |
| 8      | 1000   | 12       |
| 9      | 1001   | 14       |
| 10     | 1010   | 15       |
| 11     | 1011   | 17       |
| 12     | 1100   | 19       |
| 13     | 1101   | 21       |
| 14     | 1110   | 23       |
| 15     | 1111   | 25       |

Though if that were correct someone should have observed a 2 or a 3 with the existing code, so it's probably another dead end.

Offline rct

  • Senior Member
  • **
  • Posts: 98
  • W2RCT
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #22 on: July 14, 2020, 05:57:18 PM »
I'm wondering if it's a 4 bit counter rather than a 5 bit.

...SNIP...

Though if that were correct someone should have observed a 2 or a 3 with the existing code, so it's probably another dead end.


It isn't a counter.  According to the AS3935 datasheet there are only 16 possible values, so it could have fit into 4 bits, but that doesn't appear to me to be what Acurite chose to do.

See Statistical Distance Estimation (page 33) 

Note: That's actually a newer version (v5) of the datasheet than I had previously seen (v2?).  At some point I should look to see if the differences yield any new clues.

My guess is Acurite allocated 5 bits in the message to give enough room for 0-25 Mi. The Atlas lightning detector just sends plain miles in the message, no special coding.  The 6045 sends temperature in tenths of a degree Fahrenheit with an offset of 400 to avoid having to use a sign bit.

Judging by the title "Statistical Distance Estimation" the AS3935 wound up with the 14 different KM distance through some observation process, though they made it six bits and used KM so they could change the chip implementation without needing users to change their code. Someone at Acurite (or a subcontractor) needed to make that 6 bit value fit into 5 bits.  I think they tried to fit it to a curve but it seems kludgy to me. Or, I just haven't recognized something obvious that usually comes with successful reverse engineering.
« Last Edit: July 14, 2020, 06:08:03 PM by rct »

Offline Storm017

  • Senior Contributor
  • ****
  • Posts: 172
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #23 on: July 14, 2020, 07:14:05 PM »
This should be the latest datasheet (v1-04 2016-Jan-13).

Offline watsonm

  • Member
  • *
  • Posts: 38
Re: Receiving Acurite 6045M Lightning detector with rtl_433
« Reply #24 on: November 19, 2022, 07:27:02 AM »
I know its a long time ago but:

Revision 1.2
Quote
https://www.mouser.com/pdfdocs/AMS_AS3935_Datasheet_v4.pdf
Regards Mike

Raspberry Pi 4
Directly connected : BMP388 pressure sensor.  DHT22 For internal Humidity Sensor temp
Wireless connected: 3 Temperature Transmitters(WS2083), WH57  Lightning Sensor, Fine Offset Solar sensor  (stand alone)