WXforum.net
Weather Station Hardware => AcuRite Weather Stations => Topic started by: nincehelser on August 16, 2016, 09:17:30 PM
-
https://www.acurite.com/lightning-detector-with-temperature-and-humidity.html#"
It's not AcuLink compatible, but I imagine that might be coming. It would be cool if it could gauge electrical storm intensity and let me know when it's a good time to go photograph lightning.
[ You are not allowed to view attachments ]
-
I've got one. I bought only the sensor to play with. I didn't get the console. So I'm working a little blind with it. It has tripped and beeped for thunderstorms.
Anyone else have one?
As the manual states, it's sensitive to RF. Place it too close to something that emits a bit of RF, like right next the laptop, and it will trip into lightning mode as well as give an interference warning.
I'm working on adding support into rtl_433 for this. It's similar to the tower sensor and the 5n1 that I've worked on. I think I've worked out the ID, the humidity byte, the number of lightning strikes recorded so far. However, I can't find a sensible representation of temperature in the message, so far. I'm starting to wonder if it is possible that I got a unit with a defective temperature sensor.
I'd love to hear from anyone else who has one and has a rtl-sdr stick setup for rtl_433.
-
I've got one. I bought only the sensor to play with. I didn't get the console. So I'm working a little blind with it. It has tripped and beeped for thunderstorms.
Anyone else have one?
As the manual states, it's sensitive to RF. Place it too close to something that emits a bit of RF, like right next the laptop, and it will trip into lightning mode as well as give an interference warning.
I'm working on adding support into rtl_433 for this. It's similar to the tower sensor and the 5n1 that I've worked on. I think I've worked out the ID, the humidity byte, the number of lightning strikes recorded so far. However, I can't find a sensible representation of temperature in the message, so far. I'm starting to wonder if it is possible that I got a unit with a defective temperature sensor.
I'd love to hear from anyone else who has one and has a rtl-sdr stick setup for rtl_433.
I'll happily buy one and help try to decode, if you give me some hints in decoding. :grin: I have an rtl-sdr and would love to decode the Acurite BBQ thermometer. Learning how to decode the lightning sensor might help me out in the long run! I'd love to see rtl_433 be able to decode the full suite of Acurite stuff.
-
Right now rtl_433 decodes these acurite devices that I have:
- The 5-n-1 weather station
- 592TXR "Tower" Temperature/Humidity Sensor
- 609TXC Temperature and Humidity Sensor
- Acurite 986 Refrigerator / Freezer Thermometer
rtl_433 should also handle the 896 rain gauge, and the 606Tx temperature sensor but I have no direct experience with this.
2016-09-30 23:34:49 Acurite 5n1 sensor 0x0832 Ch A, Msg 31, Wind 18 kmph / 11.2 mph 45.0° NE (12), rain gauge 0.46 in.
2016-09-30 23:35:08 Acurite 5n1 sensor 0x0832 Ch A, Msg 38, Wind 25 kmph / 15.5 mph, 15.2 C 59.4 F 94 % RH
2016-09-30 23:35:17 Acurite tower sensor 0x2F15 Ch C: 18.5 C 65.3 F 75 % RH
2016-09-30 23:35:22 Acurite tower sensor 0x269C Ch B: 19.4 C 66.9 F 69 % RH
Currently my decoding for the lightning sensor looks like this:
2016-09-30 23:35:05 Acurite lightning 0x976F Ch B Msg Type 0x10: 856.7 C 1574.1 F 75 % RH - 80 97 6f 4b 90 ca 5f 0a 94
My guess at the format so far:
- I haven't been able to figure out where temperature is
- The first 3 bytes have the channel number, and ID
- Humidity is in the 4th byte, 0x4b = 75
- Status or message type appears to be a bit mask in the 5th byte.
- I don't know what the 6th byte represents yet
- The 7th byte is the number of lightning strikes detected. I'm currently not printing that yet. It's a 7 bit counter. Parity is used as in the other acurite messages.
- I think the 8th byte might be estimated distance for the last lightning strike, but I'm guessing
- The final byte is a simple checksum, which is working correctly.
The code for rtl_433 is on github https://github.com/merbanan/rtl_433 (https://github.com/merbanan/rtl_433). In the README on that page you can see the list of devices that are currently being decoded. I haven't submitted my code for the lightning detector yet since it's still experimental.
There is a repository of recorded signals for testing. https://github.com/merbanan/rtl_433_tests (https://github.com/merbanan/rtl_433_tests) I'll add some samples from my lightning detector soon.
There is a Google Group for rtl_433, it's very low traffic these days https://groups.google.com/forum/#!forum/rtl_433 (https://groups.google.com/forum/#!forum/rtl_433)
I'd be happy to give some hints/help with the BBQ thermometer. I don't own one. Is it worth getting? First step would be to get some recorded signals with as much info as to what should be in them (in other words, what's the reading on the display when the signal is captured.)
The code is easiest to build on a Linux box, It runs pretty well on a RPi these days. It does build on windows but I'm not sure what the process is for building it. There is also a guy who periodically provides windows builds via his blog http://cognito.me.uk/computers/rtl_433-windows-binary-32-bit/ (http://cognito.me.uk/computers/rtl_433-windows-binary-32-bit/). The links in the blog post haven't been updated check http://cognito.me.uk/uploads/rtl433/ (http://cognito.me.uk/uploads/rtl433/) to see the files and the dates 32 bit: http://cognito.me.uk/uploads/rtl433/rtl433_win32_daily.zip (http://cognito.me.uk/uploads/rtl433/rtl433_win32_daily.zip) 64 bit: http://cognito.me.uk/uploads/rtl433/rtl433_win64_daily.zip (http://cognito.me.uk/uploads/rtl433/rtl433_win64_daily.zip)
-
Thanks rct! I do have rtl_433 running on a RasPi. I have so many 433mhz devices that I have to remove the antenna (leaving the base attached of course) and place the desired device next to it just to isolate the signal. But I've yet to try my hand at decoding.
I'll order the lightning sensor and get some data to you once I have it. I also have the Room Monitor, outdoor temp/hum, leak detector, soil probe - all in need of decoding!
As for the BBQ unit - I'm not even sure it broadcasts the temperature. The receiver is just a pager for near-done and done alerts. I really want a 4+ probe BBQ monitor. I've looked at the lot of homebrew and commercial solutions, none are quite what I want. That being easy/cheap to replace probes, and clearly parseable data. Most are Bluetooth, or cloud only, or proprietary probes, or some combo. If the Acurite does xmit temp data it would be ideal since the "per probe" cost is cheap, though having 4 LCD units near my smoker would take up a bit of space!
-
I use this in my smokers: http://www.aginova.com/store/icelsius_wireless_bbq_dual Nice unit.
-
Thanks rct! I do have rtl_433 running on a RasPi. I have so many 433mhz devices that I have to remove the antenna (leaving the base attached of course) and place the desired device next to it just to isolate the signal. But I've yet to try my hand at decoding.
I'll order the lightning sensor and get some data to you once I have it. I also have the Room Monitor, outdoor temp/hum, leak detector, soil probe - all in need of decoding!
Ok, you win, you've got more devices then I do. Would really like to see some sample signals from all of those other devices. Removing the antenna to help isolate seems like a reasonable solution. Hopefully having it so close won't distort the signal/overload the receiver. Note: You might wind up needing to tweak the pulse widths a little bit once you've got the antenna reconnected and have the sensor placed away from the receiver.
What I do which isn't automated is I record for a while with rtl_433 -p NN -a -t. Then I run through the captured files with a for loop and send the output to a file. Then I review the output looking to see what files didn't decode / might have the new device of interest. So I do something like this:
for f in gfile*data; do echo ============ $F ============; rtl_433 -q -l 0 -r $f;echo " "; echo " ";done > /tmp/out.txt 2>&1
-
I can certainly provide data from the other sensors. They should be easier to decode since they are now decoded by the bridge and I'm capturing that traffic as well.
For whatever reason I never got rtl_433 working on my original RasPi. (it compiled/installed and runs, but never picks up any signals) Works fine on my RasPi2. I have some stuff to move off of that and I want to do a clean install, then I can get some data.
Maybe we should move to a new thread, apart from lightning sensor details?
-
I use this in my smokers: http://www.aginova.com/store/icelsius_wireless_bbq_dual Nice unit.
Thanks! I'll check that out!
-
I can certainly provide data from the other sensors. They should be easier to decode since they are now decoded by the bridge and I'm capturing that traffic as well.
Great that should make it easier.
For whatever reason I never got rtl_433 working on my original RasPi. (it compiled/installed and runs, but never picks up any signals) Works fine on my RasPi2. I have some stuff to move off of that and I want to do a clean install, then I can get some data.
Maybe we should move to a new thread, apart from lightning sensor details?
Sure, I'm happy to move the RTL-SDR discussion where you think is appropriate. I'm new to this forum. If you think there should be a new topic or category, I'd be happy to participate here or on the rtl_433 google group. Just let me know what you decide.
To respond to your RPi 1 vs. RPi 2 issue, the first thing that comes to mind is power, The sticks with the R820T tuner consume a pretty good amount of power, ~350 ma, if you touch them they feel warm. The original RPi's could be problematic when it comes to power. Also it helps to use a USB extension cable to get the radio and the antenna away from any noise generated by the RPi. I've got RTL sticks running successfully on both an original (1st generation) RPi and a RPi 2. You didn't mention if you are using the same stick on the two devices or two different ones. I recommend figuring out what the tuning error is. I've got some that are as far off as +/- 70 ppm. That's 30 khz. At the default rtl_433 sample rate of 250 Khz, that leaves on 125 khz of bandwidth on either side of the center frequency.
-
FYI - my preliminary decoding of the lightning detector is now merged into the main rtl_433 repo. So do a git pull and rebuild. https://github.com/merbanan/rtl_433 (https://github.com/merbanan/rtl_433)
-
Unfortunately it might be a couple of weeks before I can start playing around. But yeah maybe we can start up a new thread just so folks looking for lighting detector info aren't confused by our 433mhz talk. :-P There's some good info in your posts however, wondering if mod could move them to a new thread?
-
I don't have a lightning sensor yet, but I do have all the parts lying around for setting up a 433_RTL setup on a Pi.
It would be nice if someone could post a "quickstart" tutorial on getting things set up and running. It might get me motivated.
:-P
-
This is a good place to start: https://cdn-learn.adafruit.com/downloads/pdf/freq-show-raspberry-pi-rtl-sdr-scanner.pdf
-
This is a good place to start: https://cdn-learn.adafruit.com/downloads/pdf/freq-show-raspberry-pi-rtl-sdr-scanner.pdf
Thanks, but I was thinking more of the RTL_433 specific stuff.
-
OK. I've got it installed and initially running.
Here are my notes for compiling and installing. Use them at your peril... There could be typos or I could have forgotten something.
Problem: you have to be root or use sudo to execute the final rtl_433 command. I thought I compiled with what I needed for a non-root user to run it, but apparently not.
Assumptions: Fresh installation of Raspbian Jessie
Install some packages we'll need:
$sudo apt-get install git
$sudo apt-get install cmake
$sudo apt-get install libusb-1.0-0-dev
Make a directory for a local git repository, then clone the source code we need:
$mkdir git
$cd git
$git clone git://github.com/merbanan/rtl_433
$git clone git://git.osmocom.org/rtl-sdr.git
Compile and install rtl-sdr:
$cd rtl-sdr
$mkdir build
$cd build
$cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON
$make
$sudo make install
$sudo ldconfig
Switch to the rtl_433 directory and compile and install.
$cd ..
$cd ..
$cd rtl_433
$mkdir build
$cd build
$cmake ../
$make
$sudo make install
Go to your home directory and do an initial test:
$cd ~
$sudo rtl_433 -G
I'm getting data... more than I expected, though. I see my 5n1, but I also seem to be getting a lot of data from a "Danfoss CFR Thermostat". Must be from a neighbor...
-
And here I was trying not to hijack George's lighting thread with 433 noise. :grin: Ah well. That looks about right to me, though there's a slightly later version of libusb at libusb.info. The only other thing I had to do on my RasPi was disable the auto loading of some other devices such that detection of the rtl-sdr survives a reboot:
create /etc/modprodbe.d/no-rtl.conf :
blacklist dvb_usb_rtl28xxu
blacklist rtl2832
blacklist rtl2830
Indeed it picks up a lot of stuff, amazing how much is in this frequency range!
-
Here's the hardware I'm using in case someone wants to pick up something they know will work:
https://www.amazon.com/gp/product/B009U7WZCA
[ You are not allowed to view attachments ]
-
OK. Here's a question about RTL_433.
If I specify protocol 09, I just see my 5n1 data, nice and simple.
However, if I specify protocol 39, which includes the lighting sensor, the 5n1 data is repeated 3 times.
Is that because the 5n1 is actually transmitting the data 3 times, or is it something with how the program is decoding the data?
-
OK. Here's a question about RTL_433.
If I specify protocol 09, I just see my 5n1 data, nice and simple.
However, if I specify protocol 39, which includes the lighting sensor, the 5n1 data is repeated 3 times.
Is that because the 5n1 is actually transmitting the data 3 times, or is it something with how the program is decoding the data?
i see the same behavior. have not had time to track down the source, so for now i made the weewx-sdr driver drop duplicate packets.
https://github.com/matthewwall/weewx-sdr
m
-
If anyone here wants to create an rtl_433 topic (or group) Just let us know and I will gladly respond there. For what it's worth, rtl_433 handles more than Acurite devices. I use it with Acurite, LaCrosse, and DSC security devices. (There is also support for a number of weather devices from other manufacturers as well as many non-weather devices.)
OK. Here's a question about RTL_433.
If I specify protocol 09, I just see my 5n1 data, nice and simple.
However, if I specify protocol 39, which includes the lighting sensor, the 5n1 data is repeated 3 times.
Is that because the 5n1 is actually transmitting the data 3 times, or is it something with how the program is decoding the data?
Yes, that was intentional. First let me point out that protocol 39, (-R 39) handles the tower sensor, the 5-n-1, and lightning detector. (The lightning detector support is still very preliminary.)
Be aware that there is a difference in wind direction interpretation between the original protocol 9 implementation, and my re-implementation. Protocol 9 does a straight circular mapping. Some people seem to feel that is correct. Protocol 39 does a mapping using a modified gray code that matches the old aculink reporting and my 01512 display. I believe some of the aculink parsers (ipwx, haculink, etc.) went through the same discovery process. I don't know if there are two versions of the 5-n-1, or if the people who feel the original circular mapping is correct just haven't noticed.
Also, at times I've been suspicious that the wind speed formula is incorrect. I haven't had a chance to do a good comparison now that my aculink has been migration to a smartHub to see if it is off, or it's a difference in averaging/smoothing. Currently both decoders use the same code.
Regarding suppressing duplicate messages: The Acurite devices send the message multiple times in each message burst. In a number of cases, the received signal strength indicator on acurite gear is not the actual signal level, or signal-to-noise ratio, but is an attempt indication of quality judging by the number of times the message was heard. Note: IIRC, Protocol 9 will suppress duplicates, but assumes that only a single 5-n-1 will ever be heard.
I, and many others, running rtl_433 take the output of rtl_433 and pipe it into the something else to deal with storage, graphing, alerting, etc. At this point my primary storage and graphing is RRDtool. I've been thinking I should look into replacing or agumenting that with WeeWx, or something else, but I haven't done any research yet.
The consensus at this point is that rtl_433 should generally be handling the radio, demodulation, and decoding. It's up to the consumers of the data to figure out if they want to suppress duplicates, or count them, do unit conversions, averaging, smoothing, etc. Many of the newer decoders output structured data in your choice of CSV, JSON, or key-value pairs, and don't do duplicate suppression. Some of the old decoders, would print the first message received, and ignore others received at the same time assuming those were duplicates. With some of the protocols, there isn't enough error detection to be confident that a message has been correctly decoded.
Hope this helps,
--Rob
-
i see the same behavior. have not had time to track down the source, so for now i made the weewx-sdr driver drop duplicate packets.
https://github.com/matthewwall/weewx-sdr
m
@mwall:
Cool. Thanks for that. I wasn't aware there was a weewx driver for rtl_433 yet. I'll have to check that out.
I'll give you a heads up if I change any of the Acurite code. Are you watching the merbanan/rtl_433 github repo for changes? I hope the structured data conversion doesn't cause too much churn with your code. Unfortunately there aren't releases yet that could say you support. Hopefully that will happen soon.
Also if you haven't you might want to join the rtl_433 google group. The traffic is pretty low.
-
Here's the hardware I'm using in case someone wants to pick up something they know will work:
https://www.amazon.com/gp/product/B009U7WZCA
[ You are not allowed to view attachments ]
For rtl_433, any of these NooElec, or RTL-SDR blog units should be fine. I'm using two of the NooElec units for rtl_433.
If you haven't bought one yet, and think you'd might use it for other stuff too, I'd recommend one of the units with an SMA connector and a low PPM oscillator or TCXO. They are only a few bucks more.
There is a lot of good info on http://www.rtl-sdr.com/ (http://www.rtl-sdr.com/), including reviews and buyers guides. At the moment, if I were buying one, I'd probably get the RTL-SDR Blog v3 unit with the 2 antennas, but they are out of stock on Amazon at the moment.
-
Protocol 9 does a straight circular mapping. Some people seem to feel that is correct. Protocol 39 does a mapping using a modified gray code that matches the old aculink reporting and my 01512 display. I believe some of the aculink parsers (ipwx, haculink, etc.) went through the same discovery process. I don't know if there are two versions of the 5-n-1, or if the people who feel the original circular mapping is correct just haven't noticed.
I'm pretty sure there's only the gray-code mapping. It comes from a plastic optical encoder disc inside the 5n1. It wouldn't make a lot of sense for them to change that for different production runs.
In any case, it's really easy to fool yourself that the "circular" mapping sorta works, but when you really look at it in a detailed, methodical fashion, the gray-code version is correct.
Regarding suppressing duplicate messages: The Acurite devices send the message multiple times in each message burst. In a number of cases, the received signal strength indicator on acurite gear is not the actual signal level, or signal-to-noise ratio, but is an attempt indication of quality judging by the number of times the message was heard. Note: IIRC, Protocol 9 will suppress duplicates, but assumes that only a single 5-n-1 will ever be heard.
Hmm... on the displays they subtract a bar every time an expected data packet is missed, when it drops to zero then the display starts rescanning.
On the bridge/SmartHUB, there's an analog voltage on the RSSI pin of the radio module that represents the signal strength. I don't know the details of how they are computing that, but the bridge's microcontroller converts that into an integer up to 4.
-
OK. I've got it installed and initially running.
Here are my notes for compiling and installing. Use them at your peril... There could be typos or I could have forgotten something.
Problem: you have to be root or use sudo to execute the final rtl_433 command. I thought I compiled with what I needed for a non-root user to run it, but apparently not.
The UDEV rules you installed should fix that, but probably want take effect until after a reboot.
Compile and install rtl-sdr:
$cd rtl-sdr
$mkdir build
$cd build
$cmake ../ -DINSTALL_UDEV_RULES=ON -DDETACH_KERNEL_DRIVER=ON
$make
$sudo make install
$sudo ldconfig
The above steps should take care of the device ownership, because it's installing a UDEV rule to deal with permissions. Suggest rebooting here.
I'm getting data... more than I expected, though. I see my 5n1, but I also seem to be getting a lot of data from a "Danfoss CFR Thermostat". Must be from a neighbor...
Yes, that can happen. Also, some protocols are prone to false positives.
To narrow things down, just enable the protocols you need. Here are all the Acurite protocols
$ rtl_433 -q -R 10 -R 11 -R 39 -R 40 -R 54
I didn't enable 9, since the 5-n-1 is also covered by 39.
If you want to see the protocol numbers:
$ ./src/rtl_433 --help 2>&1 | egrep -i acurite
[09]* Acurite 5n1 Weather Station
[10]* Acurite 896 Rain Gauge
[11] Acurite 609TXC Temperature and Humidity Sensor
[39]* Acurite 592TXR Temp/Humidity, 5n1 Weather Station, 6045 Lightning
[40]* Acurite 986 Refrigerator / Freezer Thermometer
[54] Acurite 606TX Temperature Sensor
-
Protocol 9 does a straight circular mapping. Some people seem to feel that is correct. Protocol 39 does a mapping using a modified gray code that matches the old aculink reporting and my 01512 display. I believe some of the aculink parsers (ipwx, haculink, etc.) went through the same discovery process. I don't know if there are two versions of the 5-n-1, or if the people who feel the original circular mapping is correct just haven't noticed.
I'm pretty sure there's only the gray-code mapping. It comes from a plastic optical encoder disc inside the 5n1. It wouldn't make a lot of sense for them to change that for different production runs.
I agree, I wouldn't think that would make sense. I was just given those who think it is/was correct the benefit of a doubt.
In any case, it's really easy to fool yourself that the "circular" mapping sorta works, but when you really look at it in a detailed, methodical fashion, the gray-code version is correct.
Agreed.
Regarding suppressing duplicate messages: The Acurite devices send the message multiple times in each message burst. In a number of cases, the received signal strength indicator on acurite gear is not the actual signal level, or signal-to-noise ratio, but is an attempt indication of quality judging by the number of times the message was heard. Note: IIRC, Protocol 9 will suppress duplicates, but assumes that only a single 5-n-1 will ever be heard.
Hmm... on the displays they subtract a bar every time an expected data packet is missed, when it drops to zero then the display starts rescanning.
On the bridge/SmartHUB, there's an analog voltage on the RSSI pin of the radio module that represents the signal strength. I don't know the details of how they are computing that, but the bridge's microcontroller converts that into an integer up to 4.
Good to know, at this point, I don't remember where I got the impression that the RSSI interpretation was based on the number of successful receives.
Note on the 5-n-1, each message has a bit to indicate if it's the 1st, 2nd or 3rd copy.
// The sensor sends the same data three times, each of these have
// an indicator of which one of the three it is. This means the
// checksum and first byte will be different for each one.
// The bits 5,4 of byte 0 indicate which copy of the 65 bit data string
// 00 = first copy
// 01 = second copy
// 10 = third copy
// 1100 xxxx = channel A 1st copy
// 1101 xxxx = channel A 2nd copy
// 1110 xxxx = channel A 3rd copy
The 592 tower and the 6045 lightning detector don't have this property.
Currently the decoders in rtl_433 don't have a notion of signal strength. The Pulse Analyzer, enabled with -A, attempts to give some info based about signal levels and frequency offset.
-
Make a directory for a local git repository, then clone the source code we need:
$mkdir git
$cd git
$git clone git://github.com/merbanan/rtl_433
$git clone git://git.osmocom.org/rtl-sdr.git[/code]
For rtl_433, it is probably irrelevant, but I've been using keenerd's rtl-sdr repo. There are a bunch of patches and improvements to the other tools.
https://github.com/keenerd/rtl-sdr
(Add .git to that url for the clone line).
If you are interested in the changes see http://igg.kmkeen.com/
-
I'll give you a heads up if I change any of the Acurite code. Are you watching the merbanan/rtl_433 github repo for changes? I hope the structured data conversion doesn't cause too much churn with your code. Unfortunately there aren't releases yet that could say you support. Hopefully that will happen soon.
my intent is to make weewx-sdr look for json output first, then fall back to text strings if it does not find json.
right now (06oct2016) the weewx-sdr driver only parses text strings from rtl_433
i would like to do it generically (i.e., using json) so that mapping observation names and sensor identifiers to database schema fields is simply a matter of entries in a configuration file. unfortunately, not all of the rtl_433 decoders can emit json.
the mapping pattern i am using looks like this:
database_field = observation_label.sensor_identifier.packet_type
so you could distinguish between two different 5n1 clusters, or any number of t/h sensors, or a t/h acurite sensor versus a t/h hideki sensor.
that way you can listen for traffic from any number of sensors, possibly from different manufacturers, and put the results unambiguously into a single database.
another option is to combine data from multiple databases at report time; with weewx you could easily run multiple weewx instances, each with its own sdr, then combine databases at the reporting layer.
i imagine that some installations will prefer the former, others the latter.
m
-
@rct - Any new progress on the decoding of the lightning sensor?
I started taking a look at a lightning sensor device tonight (just the device, I have no display, so I'm flying blind).
Here are some things I've noticed:
There seem to be at least several message types. They started changing fast when I put the sensor in my freezer. They started changing fast when I took it out, too.
Temp has problems as you know. It's translating to around 100C inside my freezer. Maybe part of the temp is in the bits representing "message type"?
Somehow the "interference" signal needs to be accounted for. Maybe that's a message type, but I don't understand why there would be so many message types.
The strike counter and distance don't make much sense as it doesn't seem to relate to any storm activity around me.
I guess I'll have to wait for some storm activity and see what happens.
-
@rct - Any new progress on the decoding of the lightning sensor?
I started taking a look at a lightning sensor device tonight (just the device, I have no display, so I'm flying blind).
I haven't been able to make too much more progress with the code. I have some theories on the meaning of the bits, but I haven't been able to nail things down conclusively yet. I too an flying blind. I feel like I'm seeing behavior that I just don't understand or is just plain erratic. I've worked out the decoding four other acurite devices and didn't have much trouble, though I had displays for those to confirm what I saw.
Hopefully now that you've got a sensor too we'll be able to compare notes and make more progress. This will also force me to clean up my notes and share them.
Here are some things I've noticed:
There seem to be at least several message types. They started changing fast when I put the sensor in my freezer. They started changing fast when I took it out, too.
That's very interesting. I haven't tried a freezer test yet. I haven't seen enough variety in that byte to think it might be temperature. Values I've seen are 0x11, 0x51, 0x41. 0x50.
Note: I believe the data bytes, the ones in the message between the ID bytes, and the checksum byte use parity checking, so only 7 bits are available for encoding information. This is the same as the 5n1 and the tower.
Did you capture the text output from rtl_433 when you did your freezer test?
Currently I believe the 5th byte, which I'm printing as message type, is a bit mask.
- 0x01 - Most of the time the LSB (0x01) is on, which I suspect is Battery Ok. It went off when I dropped the voltage or current to fall below about 2.4 Vdc. However, I've seen this bit off at a couple of other times that I don't understand
- 0x10 - TBD
- 0x40 - Transmitting every 8 seconds (lightning/interference detected)
Temp has problems as you know. It's translating to around 100C inside my freezer. Maybe part of the temp is in the bits representing "message type"?
It's possible. I know the interpretation of temperature is completely wrong. I haven't seen the sort of incremental changes in the message type/status byte to make me suspect that it is a reading. While I haven't done a fridge/freezer test yet, I would have expected to see some incremental changes that would be a clue for decoding.
Somehow the "interference" signal needs to be accounted for. Maybe that's a message type, but I don't understand why there would be so many message types.
So far, I've tried observing the data when interference is present and when it's not. I didn't see see a clear, simple bit flip that I recognized. I don't remember if the console has an indication for interference or not, I seem to recall it doesn't. See below about possible status bits in the "distance" byte. The "distance byte" is where I see activity when creating interference.
The strike counter and distance don't make much sense as it doesn't seem to relate to any storm activity around me.
The strike counter, the 7th byte, has been pretty stable for me. It increments only shorting after the unit beeps because it thinks lightning has been detected. So I've been fairly confident about that. The value remains the same across power ups. I can occasionally trigger false positives by moving the sensor in very close proximity to my laptop and watch that value increment.
"Distance", the 8th byte, I'm currently guessing has both status bits and a distance (or strength?) value. When powering up the unit, the value of distance is 0x9f, or 0x1f after removing the parity bit. My current thinking is the lower 5 bits are the distance/strength value. I think 0x1f indicates no value, or not valid. My guess is that the bits 0x60 are status bits. The spec for reporting the lightning distance is up to 25 miles or 40 km. 25 miles could be encoded in 5 bits (0x19) with a resolution of 1 mile.
I also believe there is a number of seconds delay between the beep and when the lightning strike counter is incremented. During that time there are changes in the "distance" byte. My guess is that when the strike count is updated the "distance" byte is then valid.
I guess I'll have to wait for some storm activity and see what happens.
I have recordings from one thunderstorm. Now that summer is over, I'm not sure when the next one will be. It was a fairly quiet summer for us thunderstorm wise. While we haven't had any storms, I think I've recorded output for the last several weeks or more. I have to look through and analyze that for any clues.
One thing I've noticed is that the sensor trips into transmitting every 8 seconds every now and then, without ever beeping to indicate lightning or counting a strike.
Also, are you able to trigger any false positives with interference?
I'm interested in seeing any data you've captured. (text output is fine since the data bytes are in each line.)
Thanks
-
I didn't record what happened during the "freezer test", but I can do it again.
What are the best command options to get what you need?
At the moment I'm not hearing much but my 5n1 and the lightning sensor. My neighbor's thermostat data comes and goes.
-
Capturing the text output is good as it's printing all the raw bytes on each line. I tend to use either `script -af file` to capture everything or:
rtl_433 -q -p NN -R 39 2>&1 | tee out-rtl-$(date +%Y%m%s-%H%M%S)
I'm pretty confident that the bytes are being demodulated correctly. It's similar to the tower and the 5n1.
You could always capture the raw signal with `rtl_433 -a -t`, which will let you replay it later with -r but that can take a bit of space.
-
The attached file is actually in gzip format, not zip, so I could attach it.
Starting temp about 79F, placed in freezer at about 5F for about 10 minutes or so.
At top of the hour removed from freezer and continued monitoring where the temp was about 74F.
Hope this helps!
-
George, thanks for the data.
So in the 5th byte of your data, the byte that I think is the status/message type, I only see 5 values, which isn't enough range for temperature. 1st column is number of occurrences. 2nd column is the value in hex. 3rd column is binary. Note I believe the MSB to be used for parity.
12 90 0b1001 0000
18 11 0b0001 0001
141 50 0b0101 0000
170 cf 0b1100 1111
180 4e 0b0100 1110
So 0x90 (0x10), 0x11, 0x50 are values I've seen in that field before, but 0xcf (0x4f) and 0x4e are new to me. This is the progression that byte went through, where the first column is counting the number of occurrences.
18 11
12 90
33 50
81 cf
180 4e
89 cf
108 50
Though it varied during what should have been the big changes in temperature, I'm not spotting any clues that make sense to me right now.
In your data, the byte that I think might be temperature had 49 different values ranging from 0x00 to 0x7d, after removing the parity bit. That's too big of a range for a simple temperature encoding given it didn't hot enough to get to the maximum end. So I'm still stumped on temperature.
As for the other values. The strike counter is fixed at 5 which is plausible. Don't know if it comes from the factory at 0 or not. I've seen RFI generate false positives there. The "distance" byte which probably has status bits in at least part of the upper nybble alternated between 0xc0 (0x40) and 0x60. Though what is interesting, is it looks like it would send 0x60 for 1 transmission (message is sent 3 times), and then goes back to 0xc0 (0x40) for the next 9 - 15 transmissions.
249 c0
3 60
36 c0
3 60
45 c0
3 60
23 c0
3 60
27 c0
3 60
30 c0
3 60
93 c0
-
I went and checked the data I've been logging over the last few weeks. I found some similar status bytes to George's that I wasn't expecting (values where the lower nybble isn't 0 or 1.
12183 0f
21562 11
35632 cf
44488 90
61825 d1
132089 50
I don't know what the lower nybble being 0xf represents. My guess that the LSB (0x01) represented battery status, appears to be wrong.
-
As far as the count goes, it's always been 5. I started reading it soon after putting in the batteries, so maybe that's from factory testing.
I haven't heard it beep or anything like that since I got it.
-
I purchased one of these devices about a month ago & I am pleased with it. Someone mentioned about an "am radio" being just as good, I disagree now that I own both.
Was curious if anyone else here had profiled two parameters, one in which the device seems to be directional in receiving, & the other, height off the ground makes a difference toward how far the device picks-up a strike?
-
rob,
here are more data for the lightning sensor. let me know if there is a specific test that would help isolate the bytes.
the red light flashes every 4 or 5 seconds. i see lines from rtl_433 every time the green light flashes, which is about every 8 seconds. every once in awhile the thing starts beeping.
i have updated the weewx-sdr driver to recognize the lightning sensor.
do you know what the units are for distance?
m
-
rob,
would you consider refactoring the changes you made to rtl_433?
i think it would be better to keep the 5in1, lightning, and 592TXR output separate; getting three different types of packets for '-R 39' does not seem to be keeping with the rest of the rtl_433 design patterns.
my rtl_433 lists the following:
Registering protocol [9] "Acurite 5n1 Weather Station"
Registering protocol [10] "Acurite 896 Rain Gauge"
Registering protocol [11] "Acurite 609TXC Temperature and Humidity Sensor"
Registering protocol [39] "Acurite 592TXR Temp/Humidity, 5n1 Weather Station, 6045 Lightning"
Registering protocol [40] "Acurite 986 Refrigerator / Freezer Thermometer"
Registering protocol [54] "Acurite 606TX Temperature Sensor"
if it were refactored to the listing below, we would have much better control over the packets:
Registering protocol [9] "Acurite 5n1 Weather Station"
Registering protocol [10] "Acurite 896 Rain Gauge"
Registering protocol [11] "Acurite 609TXC Temperature and Humidity Sensor"
Registering protocol [39] "Acurite 592TXR Temp/Humidity"
Registering protocol [40] "Acurite 986 Refrigerator / Freezer Thermometer"
Registering protocol [54] "Acurite 606TX Temperature Sensor"
Registering protocol [XX] "Acurite 6045 Lightning"
then one could get just lightning packets, or just 5in1 packets.
m
-
rob,
would you consider refactoring the changes you made to rtl_433?
i think it would be better to keep the 5in1, lightning, and 592TXR output separate; getting three different types of packets for '-R 39' does not seem to be keeping with the rest of the rtl_433 design patterns.
[...]
then one could get just lightning packets, or just 5in1 packets.
m
Sorry for the delay, I didn't see this until now. (I thought I was getting notified for this topic).
The rationale for the 3 acurite devices being handled by the same protocol is they use the same RF encoding with slight differences in message format that can be used to tell them apart. If they were split into 3 separate protocols, they would still match, and all 3 would run each time. They wouldn't output anything, but they'd do the same message envelope validate in each call back.
The ability to turn protocols on an off was added to rtl_433 to reduce CPU overhead and to ignore false positives. The CPU overhead problem has been fixed, it used to be that every sample was iterated over for each enabled protocol. Now the message is converted into pulses much earlier. CPU usage on a 1st gen. RPi was then low enough that it could run with all protocols enabled. Protocols in rtl_433 are still a bit more heavyweight then they should be. There is some cleanup work that needs to be done there at some point.
What are the use cases where you've got multiple Acurite devices, but only want to see the output from a subset?
If you wanted to select/filter certain devices, why wouldn't that be handled in what ever consumed the output of rtl_433?
Each device type has a fixed string to identify the device type "Acurite tower sensor", "Acurite 5n1 sensor", "Acurite lightning".
Also each devices decoded by the shared Acurite protocol 39 has a fixed ID that is on the order of 12-16 bits. The consumer could select on that. (A consumer might also want to select on Channel number.)
Some of this should get easier with the conversion to structured data that will output JSON. I think a Pull Request has recently been merged that makes the 592TXR tower sensor output JSON, but I haven't tried it yet. I should follow suit and make the 5n1 have structured data output.
I could see temporarily moving the lightning detector into it's own protocol because it's somewhat experimental. It's not likely to output structured data until I can get a better handle on decoding it. Though once it's stabled, and outputting structured data, I'd probably want to put it back in the same group as the 5n1 and the tower for the reasons mentioned above.
I haven't had a chance to try WeeWx yet. So I haven't run any of your WeeWx drivers. I've got scripts parsing the output and putting it in RRDTool for graphing/storage and log files for other stuff (security). I probably need to set up another rtl-sdr so I can try WeeWx without tearing down my stuff.
[rtl_433 topic - If someone familiar with the conventions for this forum sets up a topic, or an area, or whatever for rtl_433, I'd happily move this discussion there. rtl_433 decodes other weather stations beyond Acurite.]
-
The rationale for the 3 acurite devices being handled by the same protocol is they use the same RF encoding with slight differences in message format that can be used to tell them apart. If they were split into 3 separate protocols, they would still match, and all 3 would run each time. They wouldn't output anything, but they'd do the same message envelope validate in each call back.
The ability to turn protocols on an off was added to rtl_433 to reduce CPU overhead and to ignore false positives. The CPU overhead problem has been fixed, it used to be that every sample was iterated over for each enabled protocol. Now the message is converted into pulses much earlier. CPU usage on a 1st gen. RPi was then low enough that it could run with all protocols enabled. Protocols in rtl_433 are still a bit more heavyweight then they should be. There is some cleanup work that needs to be done there at some point.
What are the use cases where you've got multiple Acurite devices, but only want to see the output from a subset?
thanks for the explanation. fixing the cpu overhead goes a long way toward making the selection of separate protocols moot.
however, selecting output from rtl_433 based on sensor, not protocol, is still useful.
one use case is that when i test for lightning sensor, any other sensor data just complicates things. but that is a development use case, so not really a big deal.
the use case for support is a much bigger deal. it is easier to explain to users "each type of sensor has its own number in rtl_433" rather than trying to explain "there are two different options for 5in1 packets, and if you just want to get lightning data you also have to get 5in1 and tower data, but not the same 5in1 data as the other 5in1"
from a user point of view, it does not matter which sensors share the same protocols, especially when the semantics of using rtl_433 are based on "choose a type of sensor" rather than "choose a protocol". users see sensors and sensor models, not protocols or encoding/decoding.
If you wanted to select/filter certain devices, why wouldn't that be handled in what ever consumed the output of rtl_433?
Each device type has a fixed string to identify the device type "Acurite tower sensor", "Acurite 5n1 sensor", "Acurite lightning".
Also each devices decoded by the shared Acurite protocol 39 has a fixed ID that is on the order of 12-16 bits. The consumer could select on that. (A consumer might also want to select on Channel number.)
the weewx-sdr driver already does this using this construct:
database_field = <observation_name>.<sensor_identifier>.<sensor_type>
to map sensor output to fields in a database.
but once again from a user point of view, it is more difficult to filter when you're getting data from things you do not care about.
if someone is trying to set up a lightning sensor, but they're getting 5in1 packets from one neighbor and tower packets from another neighbor, that makes the configuration more difficult.
Some of this should get easier with the conversion to structured data that will output JSON. I think a Pull Request has recently been merged that makes the 592TXR tower sensor output JSON, but I haven't tried it yet. I should follow suit and make the 5n1 have structured data output.
weewx-sdr will do json parsing if you ask for it from rtl_433 and the sensor parser emits json. otherwise it falls back to parsing lines of text.
from my pov, having a stable output from the rtl_433 sensor is more important than whether that output is json or lines of text. but it would be nice if everything did json (or nothing did json) so i don't have to maintain two different parsers for every sensor.
m
-
the weewx-sdr driver already does this using this construct:
database_field = <observation_name>.<sensor_identifier>.<sensor_type>
to map sensor output to fields in a database.
First, to help me understand, can you give some examples of what this configuration looks like for some of the Acurite devices?
If someone has (or can receive) more than 1 sensor, they need to be able to identify the device, right? Typically after running for 2-3 minutes you should have seen all of the device IDs, channel numbers, etc. that would help identify the device.
What do you do for devices that change their ID's each time the batteries are changed? (LaCrosse, some of the acurites, etc.)
from my pov, having a stable output from the rtl_433 sensor is more important than whether that output is json or lines of text. but it would be nice if everything did json (or nothing did json) so i don't have to maintain two different parsers for every sensor.
I understand, you are in a difficult position here, with no stable (or 1.0) release of rtL433 and things being in transition. Benjamin (merbanan) has a plan for what he considers to be the 1.0 release criteria but hasn't shared it, yet.
The direction that has been agreed to is to try to convert all of the devices to structured output. The expectation is that JSON ithe format that is most useful for consumers to parse, though CSV and key values pairs are also supported. (Note: As of a month or two ago, there was a change that all devices that don't emit structured data are disabled by default. Specifically enabling the protocol -R NN or -G is necessary to turn the deprecated one.
When a device is converted to use structured output, the old code for printing data is removed. So I think once the decoders have been converted, you should deprecate your old parsers, they will only work with an older version of rtl_433. Off the top of my head, I can't think of a good reason for your driver to run rtl_433 without '-F json'. I think, but haven't given it that much thought yet, that the output you should support is JSON output for devices that support it and the legacy, pre-JSON output for devices you are interested in supporting.
-
the weewx-sdr driver already does this using this construct:
database_field = <observation_name>.<sensor_identifier>.<sensor_type>
to map sensor output to fields in a database.
First, to help me understand, can you give some examples of what this configuration looks like for some of the Acurite devices?
If someone has (or can receive) more than 1 sensor, they need to be able to identify the device, right? Typically after running for 2-3 minutes you should have seen all of the device IDs, channel numbers, etc. that would help identify the device.
here are examples from the weewx-sdr readme:
# collect data from Acurite 986 fridge/freezer sensor set 1R and 2F
[SDR]
driver = user.sdr
[[sensor_map]]
extraTemp1 = temperature.1R.Acurite986Packet
extraTemp2 = temperature.2F.Acurite986Packet
# collect data from Acurite 06002RM t/h sensor 3067
[SDR]
driver = user.sdr
[[sensor_map]]
inTemp = temperature.3067.AcuriteTowerPacket
inHumidity = humidity.3067.AcuriteTowerPacket
as you noted, one must identifiy the sensors before creating the map. you could do that by running rtl_433 directly, but if you run the weewx-sdr driver directly you get the observations, identifiers, and types in a more obvious format.
details are in the readme on github:
https://github.com/matthewwall/weewx-sdr
feedback is most welcome!
What do you do for devices that change their ID's each time the batteries are changed? (LaCrosse, some of the acurites, etc.)
that is a problem for which we do not yet have a solution.
if there are no conflicting sensors, then a general match will work, for example:
outTemp = temperature_out.*.*
but if there are two sensors of the same model whose IDs change, then you have a problem.
-
here are examples from the weewx-sdr readme:
# collect data from Acurite 986 fridge/freezer sensor set 1R and 2F
[SDR]
driver = user.sdr
[[sensor_map]]
extraTemp1 = temperature.1R.Acurite986Packet
extraTemp2 = temperature.2F.Acurite986Packet
# collect data from Acurite 06002RM t/h sensor 3067
[SDR]
driver = user.sdr
[[sensor_map]]
inTemp = temperature.3067.AcuriteTowerPacket
inHumidity = humidity.3067.AcuriteTowerPacket
Thanks for that, I had missed that in the README. There are several things that are interesting to me about that example.
First, the 986 Fridge/Freezer sensors -- It's great to see that someone besides me is using that. Are you using it with weesx? Are you using it for room temperatures or frdige/freezer/kegerator/etc.?
Note: There is a small problem with the demodulator that causes it to miss the message repeater if the final bit of the CRC is a 1. As long as the first copy of the message is received intact there is no problem.
For the 592 Tower sensor I see you are using the device ID, which is fixed. On the 986 I see you are using the 1R/2F designation, as the device ID. That's essentially a fixed channel number. (When I convert that to JSON, I'll put that info in the Chennel number.) The 986 device has an ID (12-16 bits) but it changes at each battery change. So unless I'm missing something, if more than 1 set of 986 sensors were in range of the receiver there would be a conflict.
I'll have to spend some time getting weewx running.
-
I finally sat down last night to update my code for the SmartHub. Guess I should have done that some time ago, given now nicely parseable it is. I now have 2 Room Monitors with the leak detectors, plus one of the outdoor sensors and the spot-check sensor attached. I believe I have 17 sensors in total if you count my neighbor's 3N1. :shock: :-P
I'm now ready to participate in anything rtl_433 related; looks like there is still work to do with the lightning detector? Given the seasonal change, is it feasible to decode w/o actual lightning? George, I see you looked at the chip specs, wondering if it's possible to simulate whatever the chip is trying to detect.
-
I've got one of these and the temperature reading isn't correct. It's been in my shop all day, where the temp is a pretty constant 73 degrees F. I put fresh batteries in it this morning, and the "temperature" that RTL-433 returns stared at 2 and has now risen to 27.
I'm using WeeWx and Matt Wall's SDR driver.
Can someone confirm that this combination SHOULD be working, before I call Acurite?
Thanks!
Clay Jackson
-
Did you try running rtl_433 standalone to see what it is receiving? Have you updated rtl_433 in the past month, since the change to JSON?????
-
The temperature on mine is off by around 3 degrees or just a hair less.
Although I purchased it for the lightning detection, which works well for myself.
-
Thanks for the responses! Yes, I'm using the JSON version of rtl; and, if I look at the raw data,it's doing the same rise (in C, of course).
In any case, talked to Acurite, they asked for the QC number on the battery cover, and then said "we'd like to send you a new one". So, apparently something's going on. I asked the tech and all she said was, "we have a number of sensors from this lot behaving this way, don't know why".
Clay
-
Out of curiosity, what was the magic QC number?????
-
3716 - a sticker on the lid of the battery compartment
-
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.
-
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:
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).
-
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.
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
-
bob,
this is the output from one of my lightning sensors:
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
-
If it helps, this is the output from my lightning sensor. I bought it week before last.
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
-
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.
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
-
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.
-
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.
-
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.
-
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
-
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.
-
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
[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.
[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.
-
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
-
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.
-
@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.)
-
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:
[[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:
[[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
[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!
-
Right, I saw a post from you on the google group, which I think answers my own questions.
I want:
lightning_strikes_total = strikes_total.002D.AcuriteLightningPacket ## lightning detectorwhich assigns the running total to lightning_strikes_total
[[deltas]]
lightning_strikes = lightning_strikes_total
which says that the variable lightning_strikes is the delta value of lightning_strikes_total
[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.
-
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.
-
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.
-
* 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?).
-
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.
-
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...
-
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
-
@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.
-
A T-Storm passed through the area...captured some data. Hopefully this will help.
-
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;
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
Thanks for that, but unless I'm missing some context that code is pointless. The case statements are just turning the hex literal into a decimal literal, but assuming those are in some int data type means no conversion is necessary. Hex 28 is 40 decimal. So I have no idea why someone thought that was needed. Maybe the understanding changed over time and the maintainers didn't notice that "lookup" table didn't actually do anything any longer.
However, it's not relevant to the acurite unless I'm missing some bits. There only appear to be 5 bits available, so you've got 0-31, (0x1f). I think 0x1f (31) is an invalid value. That's what it reset to at power up. Though I think the status bit indicates whether the distance value is valid or not.
I haven't looked at the data sheet in a year or two. I don't remember there being any clues that seemed relevant for how the acurite sensor is encoding it.
-
A T-Storm passed through the area...captured some data. Hopefully this will help.
So taking a quick look, you've got three distance correlations in that file. (There are actually 5 but 3 have the same values.)
rtl_433, console
20, 15
10, 7 (repeated 2 more times)
12, 9
Did I interpret that correctly?
-
Yes that is correct. I'm going to set the console to display KM and capture data during the next time storms pass through.
-
3 data points isn't a lot to have confidence, but just looking at those, it looks like the relationship is the console value in miles is 3/4 of what the raw value in the message is. That doesn't quite seem like any magic number that I recognize. If that it the actualy conversion, it means the range 31 - 0 raw is 23.25 to 0 miles. IIRC the spec is up to 25 miles.
Kilometers would be useful at some point, but I'd be interested in more Miles correlations. The larger the range and the more data points, the easier it will be to see if we've got the right conversion.
-
Hopefully I get some storms that stick around and will try to get more data points.
-
Actually if you get some brief / far off storms that only register a strike or two that would also be helpful. Large values for distance that are stable for long enough to be sure of the correlation would be best.
-
Did you look at my data? I found no obvious correlation.
I also had the 10 and 12 as 7 and 9, however I took a bunch of KM readings too.
The closest I got to was sensor value / 1.4 rounded, however I then got a longer distance reading that did not correspond.
I also had a few readings from rtl433 that were not whole numbers. Not sure how that happened.
-
Did you look at my data? I found no obvious correlation.
I also had the 10 and 12 as 7 and 9, however I took a bunch of KM readings too.
The closest I got to was sensor value / 1.4 rounded, however I then got a longer distance reading that did not correspond.
I also had a few readings from rtl433 that were not whole numbers. Not sure how that happened.
The problem with the data you provided is that it has been modified by your weewx config/processing, so it is approximate and probably misleading. I think you are storing 5 minute buckets in the database and were doing averaging. The 6045 transmits every 8 seconds when it is in active mode. So that's a long time.
As you said you are seeing some floating point numbers for distances. The numbers coming out of rtl_433 can only be integers.
Those floating point numbers are caused by the aggregation (averaging) you are (or were?) doing in your weewx config. Your SQL statements show you are rounding which shouldn't be necessary. @craigthom suggested changes to your config. You should discard the data from when you were averaging.
The most reliable data for doing correlations is the raw messages from rtl_433. I think there is a way to capture those when weewx is running.
That being said -- Dividing by 1.4 is pretty close to multiplying by 3/4. The reciprocal of 3/4 is 1.3333... That is for a conversion to miles. Given the 5 minute buckets and possibly averaging, I'm not surprised that you would see numbers that don't fit.
Note: if you remove the batteries/power cycle the sensor, it resets the storm distance to 31 (0x1f).
31 is either an invalid value or some of the other bits indicate that it shouldn't be used for a distance calculation.
-
I've cleaned up and posted a Jupyter notebook that I've used to look at the lightning detector data. The notebook uses data from Summer 2018. I've extracted only messages where there are changes in strike count, storm distance, and USSB1.
Some patterns can be seen in the data.
See https://github.com/rct/device-decoding-notes/blob/master/acurite-6045-lightning/rct-data/lightning-breakdown-1.ipynb
-
A T-Storm passed through the area...captured some data. Hopefully this will help.
For what it's worth I also posted a Jupyter notebook where I was examining the data @Storm017 provided.
https://github.com/rct/device-decoding-notes/blob/master/acurite-6045-lightning/storm017/storm017-data.ipynb
-
Did you look at my data? I found no obvious correlation.
I also had the 10 and 12 as 7 and 9, however I took a bunch of KM readings too.
The closest I got to was sensor value / 1.4 rounded, however I then got a longer distance reading that did not correspond.
I also had a few readings from rtl433 that were not whole numbers. Not sure how that happened.
The problem with the data you provided is that it has been modified by your weewx config/processing, so it is approximate and probably misleading. I think you are storing 5 minute buckets in the database and were doing averaging. The 6045 transmits every 8 seconds when it is in active mode. So that's a long time.
As you said you are seeing some floating point numbers for distances. The numbers coming out of rtl_433 can only be integers.
Those floating point numbers are caused by the aggregation (averaging) you are (or were?) doing in your weewx config. Your SQL statements show you are rounding which shouldn't be necessary. @craigthom suggested changes to your config. You should discard the data from when you were averaging.
Hi, I have config for doing deltas for number of strikes, however the distance has never been modified by weewx config, as there's no "module" for it.
That's the reason I was trying to figure out how to get it to work ;-)
So distance is raw data. The floating numbers are odd, and could be discarded, the other values match with other posts, so I think you can use them as reliable data.
-
@wcndave - take a look at this post from @craigthom again. From what he says you need to use the min aggregator. The default for things that aren’t defined is to average them, which explains what you are seeing
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
[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.
[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.
-
OK, makes sense, thanks. Although my non-floating distance data is still correct, with 500 strikes in one 4 hour period I had quite a lot of data!
-
Out of interest, what does happen to the delta when the values wrap around from 127 back to 0? Do you simply lose one reading? If they go from 125 to 8, you'd lose 10 strikes...
-
OK, makes sense, thanks. Although my non-floating distance data is still correct, with 500 strikes in one 4 hour period I had quite a lot of data!
If you don't get any changes during the interval, the average computed will be the same as the (one) input number.
-
Out of interest, what does happen to the delta when the values wrap around from 127 back to 0? Do you simply lose one reading? If they go from 125 to 8, you'd lose 10 strikes...
I believe you are asking how weewx handles counters. Hopefully one of the people with direct weewx knowledge can answer that.
Note: counters are a reasonably common data representation. Things like the rain gauges count tips. There aren't infinite bits available so at some point the counter wraps around just like a 4 digit meter (electrical usage, odometer, etc.) that rolls over from 9999 -> 0 or whatever depending on the number of digits it has.
-
Out of interest, what does happen to the delta when the values wrap around from 127 back to 0? Do you simply lose one reading? If they go from 125 to 8, you'd lose 10 strikes...
I believe you are asking how weewx handles counters. Hopefully one of the people with direct weewx knowledge can answer that.
Note: counters are a reasonably common data representation. Things like the rain gauges count tips. There aren't infinite bits available so at some point the counter wraps around just like a 4 digit meter (electrical usage, odometer, etc.) that rolls over from 9999 -> 0 or whatever depending on the number of digits it has.
Sure, and the rain counter would appear to go very high, it counts yearly rainfall for example.
However, if the lightning strikes count up to 127, then it can easily go three times round in one night for me, meaning data could be lost.
eg, if the readings were 108, 121 008, 012
there there have been 13, 14, 4 strikes in each reporting period respectively.
However weewx might count that as 13, 0, 4
Just wondering if there was a way to tell weewx what the wraparound point was, so that it could calculate based on that, however probably better to ask in the weewx group.
Just seemed people here knew about the lightning counter in quite some detail :-)
Thanks!
-
Remember the lightning sensor is sending data every 8 seconds when it is in active mode. So unless there is an RF problem, it will be a small interval when it wraps around.
-
So the delta is done on sensor data received, rather than on db writes? Ie if it writes to db every 5 minutes, doesn't do the delta calc then...