Author Topic: New Acurite Lightning Detector  (Read 10890 times)

0 Members and 1 Guest are viewing this topic.

Offline n7qnm

  • Member
  • *
  • Posts: 3
Re: New Acurite Lightning Detector
« Reply #50 on: February 17, 2017, 10:24:13 PM »
3716 - a sticker on the lid of the battery compartment

Offline rct

  • Senior Member
  • **
  • Posts: 60
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #51 on: February 27, 2017, 06:52:47 PM »
The one which I used to implement the current experimental code in rtl_433, has a label QC 3016.  I suspected that the temperature sensor at a minimum might be bad. I got it during the (early?) summer, don't know if it's already out of warranty.   There is a bunch of things that seem to be erratic about it.  I had trouble nailing down which bit was battery low (or battery good).  I thought it's the LSB in the status byte.  It usually is on.   Turned off when the voltage was low, but then it stayed off for a while.  Didn't seem to behave sensibly. I eventually gave up on it.

Note: while a number of the other Acurite devices spit out JSON in rtl_433, the 6045M code still just outputs plain text.  including a dump of all bytes received since I never finishing figuring out the encoding.

Offline rct

  • Senior Member
  • **
  • Posts: 60
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #52 on: March 19, 2017, 05:12:28 PM »
A little bit of a status update for receiving the 06045 lightning sensor with rtl_433 (and an RTL-SDR).  Clay, N7QNM, motivated me enough to get my 06045 back out of the box and take another swing at figuring out the decoding.

I believe I've finally got the temperature figured out. There appears to be 12 bits for temperature.  The native units in the message appear to be in tenths of a degree Fahrenheit.   I've tested from around -2 F (freezer) to 90 F.

the rtl_433 output has changed slightly. Currently the output looks like this:

Code: [Select]
2016-10-24 18:48:12 Acurite lightning 0xE86F Ch B Msg Type 0x00: 74.1 F 43 % RH Strikes 5 Distance 0 L_status 0x02 - 80* e8 6f 2b 11 41 05 c0 19*
The changes in parsing are:
  • Temperature in Fahrenheit instead of Celsius.
  • The distance field is more reasonable but doesn't match the display.  I think 5 bits are used for distance.  0x1f (decimal 31) seems to be an invalid/undefined value.  This is the value when the sensor powers up.  I don't have a compatible display,  I could use some data from anyone who does with correlations between what rtl_433 is outputting and what the display shows.
  • New field "L_status", lightning/distance status bits that I haven't quite figured out yet.  The lower of the 2 bits (1) toggles on for interference / RF noise detected.
  • "Message Type" is just 2 status bits now that I've figured out the rest of those bits were temperature MSB.  The higher bit (2) seems to indicate the sensor is in active mode, transmitting every 8 sections instead of the regular 24.  I have not been able to get the lower bit (1) to be on.  My guess is this should be battery low if on (see below).

Has anyone that has the sensor with a compatible Acurite display ever seen it indicate low battery?    I've been trying to see which bit might indicate low battery, but I haven't seen anything so far.  I have it on a variable supply running at about 2.2 Vdc, just above where it will die from insufficient power. 

I still have to spend sometime digesting the data sheet that was posted in the tear down thread by George.

I put some documentation for the message format in the rtl_433 source code. (src/devices/acurite.c).



Offline rct

  • Senior Member
  • **
  • Posts: 60
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #53 on: April 07, 2017, 12:32:19 PM »
More on trying to decode the raw bytes from the lightning sensor with rtl_433:

Heads up - my assumption about the 2nd and 3rd bytes bytes being used for the sensor ID in the raw message might be wrong.  This might affect weewx-sdr users.

Generally, I've seen the 3rd byte as a fixed value of 0x6f.  I got a new sensor about a month ago.  The 3rd byte was a fixed 0xaf, which seemed to confirm that it is part of the ID.   However, I just noticed after 3-4 weeks that sensor started sending 0x6f instead of 0xaf.   Since it changed it's only been sending 0x6f.    I don't have any guesses/clues as to why it changed or what that byte/those bits might represent.  I don't think it is low battery, because I didn't see any change with a variable power supply.   

(You'll notice that two bits changed, 0xa = 0b1010 -> 0x6 = 0b0110.  This actually makes sense if this is one of the data bytes and not an ID byte, since data bytes are 7 bits and used the 8th for parity checking.  The ID bytes and checksum use all 8 bits, so no room for parity.)

I'm interested if you've seen an ID / 3rd byte value that isn't 0x6f.   I'm especially interested if you've seen it change and have any clues why.

Code: [Select]
2017-04-07 12:29:04 Acurite lightning 0xD56F Ch B Msg Type 0x00: 55.2 F 57 % RH Strikes 17 Distance 22 L_status 0x00 - 80* d5* 6f  39  90  84  11  96  b8

Offline mwall

  • Contributor
  • ***
  • Posts: 126
Re: New Acurite Lightning Detector
« Reply #54 on: April 07, 2017, 12:51:06 PM »
bob,

this is the output from one of my lightning sensors:
Code: [Select]
Acurite lightning 0x526F Ch A Msg Type 0x50: 112 C 48 % RH Strikes 1 Distance 81 - dd  52* 6f  30  50  f0  81  d1  60the 3rd byte has been 0x6f for as long as i've had the sensor (dec 2016).

i have an older sensor (aug 2016) at a different, remote location, but i have not been recording its output - it beeps all the time, even when there is no electrical activity.  acurite said it was defective.

m

Offline craigthom

  • Member
  • *
  • Posts: 8
    • My PWS
Re: New Acurite Lightning Detector
« Reply #55 on: April 10, 2017, 08:47:36 AM »
If it helps, this is the output from my lightning sensor.  I bought it week before last.

Code: [Select]
Acurite lightning 0x6FAF Ch A Msg Type 0x02: 65.1 F 42 % RH Strikes 32 Distance 12 L_status 0x02 - c0  6f  af  aa  50  e7  a0  cc  2b

Offline rct

  • Senior Member
  • **
  • Posts: 60
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #56 on: April 10, 2017, 09:05:20 AM »
the 3rd byte has been 0x6f for as long as i've had the sensor (dec 2016).

i have an older sensor (aug 2016) at a different, remote location, but i have not been recording its output - it beeps all the time, even when there is no electrical activity.  acurite said it was defective.

Matthew - Thanks for that data point. 

If it helps, this is the output from my lightning sensor.  I bought it week before last.

Code: [Select]
Acurite lightning 0x6FAF Ch A Msg Type 0x02: 65.1 F 42 % RH Strikes 32 Distance 12 L_status 0x02 - c0  6f  af  aa  50  e7  a0  cc  2b

Craig - Thanks -  that's interesting, another new, out-of-the-box sensor with the 0xaf value.  Let me know if that changes to 0x6f or anything else.   Wild guess - Maybe it's some sort of learning mode indicator.

--Rob

Offline craigthom

  • Member
  • *
  • Posts: 8
    • My PWS
Re: New Acurite Lightning Detector
« Reply #57 on: April 22, 2017, 12:54:07 AM »
Craig - Thanks -  that's interesting, another new, out-of-the-box sensor with the 0xaf value.  Let me know if that changes to 0x6f or anything else.   Wild guess - Maybe it's some sort of learning mode indicator.

--Rob

No change yet.  All the bytes after the af have changed, but I suppose the that's temp/humidity/strikes/distance data.

Offline rct

  • Senior Member
  • **
  • Posts: 60
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #58 on: April 23, 2017, 10:48:55 AM »
Thanks for the info Craig.  Yes, all the bytes after the 0x6f or 0xaf are data bytes.  src/devices/acurite.c has some docs.   I think it was 3-4 weeks before my sensor flipped from 0xaf to 0xaf.

Offline craigthom

  • Member
  • *
  • Posts: 8
    • My PWS
Re: New Acurite Lightning Detector
« Reply #59 on: January 03, 2018, 04:38:30 PM »
OK, I was getting low humidity readings from my lightning sensor, and it's cold, so I replaced the NiMH batteries with alkalines, and they weewx stopped recording it.

I checked, and, sure enough, that AF changed to a 6F, so what I'm now showing as sensor ID is 6F6F instead of 6FAF.  So maybe it took a power cycle to change.

Offline wcndave

  • Member
  • *
  • Posts: 45
Re: New Acurite Lightning Detector
« Reply #60 on: August 19, 2018, 06:04:23 PM »
Did you get anything going on this?  I have added 2 fields to record the data, however I can't make sense of them, nor be sure how to get weewx to use them.

in my sensor map I have

      lightning_strikes  = strikes_total.002D.AcuriteLightningPacket  ## lightning detector
      lightning_distance = distance.002D.AcuriteLightningPacket

Which record data:

sqlite> SELECT datetime(dateTime, 'unixepoch', 'localtime') , round(lightning_strikes,1) as strikes, round(lightning_distance,1) as distance from archive order by dateTime desc limit 20;                                                      datetime(dateTime, 'unixepoch', 'localtime')  strikes     distance
--------------------------------------------  ----------  ----------
2018-08-20 00:00:00                           12.0        2.0
2018-08-19 23:55:00                           11.1        8.3
2018-08-19 23:50:00                           10.6        7.0
2018-08-19 23:45:00                           10.0        7.0
2018-08-19 23:40:00                           10.0        7.0
2018-08-19 23:35:00                           9.5         5.0
2018-08-19 23:30:00                           7.0         0.0
2018-08-19 22:25:00                           111.0       24.0
2018-08-19 22:20:00                           111.0       24.0
2018-08-19 22:15:00                           111.0       24.0
2018-08-19 22:10:00                           111.0       24.0
2018-08-19 22:05:00                           111.0       24.0
2018-08-19 22:00:00                           111.0       24.0
2018-08-19 21:55:00                           111.0       24.0
2018-08-19 21:50:00                           111.0       24.0
2018-08-19 21:45:00                           111.0       24.0
2018-08-19 21:40:00                           111.0       24.0
2018-08-19 21:35:00                           111.0       24.0
2018-08-19 21:30:00                           111.0       24.0
2018-08-19 21:25:00                           111.0       24.0

and my console says:

73 strikes in 48 hours last one at 1km.

I'm not sure how I use the DB data to drive any kind of displayed information...

Hope you're still into this topic!

Dave

Offline rct

  • Senior Member
  • **
  • Posts: 60
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #61 on: August 19, 2018, 06:28:02 PM »
Do you happen to have the rtl_433 output logged?

I'm not using Weewx, so I'm making some guesses from the 5 minute output.  Also, while I have the sensor, I don't have the console, so I've made some guesses.

In the message from the sensor, the strike count is a 7 bit persistent counter, this means it counts from 0-127 then wraps around again.

Between 2018-08-19 22:25:00 and 2018-08-19 23:30:00  the database is showing the strike counter went from 111 to 7.  I'm interpreting that as the senor recorded 28 strikes during that 5 minute interval. The counter would have gone from 112 to 127, then 0 to 12.

It's possible some consolidation function should be used in weewx to handle the counter and turn it into something that increases monotonically as part of storing it in the database.

I have no idea on what the scaling function should be for the distance.  5 bits are available.  0x1f (31) seems to be invalid (what the device powers up as). so values are 0-30.  I haven't been able to get enough observations from people with consoles to have a shot at figuring out the formula.

The distance is an approximation by the sensor of what it things the leading edge of the storm is.  Seems like it calculated the storm as moving away.  I think one of the not fully understood status bits indicates validity of the distance calculation.

If possible save the message output from rtl_433 for the lightning sensors for us to have a better shot at figuring things out.

Offline craigthom

  • Member
  • *
  • Posts: 8
    • My PWS
Re: New Acurite Lightning Detector
« Reply #62 on: August 19, 2018, 07:47:14 PM »
Did you get anything going on this?  I have added 2 fields to record the data, however I can't make sense of them, nor be sure how to get weewx to use them.

in my sensor map I have ...

I think this is more of a WeeWX issue, but here's what I discovered a year or so ago when I was messing with this.

The value for lightning strikes is, as noted, a total count in seven bits, so it wraps from 127 to 0.  That's from the sensor.  If the value is the same in consecutive records there were no strikes during that loop interval.

If you put an entry in the [[deltas]] section of the [SDR] driver config that's something like this

Code: [Select]
[sdr]
...
    [[deltas]]
        lightningStrikes = lightningStrikesTotal

you'll get just the number of strikes, not the internal running total.

But that just gives you the lightning strikes per packet received.  Each packet will have a new value, and there are dozens of packets during the loop time before weewx writes to the database.

By default, for things it doesn't already know about, weewx averages the values received by packets, so you won't get the total lightning strikes for the reporting interval (usually five minutes) but an average of the strikes per packet.

To fix this you'll need to add or edit the Accumulator top level section in weewx.conf.  I added it at the very end.

Code: [Select]
[Accumulator]
    [[lightningStrikes]]
        extractor = sum
    [[lightningDistance]]
       extractor = min

The distance extractor gives you the closest lightning strike during the interval.  Without it it averages the values, so if you get two with a distance of 1 and eight with a distance of 20, you'd end up with a value of 18 or so.  I want to record the smallest distance during the interval, not the average.  If you want the average you can leave that out.

The "min" only works for weewx 3.7.2 or later.  I got Tom to add it for this very reason.

I haven't looked at this in a year, but I got those lines from my weewx.conf.
« Last Edit: August 19, 2018, 07:49:23 PM by craigthom »

Offline wcndave

  • Member
  • *
  • Posts: 45
Re: New Acurite Lightning Detector
« Reply #63 on: August 20, 2018, 12:07:08 PM »
Thank you both.

I had no idea about the [[deltas]] and [[accumulators]] sections, there is no mention of them at all in the weewx documentation....

Given that, how does this work: lightningStrikes = lightningStrikesTotal

Is the word Total at the end a reserved keyword that does something special?

I see that the detector does up to 25miles, and I have no values above 24 in the database.
I wondered if that would mean that it was 0 to 24 miles, or perhaps 0 is up to 1 mile etc...

However it currently is reporting the value 4, and saying 5km on the display...

Also there's some very odd precision patterns, it seems to either give a round number, or something to 13 decimal places!

| 2018-08-19 22:25:00     |                        111 |                 24 |
| 2018-08-19 23:30:00     |                          7 |                  0 |
| 2018-08-19 23:35:00     |                          9 |   5.00917431192661 |
| 2018-08-19 23:40:00     |                         10 |                  7 |
| 2018-08-19 23:45:00     |                         10 |                  7 |
| 2018-08-19 23:50:00     |                         11 |                  7 |
| 2018-08-19 23:55:00     |                         11 |   8.31775700934579 |
| 2018-08-20 00:00:00     |                         12 |    1.9811320754717 |
| 2018-08-20 00:05:00     |                         12 |                  0 |
| 2018-08-20 00:10:00     |                         12 |                  0 |
| 2018-08-20 00:15:00     |                         12 |  0.685714285714286 |
| 2018-08-20 00:20:00     |                         13 |                 24 |
| 2018-08-20 00:25:00     |                         13 |                 24 |
| 2018-08-20 00:30:00     |                         13 |   12.3243243243243 |
| 2018-08-20 00:35:00     |                         14 |                 12 |
| 2018-08-20 00:40:00     |                         14 |                 12 |
| 2018-08-20 00:45:00     |                         14 |                 12 |
| 2018-08-20 00:50:00     |                         14 |                 12 |
| 2018-08-20 00:55:00     |                         15 |   11.5675675675676 |
| 2018-08-20 01:00:00     |                         15 |                  4 |
| 2018-08-20 01:05:00     |                         16 |                  4 |
| 2018-08-20 01:10:00     |                         17 |                  4 |

My data doesn't yet go back 48 hours, so I will see tonight if the counter part is correct, it says 80 strikes now, and since my first reading 43 hours ago the database shows an increase of 39 (once reset at 127), so we've had a lot of storms, and I can't recall if we had 40 odd strikes 2 days ago....

I do have debug on, so I probably have all the raw data in some form or another, will try and dig it out of the log files.

Thanks again for all the help.

Dave

Offline craigthom

  • Member
  • *
  • Posts: 8
    • My PWS
Re: New Acurite Lightning Detector
« Reply #64 on: August 20, 2018, 12:31:08 PM »
Until you've added the [[deltas]] section your lightning strikes won't be a count; it will be an average of the values sent during that reporting interval. 

The strikestotal is the value read from the packet.  It's an intermediate value and is just the rolling count from the sensor.  The deltas changes that to the change since the last time, and the accumulator totals all the deltas for the interval.

Offline rct

  • Senior Member
  • **
  • Posts: 60
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #65 on: August 20, 2018, 01:24:44 PM »
@wcndave - Since you have the right Acurite console, I'd be very interested in try to get correlations between your display and the raw messages from rtl_433. 

Due to the aggregation, the database records aren't very useful.  They should be closer once WeeWX is no longer averaging, but there is a lot that can happen in 5 minutes or whatever the interval is.

Hopefully the strike count in WeeWX and the console will match up correctly.  I think that should be straightforward so I'd be surprised if it was being misinterpreted.

Right now I think storm distance is the biggest question.   

The observation that should be easiest to make and hopefully the most reliable is after each storm when things are no longer changing -- What does the display say for distance and what is the raw value from the sensor?  Hopefully we can collect a table of values that

(Actually if there are no changes during the 5 minute interval the database could be used.)

Offline wcndave

  • Member
  • *
  • Posts: 45
Re: New Acurite Lightning Detector
« Reply #66 on: August 20, 2018, 02:52:58 PM »
The strikestotal is the value read from the packet.  It's an intermediate value and is just the rolling count from the sensor.  The deltas changes that to the change since the last time, and the accumulator totals all the deltas for the interval.

So, I get the premise behind it, however not how the naming convention works.  E.g. yesterday I was told to use "rain_total" instead of "rain", even though rain_total is nowhere in all the documentation.... so how was I supposed to know!?

I have this now:

Code: [Select]
   [[sensor_map]]
      lightning_strikes  = strikes_total.002D.AcuriteLightningPacket  ## lightning detector
      lightning_distance = distance.002D.AcuriteLightningPacket

where lightning_strikes and lightning_distance are the names of the fields in my db, as for some reason they don't exist in the default weather db schema.

I have now added to the end of the SDR section:

Code: [Select]
   [[deltas]]
      lightning_strikes = lightning_strikesTotal

However I don't just see why I wouldn't add the "lightning_strikes" to deltas, to tell the system I want deltas for this value.
Why does it get assigned the value of another field (lightning_strikesTotal), and how was that name arrived at?

Then, outside the SDR section, I have

Code: [Select]
[Accumulator]
   [[lightning_strikes]]
      extractor = sum
   [[lightning_distance]]
      extractor = min

but, I am not sure how this can work.

Apologies if I am being dense, I think the lack of documentation doesn't help!

If I understand, delta means the difference between the value and the previous value received from the sensor

So if I got

10 -> stored in db
10
14
17 -> stored in db as delta=3

when it should be 7

However, if I do the sum, I would get this scenario

10 -> stored in db
10 - sum = 20
14 - sum = 34
17 - sum = 51 -> stored in db as 51-34 = 17

which is also wrong.

Also, when I might get 10 readings in one interval, and 11 readings in another, the sum will be wrong quite often.

Yet, you say this is working for you, so I am not sure what I'm not understanding.

Apologies again if I'm just being thick!


Offline wcndave

  • Member
  • *
  • Posts: 45
Re: New Acurite Lightning Detector
« Reply #67 on: August 20, 2018, 04:31:16 PM »
Right, I saw a post from you on the google group, which I think answers my own questions.

I want:

Code: [Select]
lightning_strikes_total  = strikes_total.002D.AcuriteLightningPacket  ## lightning detectorwhich assigns the running total to lightning_strikes_total

Code: [Select]
[[deltas]]
      lightning_strikes = lightning_strikes_total

which says that the variable lightning_strikes is the delta value of lightning_strikes_total

Code: [Select]
[Accumulator]
   [[lightning_strikes]]
      extractor = sum

which says to sum all those deltas

so my example now would be

10 -> stored in db
10 delta = 0
14 delta = 4
17 delta = 3 -> stored in db as sum of deltas 7

I think that's it now, will check during the next week or so I guess.

Offline craigthom

  • Member
  • *
  • Posts: 8
    • My PWS
Re: New Acurite Lightning Detector
« Reply #68 on: August 20, 2018, 06:09:50 PM »
That's pretty much it.  You'll get a lot more than three packets in a five minute interval, though.  There's no way of knowing how many, though, so what's important is how many you get in the reporting interval (five minutes by default).

I use the naming convention lightningStrikesTotal, which matches that used in the existing weewx db schema. 

Matt suggested (and I used) the "Total" for the value from the sensor because it's the running of all time strikes modulo 128 received since the last time the sensor was reset (the same way the rain sensor works as a tip counter).  This number is useless if not compared to previous values.

The weewx Google groups are great for this kind of thing.  My guess is that there are only a handful of us using the lightning sensor with weewx.

Offline wcndave

  • Member
  • *
  • Posts: 45
Re: New Acurite Lightning Detector
« Reply #69 on: August 20, 2018, 08:15:13 PM »
That's pretty much it.  You'll get a lot more than three packets in a five minute interval, though.  There's no way of knowing how many, though, so what's important is how many you get in the reporting interval (five minutes by default).
Yes, it was just a theoretical example.

I use the naming convention lightningStrikesTotal, which matches that used in the existing weewx db schema. 

Again, in the documentation I saw nothing about lightning, there's not a single mention of it.  Not sure how we're supposed to know what to use.
In the default (wview I guess) schema, there's not lightning fields....


Matt suggested (and I used) the "Total" for the value from the sensor because it's the running of all time strikes modulo 128 received since the last time the sensor was reset (the same way the rain sensor works as a tip counter).  This number is useless if not compared to previous values.
BTW: what happens when you do the delta when it wraps around? Do you just accept that one time the value will be wrong?



So, a further test, as we just had another nice storm.

I looked at the logs, and assuming the data which reads "lines=" is the data from the sensor, and "packet=" is the data used by weewx, the following occurred.

(I have all the log data if any further analysis is required)

* whatever the 433 read, was recorded in db, bar one missing strike number.
* the 433 was getting data every 20 seconds, I don't think anything was missed, and as it's a running total, it would be picked up anyway...
* most interesting, the strike_total that the 433 read and weewx stored in db went up from 17 to 46 (29 strikes), however, the console went from 82 to 121 (39) not accounting for strikes that fell off the 48 hour window.

So, the data from the sensor looks to be out, by quite a long way.

Offline rct

  • Senior Member
  • **
  • Posts: 60
  • W2RCT
Re: New Acurite Lightning Detector
« Reply #70 on: August 24, 2018, 09:34:22 AM »

* whatever the 433 read, was recorded in db, bar one missing strike number.
* the 433 was getting data every 20 seconds, I don't think anything was missed, and as it's a running total, it would be picked up anyway...
* most interesting, the strike_total that the 433 read and weewx stored in db went up from 17 to 46 (29 strikes), however, the console went from 82 to 121 (39) not accounting for strikes that fell off the 48 hour window.

So, the data from the sensor looks to be out, by quite a long way.

During a storm the 6045 should be transmitting every 8 seconds.  It should be in "active" mode.  When not in active mode it transmit around every 24 seconds.

Yes the strike_count as seen by the sensor is a counter so it's a running total.

Without the console, the strike count as seen in the raw message seems pretty reasonable.  I can cause false strikes with RFI or things that arc (like putting it near a switch or an electric igniter).

If the values the console reports are really that much higher then the console might be counting strikes when ever *either* the strike count changes or the distance estimate changes.  While that's plausible it seems like double counting (and why have a strike counter?).


Offline wcndave

  • Member
  • *
  • Posts: 45
Re: New Acurite Lightning Detector
« Reply #71 on: August 28, 2018, 04:54:27 AM »
So, it could be that the sensor is sending "last 7 days" or something, which means the count of strikes doesn't increase as much as the actual strikes, however that seems unlikely.

Also, there could be something wrong in the 433 translation of the message to the data.

Here's what I have from 433 for distance, number strikes, and then what the screen said.
I switched from km to miles at one point to see if there was any correlation between the number and miles that was more obvious.

It's not.  You get the distance in miles by dividing the read sensor value by 1.4
Approx.
Like, sometimes it's 1.36, and sometimes 1.44, however if you ROUND the number, it's always what you see on screen.

Also, there are rare, but occurring instances where the distance is not a whole number.

Perhaps you have some other interpretation.

select distinct(round(lightning_distance,2)) as dist, count(round(lightning_distance,2)) as num from archive group by dist order by dist

               ON CONSOLE         DERIVED         
   dist      num      Miles      KM      /1.4 to get miles      KM   
   0      7      0      1      0.0      0.0   
   0.69      1      0      0      0.5      0.8   
   1.98      1      0      0      1.4      2.3   
   4      292      3      5      2.9      4.6   
   5      15      0      6      3.6      5.7   
   5.01      1      0      0      3.6      5.7   
   7      18      5      8      5.0      8.0   
   8      19      6      0      5.7      9.1   
   8.32      1      0      0      5.9      9.5   
   9.61      1      0      0      6.9      11.0   
   10      190      7      0      7.1      11.4   
   11.13      1      0      0      8.0      12.7   
   11.57      1      0      0      8.3      13.2   
   12      290      9      0      8.6      13.7   
   12.32      1      0      0      8.8      14.1   
   15      345      11      0      10.7      17.1   
   17      49      12      0      12.1      19.4   
   20      3      0      0      14.3      22.9   
   21.33      1      0      0      15.2      24.4   
   22      180      0      0      15.7      25.1   
   24      276      0      0      17.1      27.4   
   28      1      23      0      20       32   

Any missing on console screen values are where I've not been able to catch the screen at the right time.
« Last Edit: September 09, 2018, 11:25:48 AM by wcndave »

Offline wcndave

  • Member
  • *
  • Posts: 45
Re: New Acurite Lightning Detector
« Reply #72 on: August 29, 2018, 09:44:14 AM »
OK, that 1.4 theory goes out the window.  Just had a strike reported as 23 miles on console, and value sent by rtl_433 was 28...

Offline falkyre

  • Member
  • *
  • Posts: 1
Re: New Acurite Lightning Detector
« Reply #73 on: August 29, 2018, 09:27:40 PM »
So I found some C++ code that takes what's in the register in the AS3935 chip for distance of a lightning strike.  It's all in kilometers so you'll have to do your own calculations to get miles.  I'm guessing the 28 that is returned in the data stream is the HEX value in the register.  If so, the values break down as follows:

case 0x28:
         km = 40;
         break;
      case 0x25:
         km = 37;
         break;
      case 0x22:
         km = 34;
         break;
      case 0x1F:
         km = 31;
         break;
      case 0x1B:
         km = 27;
         break;
      case 0x18:
         km = 24;
         break;
      case 0x14:
         km = 20;
         break;
      case 0x11:
         km = 17;
         break;
      case 0x0E:
         km = 14;
         break;
      case 0x0C:
         km = 12;
         break;
      case 0x0A:
         km = 10;
         break;
      case 0x08:
         km = 8;
         break;
      case 0x06:
         km = 6;
         break;
      case 0x05:
         km = 5;
         break;
      case 0x01:
         km = 0;

Hopefully that helps.  I haven't got around to getting this setup in weewx yet.  I've missed my storm season as I have a bunch of projects on the go that never seem to get done in time.

Here's the Spec sheet from Mouser:

https://www.mouser.com/ds/2/588/ams_AS3935_Datasheet_EN_v5-1214568.pdf

Look at the chapter on Statistical Distance Estimation

I'm not sure how the acurite lightning detector is using this data to send out to it's console
« Last Edit: August 30, 2018, 03:24:59 PM by falkyre »

Offline Storm017

  • Member
  • *
  • Posts: 17
Re: New Acurite Lightning Detector
« Reply #74 on: September 02, 2018, 11:27:31 PM »
@RCT.....Now I have two 06045s with one talking with a Console.  Planning to provide all the raw data from both 06045s (8 or 24 seconds) during storms.  And if everything works out, just the data for every strike during a storm that the 06045s detected.  Also,  in the process of integrating stand alone AS3935 sensor board into my system. Once integrated will supply that data.  Just waiting for those storms to come through.