I hadn’t really paid much attention to indoors v outdoors before, but now that I’ve looked what you’ve found makes sense. I had assumed, incorrectly, that the indoor setting set the front end gain lower than for outdoors due to the increased possibility for electrical noise indoors. ‘Front end gain’ is how much the signal from the antenna is amplified before being processed. In electrically noisy environments it’s usual to set a lower gain because that amplifies the noise as well as the signal you’re looking for. However, the AS3935 does it the other way round. It sets a higher gain for indoors, presumably because the walls of the house attenuate the lighting ‘signal’ to some extent. That does show that a higher gain amplifies the noise because you see all the extra disturbers/noise on the indoor setting. I’m also not sure how much house walls attenuate signals at 500kHz. I wouldn’t have expected very much, but the board does have a very small antenna for such a low frequency.
I added a function, as yet unused, in v3.2 that allows some additional tweaking of the front end gain (AFE_GB in sensor language). We can currently only use two gain values…indoors = 18 and outdoors = 14. The new function I added will allow any value between 0 and 31 to be set for the gain, although I’d expect the extremes of these to either be way too noisy (31) or way too deaf (0). However, it should be possible to set the gain to say 16, i.e. half way between indoors and outdoors. This would gain sensitivity, i.e. ability to hear more distant lightning at the expense of some more noise, but not as much noise as with the indoor setting. I’ll add a config file option to tweak this into v3.3 so that anyone can experiment and see what effect it has.
I want to do something similar too. I’d considered the ESP8266 (I have one in my electronics ‘toy’ box) but as it uses WiFi it would need a reasonable power supply (not as much as a Pi though). I was therefore considering using something like a nRF52840 coupled with either a RFM69 (868MHz relatively slow data speed) or LORA board (same band but higher speed/better distance). These would both need a receiver to collect the data, but I would add something suitable, probably connected to a Pi. The advantage of using RFM69 is that it’s very low power (the Davis ISS uses RFM69 to get data to the console) so I could build a small nRF52840 + RFM69 + AS3935 that could be powered by a solar panel plus rechargeable battery. I’d also like to build other low power radio connected devices so using RFM69 would probably work for them too.
hi Chris
just got both pi’s updated to 3.2 by 21:00
had a clap of thunder about 21:30 bst with downpour
pi4 failed to pick any lightning at the time watchdog was at 3, spike was at 4 and noise was 5, reduced the spike to 3 but now back at 4, disturber set to true but now set to false, pi4 is on a shelf near the ceiling
pi3+ picked up some lightning around 21:30 but not the clap i heard, at the time watchdog was at 3 and spike at 4 noise was 4 disturber set to true the pi3+ is just sitting on the floor
both pi’s are still in the same room at present
i notice with v3.2 that the stop command to stop the monitor service takes between 1 and 2 minutes on both pi’s, the web service stops within a few seconds on both, but just to prove me wrong (23:15)just stopped pi4 monitor to increase the values and it only took a couple of seconds
I’ve tweaked my settings and may be getting reliable info. I have it set for Outdoors even though it’s indoors. I see where it tweaked the capacitance a bit.
Here’s what I’ve got in the last few minutes. There’s a storm cell sw of me but I think it’s a tad further than indicated - no thunder.
2020-08-01 19:27:01 Strike at 3.7 mi. with energy = 28180
2020-08-01 19:26:33 Strike at 3.7 mi. with energy = 28114
2020-08-01 19:26:11 Strike at 3.7 mi. with energy = 39209
2020-08-01 19:25:33 Strike at 3.7 mi. with energy = 50875
2020-08-01 19:25:28 Strike at 3.7 mi. with energy = 38217
2020-08-01 19:25:11 Strike at 3.7 mi. with energy = 29705
2020-08-01 19:24:55 Strike at 3.7 mi. with energy = 47992
2020-08-01 19:24:49 Strike at 3.7 mi. with energy = 37566
2020-08-01 19:24:33 Strike at 3.7 mi. with energy = 38994
2020-08-01 19:24:17 Strike at 3.7 mi. with energy = 53538
2020-08-01 19:24:11 Strike at 3.7 mi. with energy = 39746
2020-08-01 19:24:06 Strike at 3.7 mi. with energy = 50721
2020-08-01 19:23:44 Strike at 3.7 mi. with energy = 3991
2020-08-01 19:22:49 Strike at 3.7 mi. with energy = 32730
2020-08-01 19:22:33 Strike at 3.7 mi. with energy = 38620
2020-08-01 19:22:11 Strike at 3.7 mi. with energy = 38189
CPU Temperature (Max = 180 degF) 97.7 degF
Units us
Distance of last stroke 3.7283999999999997
Energy of last stroke 0
Minimum strikes before interrupt 5
Set for indoor use? false
Analog Front End Gain Boost 14
Watchdog Threshold 1
Spike Rejection 3
Noise Floor 1
Disturbers masked? true
Tuning Capacitor Setting 10 (80pF)
The error with a null byte in a (corrupt) CSV file is now handled (in what will eventually be v3.3). There are probably other CSV file corruptions that could also trip the programs up but it’s difficult to handle those without knowing what they might be.
This could be a tricky one to track down because I can’t currently replicate the problem. My monitor program is taking less than a second to stop. Has anyone else seen this and if so do you have any clues about any specific things that happened before it was slow to shut down?
v3.3 has a new optional setting for the AS3935 - front_end_gain. If defined it can take a value from 0 to 31 and use this to set the AFE_GB (Analog Front End Gain Boost). It overrides the indoors/outdoors setting and allows a finer control of the front end gain. Whilst any number between 0 and 31 can be set it’s highly likely that numbers near 0 will mean the sensor won’t hear anything and numbers near 31 will cause the sensor to be overloaded with local electrical noise. I suspect, but have no easy way to prove, that useful settings will be between 12 and 20.
I’m currently running my system with AFE_GB = 15 which is between the indoor (18) and outdoor (14) settings. I’m seeing slightly more disturbers than with the outdoor setting but a lot less than the indoor setting so I think it’s working as I intended.
the long stopping of monitor service has only started since putting version 3.2 on and sometimes it’s fast and other times it’s slow so i agree not an easy one to track down
the pi4 has now been set to outdoor and watchdog and spike both set to 4 at the moment and only getting 20-30 disturbers per hour instead of 1000 and have reenabled the WIFI so will try some different locations over the early part of the week
Yes. It doesn’t have a header record but the values in each row are:
epochtime - Unix seconds since 00:00 on 01/01/1970
timestamp - Time in whatever time you defined in the config file, e.g. YYYY-MM-DD HH:MM:SS
event type - One of strike, sim_strike, disturber or noise
distance - Stroke distance in km if event_type is strike or sim_strike. Otherwise 0
energy - Stroke energy if event_type is strike or sim_strike. Otherwise 0
CSV format is ‘Unix’, i.e. values are in quotes separated by commas
Quick question - Is anyone using the monitor-only version, i.e. not using the web server? No need to reply if you’re using the web server (full) version.
I’m wondering whether to drop the monitor-only version. It makes twice the work for me when testing/releasing a new version and I’m not really sure how usable it is because a fair amount of what’s done is through the web server. If anyone wanted to just use the monitor-only version they can easily install the full version and then disable the web server service so that it can’t run. The monitor-only version doesn’t save very much space…less than 15kb of space for the Python programs and perhaps a little more for the additional Python modules needed for the web server.
I’ve renamed my Pi to ‘Chicken Little’ since there appears to be a perpetual thunderstorm overhead.
I haven’t played around with the settings a lot.
That being said, I’ve tried the Pi in various rooms including the basement, first floor and second floor.
I have an Asis AiMesh router system set up with 2 AiMesh nodes. I’ve switched those off to see if a node in close proximity with the Pi is swamping the Pi. Nope - no discernable effects.
I’ve tried with various ceiling fans on, then off, with no effect.
I’ve also unhooked the Pi cooling fans with no difference.
All I ever see is multiple reported lightening strikes between .6 miles and 3 miles. It’s happening as we speak and there’s no rain withing, say, 100 miles of me.
I had to turn off the disturbance reporting as they’re numerous, to say the least. I’m running a noise floor of 1 and no noise is reported.
The only thing noted is 0 energy of any strikes. If I could mask any strikes of 0 energy, maybe that would cure it - or at least mask it.
I would strongly suggest that you try it outside. I had a similar problem like you. As soon as I placed it outside, almost all of the problems disappeared.
I hunted Google for a small vented outdoor box, preferable with an AC cord. All I could find was $100 and up.
I’m going to try it in the morning, for a while. I was hoping for an indoor solution since I have the temp-humidity-pressure board and wanted some indoor readings from that without investing in another Pi.
I now have the nowcast.txt file being ftp’d to my PC’s wdisplay/download folder. It’s showing up as nowcast.txt through nowcast5.txt. I’m not sure if this is correct.
How do i get the info into my Saratoga based site?
The box I used ( I had one here) was a 6x6x4 junction box (home depot sells them). I cut a 1" hole on the botton and covered it with a small piece of screen to keep the bugs out.
I don’t think the saratoga template has the option to display it without writing your own code. However, the Alternate template does. You can see it here ( Weather Calgary - Home )
Mort - are you able to run it outside for a few hours on a dry day to see if the disturbers are better (or worse!) outside. You also asked about an option for ignoring strikes of less than a certain energy. That shouldn’t be difficult to do…I’ll add it to the list of things for v3.3. I must admit the I’m puzzled about strikes being identified with zero energy though…it sort of defies logic. If it saw a strike how did it see it if it was so weak to have no estimated energy.
