@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