|
|
Post by earlthesquirrel on Aug 3, 2020 14:49:22 GMT -8
Hello again,
Now that the wind and rain sensors are operating after a loooong time debugging, now on to Lightning Detector.
Some questions:
1) I'm feeding the output data into a Weewx weather monitoring set up. It has the following values to be tracked for Lightning:
'lightning_distance', 'REAL'
'lightning_disturber_count', 'REAL'
'lightning_energy', 'REAL'
'lightning_noise_count', 'REAL'
'lightning_strike_count', 'REAL'
I see Distance, and Strike Count in the existing code (from the GitHub repo).
Question 1:
I don't see any counts for Noise or Disturber (I do see that they can occur, but it looks more like it adjusts based on them, but doesn't keep track of count... is that correct? And if so, I don't see that as a big problem)
Question 2: Was this left out of your existing code? Is there an example or place where I could pull the code on how to read this value?
Question 3: As you can see in picture below, I 3-D printed out the case, so the set up matches your instructions for setting it up with a Raspberry Pi with Grove Hat and Grove LCD, Buzzer and Sensor. The code however, leaves the LCD on continuously. That seems to be a lot of wear and tear on that... I know when mine restarts the text is fairly faint and doesn't really get readable for a bit. Is that expected? The colors are useful of course (in mine you can see that I caught it as orange/red during a strike)
Question 4: I am trying to figure out the proper placement of the device. Having it outside (and having the buzzer connected) doesn't provide the best solution. Having it inside and having buzzer go off in the middle of the night (or if power goes out) isn't a great answer either. As you can expect, i have the buzzer disconnected right now :-) Where do you recommend it being placed? I might have one window sill it could go on... is that a reasonable solution? If so, do you recommend the "set_indoors" to be set to True or False if it's on a Window sill?
Question 5:
Today during the storm, with indoors set to False, I got a lot of hits. In the 200-300 range. Is that a "reasonable" expectation? (I have Minimum_Strikes set to 1, which I "believe" indicates that it only takes 1 strike to trigger the interrupt that there was lightning... that correct? From code it "looks like it") I got it saying Lightning 34km away as well.
Question 6:
I had to restart the device a couple times today (was tweaking the code) so I never saw if the Last Result ever resets. From looking at the code, it doesn't seem that it ever does. What is the best way to detect that Lightning is detected and when is a reasonable time to "stop" displaying that it's Lightning in the area? Set some flags in the try loop? Base it on color changing on display? Or??
Thanks in advance...
EarltheSquirrel
|
|
|
|
Post by earlthesquirrel on Aug 4, 2020 22:58:46 GMT -8
Any feedback on these questions?
Some responses are necessary for me to integrate this sensor...
Thanks in advance...
|
|
|
|
Post by SDL on Aug 5, 2020 11:12:09 GMT -8
Been out at the lake! Back now.  Question 1: I don't see any counts for Noise or Disturber (I do see that they can occur, but it looks more like it adjusts based on them, but doesn't keep track of count... is that correct? And if so, I don't see that as a big problem) No, it's not counting them. They come in with the Interrupt, so it would not be hard to add.Question 2: I do see "energy" on displays related to the sensor. Such as your Instructable : www.instructables.com/id/Lightning-Detector-for-Raspberry-Pi-WeatherPi-Weat/ On the LCD display it shows "Energy". Also on the spec sheet indicates it as well. Was this left out of your existing code? Is there an example or place where I could pull the code on how to read this value? You can easily read the value and add it to the code. Put it with the code that reads from AS3935 after it gets the interrupt.Question 3: As you can see in picture below, I 3-D printed out the case, so the set up matches your instructions for setting it up with a Raspberry Pi with Grove Hat and Grove LCD, Buzzer and Sensor. The code however, leaves the LCD on continuously. That seems to be a lot of wear and tear on that... I know when mine restarts the text is fairly faint and doesn't really get readable for a bit. Is that expected? The colors are useful of course (in mine you can see that I caught it as orange/red during a strike) Now that is odd. We haven't seen that. You could turn it off and then just wake it up for the lightning but that doesn't sound all that useful.
Does it do this after a reboot or after a power on/off cycle?Question 4: I am trying to figure out the proper placement of the device. Having it outside (and having the buzzer connected) doesn't provide the best solution. Having it inside and having buzzer go off in the middle of the night (or if power goes out) isn't a great answer either. As you can expect, i have the buzzer disconnected right now :-) Where do you recommend it being placed? I might have one window sill it could go on... is that a reasonable solution? If so, do you recommend the "set_indoors" to be set to True or False if it's on a Window sill? I don't even like the buzzer. Window sill is good. I would guess that it should be set_indoors to False, but it more depends on how far away your electronics in your office are away from the sensor. (phone, monitors, computers, etc.).Question 5: Today during the storm, with indoors set to False, I got a lot of hits. In the 200-300 range. Is that a "reasonable" expectation? (I have Minimum_Strikes set to 1, which I "believe" indicates that it only takes 1 strike to trigger the interrupt that there was lightning... that correct? From code it "looks like it") I got it saying Lightning 34km away as well. set_indoors is probably reading a bunch of noise from your devices.Question 6: I had to restart the device a couple times today (was tweaking the code) so I never saw if the Last Result ever resets. From looking at the code, it doesn't seem that it ever does. What is the best way to detect that Lightning is detected and when is a reasonable time to "stop" displaying that it's Lightning in the area? Set some flags in the try loop? Base it on color changing on display? Or?? I would set up a time based reset. Say if it has been 30 minutes and then reset it.BP |
|
|
|
Post by earlthesquirrel on Aug 7, 2020 21:18:15 GMT -8
> Been out at the lake! Back now. Sounds NICE! Esp now :-)
Question 1: I don't see any counts for Noise or Disturber (I do see that they can occur, but it looks more like it adjusts based on them, but doesn't keep track of count... is that correct? And if so, I don't see that as a big problem) No, it's not counting them. They come in with the Interrupt, so it would not be hard to add.
Ok, so they keep coming in, even if the limits changed? That's what I wasn't sure about.... I'll check the code for that.
Question 2: I do see "energy" on displays related to the sensor. Such as your Instructable : www.instructables.com/id/Lightning-Detector-for-Raspberry-Pi-WeatherPi-Weat/ On the LCD display it shows "Energy". Also on the spec sheet indicates it as well. Was this left out of your existing code? Is there an example or place where I could pull the code on how to read this value? You can easily read the value and add it to the code. Put it with the code that reads from AS3935 after it gets the interrupt.
Ok, so just do a read of the data from the registers... I'm a tad confused do I read the first two bytes and combine LSB and MSB, or do I do something with that last byte. I'm not sure I understand this part of the data sheet. Question 3: As you can see in picture below, I 3-D printed out the case, so the set up matches your instructions for setting it up with a Raspberry Pi with Grove Hat and Grove LCD, Buzzer and Sensor. The code however, leaves the LCD on continuously. That seems to be a lot of wear and tear on that... I know when mine restarts the text is fairly faint and doesn't really get readable for a bit. Is that expected? The colors are useful of course (in mine you can see that I caught it as orange/red during a strike) Now that is odd. We haven't seen that. You could turn it off and then just wake it up for the lightning but that doesn't sound all that useful. Does it do this after a reboot or after a power on/off cycle?
It's mostly apparent after a power cycle. On a reboot, it might drop down a little bit, but not as bad as if it's had time off. Almost as if a CAP is slowly charging and then it finally gets back to somewhat normal contrast. I didn't see any contrast adjustment in HW or SW.
Question 4: I am trying to figure out the proper placement of the device. Having it outside (and having the buzzer connected) doesn't provide the best solution. Having it inside and having buzzer go off in the middle of the night (or if power goes out) isn't a great answer either. As you can expect, i have the buzzer disconnected right now :-) Where do you recommend it being placed? I might have one window sill it could go on... is that a reasonable solution? If so, do you recommend the "set_indoors" to be set to True or False if it's on a Window sill? I don't even like the buzzer. Window sill is good. I would guess that it should be set_indoors to False, but it more depends on how far away your electronics in your office are away from the sensor. (phone, monitors, computers, etc.).
Well I'm glad about the buzzer :-) . I'd suggest that the code be updated to have a time window when it buzzed. I.e. from 9 to 5. Or something like that. That might be useful.
Anyway, I'm trying to understand what the "set_indoors" does. Where I had it, the readings I was getting were all when lightning was occurring..and I've not seen random firings otherwise.. There are a bunch of computers not too far from it, but I haven't noticed anything that seems to be a "random firing". At least there has been lightning around when it's gone off. But I don't understand all the relationships here... could noise floor have risen to compensate, etc?
FYI -- The numbers were in the 200's, but I simply don't know if that was correct, if I counted cloud to cloud, etc. I don't have any experience to know if it was a "reasonable" value, given the storm.
Question 5:
Today during the storm, with indoors set to False, I got a lot of hits. In the 200-300 range. Is that a "reasonable" expectation?
(I have Minimum_Strikes set to 1, which I "believe" indicates that it only takes 1 strike to trigger the interrupt that there was lightning... that correct? From code it "looks like it") I got it saying Lightning 34km away as well.
set_indoors is probably reading a bunch of noise from your devices.
See above. I'd really like to know what behavior change I could expect if I make this change...
Question 6:
I had to restart the device a couple times today (was tweaking the code) so I never saw if the Last Result ever resets. From looking at the code, it doesn't seem that it ever does. What is the best way to detect that Lightning is detected and when is a reasonable time to "stop" displaying that it's Lightning in the area? Set some flags in the try loop? Base it on color changing on display? Or??
I would set up a time based reset. Say if it has been 30 minutes and then reset it.
OK, I'll see about doing that.
Should I try to submit the changes back to you, code wise?
BP
|
|
|
|
Post by SDL on Aug 8, 2020 15:55:47 GMT -8
Question 2: I do see "energy" on displays related to the sensor. Such as your Instructable : www.instructables.com/id/Lightning-Detector-for-Raspberry-Pi-WeatherPi-Weat/ On the LCD display it shows "Energy". Also on the spec sheet indicates it as well. Was this left out of your existing code? Is there an example or place where I could pull the code on how to read this value? You can easily read the value and add it to the code. Put it with the code that reads from AS3935 after it gets the interrupt. Ok, so just do a read of the data from the registers... I'm a tad confused do I read the first two bytes and combine LSB and MSB, or do I do something with that last byte. I'm not sure I understand this part of the data sheet. Screen Shot 2020-08-07 at 2.40.34 PM.png
From the Spec (you use all three registers):
Energy Calculation
If the received signal is classified as lightning, the energy is calculated. The result of the energy calculation is then stored in the registers REG0x06[4:0], REG0x05[7:0] and REG0x04[7:0]. This value is just a pure number and has no physical meaning.
Anyway, I'm trying to understand what the "set_indoors" does. Where I had it, the readings I was getting were all when lightning was occurring..and I've not seen random firings otherwise.. There are a bunch of computers not too far from it, but I haven't noticed anything that seems to be a "random firing". At least there has been lightning around when it's gone off. But I don't understand all the relationships here... could noise floor have risen to compensate, etc? FYI -- The numbers were in the 200's, but I simply don't know if that was correct, if I counted cloud to cloud, etc.I don't have any experience to know if it was a "reasonable" value, given the storm. Question 5: Today during the storm, with indoors set to False, I got a lot of hits. In the 200-300 range. Is that a "reasonable" expectation? (I have Minimum_Strikes set to 1, which I "believe" indicates that it only takes 1 strike to trigger the interrupt that there was lightning... that correct? From code it "looks like it") I got it saying Lightning 34km away as well. set_indoors is probably reading a bunch of noise from your devices. See above. I'd really like to know what behavior change I could expect if I make this change... Take a look at this video that Dr. Shovic put together: www.switchdoc.com/2019/08/tutorial-skyweather-lightning-detector-tuning/BP |
|
|
|
Post by earlthesquirrel on Nov 6, 2020 8:18:59 GMT -8
Ok, I've finally had some time to do some digging on Lightning Detector. Got a chunk of the messaging in place. In my research I also found some other packages that work directly with this chip, and especially found this link : github.com/pcfens/RaspberryPi-AS3935/blob/master/RPi_AS3935/RPi_AS3935.pyIt's another python library for this chip. And it very, very closely matches SDL_Pi_Thunderboard_AS3935.py I'm suspecting you both started from code perhaps provided by the chip (or a similar common origin).
The only differences are : the SDL version has a "runCalibrarion" function and theirs doesn't, theirs has a energy function (which I've added to mine -- since that's one thing I was wanting), SDL has a couple support functions which it doesn't.
I compared all the other functions and they match (in terms of the register values being read and written 99% -- there is one difference) The only values different are in the set and get Indoors functions -- they DIFFER on the values they are setting :
def get_indoors(self):
"""Determine whether or not the sensor is configured for indoor
use or not.
Returns True if configured to be indoors, otherwise False.
"""
self.read_data()
if self.registers[0x00] & 0x10 == 0x10: <<<<< They use 0x20 == 0x20
return True
else:
return False
def set_indoors(self, indoors):
"""Set whether or not the sensor should use an indoor configuration.
"""
self.read_data()
if indoors:
write_value = (self.registers[0x00] & 0xE0) + 0x12 <<<<< They use 0xC1 | 0x24
else:
write_value = (self.registers[0x00] & 0xE0) + 0x0E <<<<< The use 0xC1 | 0x1C
self.set_byte(0x00, write_value)
So, I'm trying to know which are correct. I'm watching the video to see about the calibration... more comments after I'm done with that.
Earl
|
|
|
|
Post by earlthesquirrel on Nov 12, 2020 12:00:47 GMT -8
Any update/feedback??
|
|
|
|
Post by SDL on Nov 17, 2020 12:55:14 GMT -8
I don't see any issues with what you are doing. Do you have some comments after you calibrated it using the video?
BP
|
|
|
|
Post by earlthesquirrel on Nov 18, 2020 12:10:42 GMT -8
The outstanding question as to what the correct CODE should be.
Which value(s) are correct? The two packages disagree.
|
|
|
|
Post by SDL on Nov 20, 2020 18:49:46 GMT -8
Ah, I didn't see your comments in the code.
if self.registers[0x00] & 0x10 == 0x10: <<<<< They use 0x20 == 0x20
return True
0x20 is correct! That is a mistake in our code.
self.read_data()
if indoors:
write_value = (self.registers[0x00] & 0xE0) + 0x12 <<<<< They use 0xC1 | 0x24
else:
write_value = (self.registers[0x00] & 0xE0) + 0x0E <<<<< The use 0xC1 | 0x1C
self.set_byte(0x00, write_value)
It should be 0xE0 | 0x24
and
0x0E | 1C
Both codes are wrong! I'll fix ours shortly.
Thanks for pointing this out. Could explain some strange results.
BP
|
|
|
|
Post by SDL on Nov 20, 2020 18:56:58 GMT -8
Updated drivers on GitHub.com/switchdoclabs
BP
|
|
|
|
Post by earlthesquirrel on Dec 29, 2022 12:17:52 GMT -8
Another update --
I'm building out the thunder sensor in the Weather Sense set up, and I see the following values in SDL_Arduino_Thurnderboard_AS3935.h
// register access macros - register address, bitmask
#define AS3935_AFE_GB 0x00, 0x3E
AND
// other constants
#define AS3935_AFE_INDOOR 0x12
#define AS3935_AFE_OUTDOOR 0x0E
And in SDL_Arduino_Thunderboard_AS3935.cpp I see :
void SDL_Arduino_ThunderBoard_AS3935::setIndoors()
{
registerWrite(AS3935_AFE_GB, AS3935_AFE_INDOOR);
}
void SDL_Arduino_ThunderBoard_AS3935::setOutdoors()
{
registerWrite(AS3935_AFE_GB, AS3935_AFE_OUTDOOR);
}
Which looks like the same bug. Am I correct here?
|
|
|
|
Post by SDL on Dec 29, 2022 15:04:31 GMT -8
Same bug!!!
BP
|
|
