Acurite Ligtning Detector bad temp

[Clay Jackson]

I've got an Acurite 6045M Lightning detector I'm trying to get integrated into WeeWx using RTL_433. I set one up in a room that normally runs between 65 and 75 and was seeing readings between32 and 258 degrees.   I called Acurite and they told me they thought I had a bad sensor and shipped me a new one.  I powered it up yesterday, and while it started out reading about 10 degrees high, it settled down and was pretty consistently tracking the temp overnight.  

This afternoon, I moved it to the greenhouse where the temp is about 45.   The sensor jumped to over 200, then dropped to 120, then back up to 170 and is now back at 46

Does anyone actually have one of these accurately reporting the temp?   Can someone suggest some debugging steps?   It's kinda hard to believe that I'd have two bad sensors from Acurite.

Thanks!

Clay Jackson

[Clay Jackson]

Been playing with this a bit - something's definitely not right.  I've got two sensors, 316F should be reading about 4.4 C and about 60 % RH; 2B6F should be reading about 21.1 C and 28 % RH.   Neither of them have had ANY lighting strikes recorded since power on.

Taking a look at the code (devices/acurite.c); but not really sure to where to start - Is there anyone I can work with who'd be interested in fixing this?

Here's the dump I have


2017-02-27 11:05:22 Acurite lightning 0x316F Ch A Msg Type 0x51: 33 C 44 % RH Strikes 2 Distance 15 - c0  31* 6f  ac  d1  21  82  0f  8f*
2017-02-27 11:05:22 Acurite lightning 0x316F Ch A Msg Type 0x51: 33 C 44 % RH Strikes 2 Distance 15 - c0  31* 6f  ac  d1  21  82  0f  8f*
2017-02-27 11:05:22 Acurite lightning 0x316F Ch A Msg Type 0x51: 33 C 44 % RH Strikes 2 Distance 15 - c0  31* 6f  ac  d1  21  82  0f  8f*
2017-02-27 11:05:23 Acurite lightning 0x2B6F Ch A Msg Type 0x11: 29 C 29 % RH Strikes 7 Distance 31 - c0  2b  6f  1d  11  1d  87  9f  cb*

[Robert Terzi]

Interesting.   So I bought a 6045M this past summer to give it a try and wrote that code.   I didn't buy a compatible display to go with it, so I was decoding it somewhat blind, though I've worked on a handful of other Acurite devices (5n1, "tower" 592TXR, 986 fridge/freezer, ...).

While I was able to get sensible data for humidity and the lightning strike counter I couldn't see an encoding for temperature in the messages that I could make sense out of.   I started to suspect that I might have a bad sensor.    There were some other things that were flaky about the sensor that made it hard to nail down the encoding.  I eventually gave up.

I'm happy to take a look at your data and see if I can make any progress.

--Rob

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To post to this group, send email to rtl...@googlegroups.com.
Visit this group at https://groups.google.com/group/rtl_433.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/d52fbd73-82f6-42ad-95c9-2422a90551fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Terzi]

Clay:

BTW, Do you have an Acurite console that displays the 6045M data?

Either way, if you can collect some more output from rtl_433 as conditions with some good observations/notes we can hopefully get this straightened out.  

A few notes:

Parity -- Like the 5n1 and 592TXR, a parity bit appears to be used on all the data bytes (but not the ID or checksum byte because those use all 8 bits).   In the data dump, bytes with a parity mismatch are output with a trailing '*'.

Humidity -- From my tests, seemed to be in the 4th byte same as the 592TXR "Tower" sensor.   Compared to my other sensors the 6045M seemed be off by a good 10% or so, but generally seemed to track the daily humidity variations.   So I'm reasonably confident in that decoding.  

Lightning -- appears to be in the 7th and 8th bytes.  The 7th byte, appears to count strikes detected.  One or more of the upper bits might encode some other status.   The counter does not reset at power up.   I've observed it increasing monotonically until it wraps around back to zero.    The 8th byte appears to have some sort of distance/strength value, but there are some other status bits at play.   When the sensor beeps to report detected lightning, this value doesn't seem to update/settle for a few seconds.   We didn't have that many thunderstorms this summer, but I was able to trigger some false positives with RF interference.

Temperature -- Is a mystery to me.   I'm currently using the 6th byte as temperature, but it's not making sense.  With my (suspect?) sensor, I see the most variation in this  byte.   If parity is being used there are only 7 bits - 127 possible values available for temperature.

I think I saw in the Acurite forum that someone (George N.?) identified the chip used inside the 6045M.  So hopefully there is a datasheet that might reveal some clues. I need to go check wxforum and see if anyone else has made any progress.

I'll follow up with you off list, so as not to fill this group with too much back and forth on this sensor.

--Rob

--
You received this message because you are subscribed to the Google Groups "rtl_433" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtl_433+u...@googlegroups.com.
To post to this group, send email to rtl...@googlegroups.com.
Visit this group at https://groups.google.com/group/rtl_433.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rtl_433/d1702808-aa7e-49ae-9edc-a571f6c3a7dc%40googlegroups.com.

[Clay Jackson]

OK – I’ve got two of ‘em side by side and am recording (rtl_433 -G)  to a file now.  Once I get a few hours of recording, I’ll post it back here.  Someone else replied as well; so perhaps between the 2 of us  we can get it figured out.

 

Clay