pcfens
commented
10 years ago Wow - I must have really been writing this in a hurry to have missed so much.
I fixed the set_byte in the set_indoors method, and removed the extra read_data in set_mask_disturber. I think it was there to make sure that the registers variable was up to date, but I decided to handle that differently while I was first writing everything.
The lightning.py file was meant as a proof of concept more than anything (it's very sloppy). If you have a better version that you'd like included in this repo feel free to send a pull request and I'll include it or replace the one I already have.
The RaspberryPi for a while has had issues with I2C repeated starts, something that the AS3935 is supposed to use for reading specific registers. It could be possible that the strange behavior is a result of this. There is a proposed fix, but I don't know that it's made it into any official distribution yet, and I haven't had time to do any detailed testing.
I've used it to detect lightning using the code here, though not as reliably as I would like. If you have any other thoughts, or pull requests please send them along.
lkomage
Been tinkering with the code as we've had rain but no lightning lately, and spotted another little bug. In the set_indoors function, it's missing a self.set_byte(0x00, write_value) at the end to actually change the register. There's also a possibly spurious self.read_data() at the end of the next function in the code, set_mask_disturber.
Still not sure about things working right. I've changed the beginning of lightning.py to do a little more initialization: calibrate, set indoors true, noise floor to 0, and mask disturber to false. And, a "restore to defaults" direct command added to the beginning of the calibration function. I seem to get inconsistent results just running it repeatedly. Like, now I run it and immediately get a couple noise detections (believable), and then a disturber detection. If I comment out the automatic setting of the disturber mask, it just goes into a constant reporting of disturber detection. My reading of the docs make it sound like a disturber shouldn't necessarily be a constant thing once detected (as the noise interrupt is). And sometimes I'll start it up and it will say waiting, and then say nothing about noise or disturbers, when a minute ago it reported both. Makes me think that there's some "resetting" that may be needed if you're repeatedly stopping and starting the code. Wish the docs were a bit clearer about the software interaction with the chip, not just the hardware aspects.
Also fixed it to notice an interrupt of 0, which is supposed to mean the distance has changed.
I guess I'll be able to really know more once we get some known lightning around. Funny, wishing for a storm to come through....