My sensor is in an awful place but I can’t really move it anywhere better at the moment. I have to have the Pi close to me to keep swapping the SD card over for fresh builds. I should get my second AS3935 wired up and connected to my WeatherPI and move that somewhere better. I’ve noticed that my disturbers seem to run at about 50% overnight so there’s clearly a human impact on the numbers.
He Chris,
Just installed the 3.2 version, running well.
I tried a lot of combinations in the settings to lower down the strikes, disturbers and noise.
At this moment i am running with the following settings:
Tuner capacitor setting: 4
Noise floor: 3
SREJ: 9
WDTH: 11
This keeps most disturbers end noice down, but i am not sure that this is not too much and deafens the sensor.
Any advice on this?
Those sound pretty severe. I’m not really sure what can be done to reduce the values though. I think it’s either down to siting the sensor in a quieter location or finding the sources of disturbers and trying to reduce those. If the disturbers are coming from outside your own property then there might not be much you can do.
Maybe as we get more people using the sensor someone will find ways of improving things?
Something that someone might like to try is to take the event_history archive file, load it into a spreadsheet and analyse the data. That might identify some ‘clusters’ of disturbers at specific times that might be identifiable. For example, spikes in disturber numbers at around the time a heating/cooling system turns on, or maybe in the evenings timed when a favourite TV show is on with the disturbers coming from the TV. The analysis would be different for everyone, but it should be possible to create a spreadsheet that anyone could load their data into and get a plot showing ‘disturbers/min’ against time.
Having found the potential source of a disturber you can them experiment to see if it goes away if you turn it off (if it can be turned off) or change when it’s turned on. That doesn’t necessarily mean you can get rid of the disturber but if you can find what causes the disturber you might be able to find somewhere further away from it to site the sensor…which of course might then be near a different disturber #-o
tried to do the upgrade route and get this when I check status of web service
● as3935_web.service - AS3935 Web Server service
Loaded: loaded (/lib/systemd/system/as3935_web.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2020-08-01 09:33:48 MDT; 5min ago
Process: 786 ExecStart=/usr/bin/python3 /home/pi/Sensors/as3935_web.py (code=exited, status=1/FAILURE)
Main PID: 786 (code=exited, status=1/FAILURE)
Aug 01 09:33:45 raspberrypi systemd[1]: Started AS3935 Web Server service.
Aug 01 09:33:48 raspberrypi python3[786]: Traceback (most recent call last):
Aug 01 09:33:48 raspberrypi python3[786]: File “/home/pi/Sensors/as3935_web.py”, line 79, in
Aug 01 09:33:48 raspberrypi python3[786]: for read_line in event_history_csv:
Aug 01 09:33:48 raspberrypi python3[786]: _csv.Error: line contains NULL byte
Aug 01 09:33:48 raspberrypi systemd[1]: as3935_web.service: Main process exited, code=exited, status=1/FAILURE
Aug 01 09:33:48 raspberrypi systemd[1]: as3935_web.service: Failed with result ‘exit-code’.
How big is your event_history.log file? If it’s not too big are you able to send me a copy to look at?
If you edit the file then the first line of the 31st July has a lot of (probably) null characters at the start of the line. I don’t know where they’ve come from but for now remove them and the service should start up. I’ll look to put something in the code to trap the file having what I assume is data corruption in it.
I’m running with WDTH at 6 and still see about 20 disturbers per minute.
Set mine to 6 as well. I also moved it outside as a test.
ran a test for just 5 minutes. this is what I get
That’s a great improvement by going outside.
it’s still only about 1.5 meters from the house. Later I am going to test a location about 6 meters from any building. I just have to get an extension cord to reach that far.
If this works out, I was thinking about putting the pi in a weather proof enclosure, however, I am concerned that it could build up too much heat. Any suggestions?
Moved mine to other side of house, its a bit under the solar pv panels 
did think garage as there is a network switch there but solar inverter and Gas Boiler there to, with ignition sparking, got to be bad.
using
noise floor = 3
SREJ =7
WDTH = 9
stopped disturbers, will try lowering a bit more, wifi no good, had to run cable along floor to test
Update
noise floor = 3
SREJ =6
WDTH = 8
now seeing noise detected
Now I have moved it further away from the house ( about 4 meters) and set location to outdoors and lowered the WDTH to 2.
I am now seeing great results after about 8 minutes.
I’ve been thinking (which is always dangerous!) and I’d welcome your opinions on this topic too. I’m not sure that we really need to be aiming for zero disturbers, just not hundreds per minute, but even that many might not be a big problem.
My understanding is that each time the sensor hears a significant noise it has to do some processing to determine whether it’s real lightning or a disturber (fake lightning). The AS3935 specs say that it can do this processing in about 2ms, so technically it could handle about 500 ‘events’ (real and/or false) per second. I doubt that any earthbound storm could generate lightning strokes at that kind of frequency and even if it did I think I’d be hiding somewhere thinking it was the end of the world if such a storm was nearby! Let’s assume that the sensor can really handle about 400 ‘events’ per second.
What you don’t want is so many disturbers flooding the sensor that it’s busy dealing with junk when a real stroke of lightning turns up. If you were seeing one disturber per second then you’d be be consuming 1/400th of the sensor’s processing capacity so it’s more than likely that the sensor will be able to see real lightning when it turns up. In my case if I set SREJ and WDTH to low values with my Pi located 4 inches from my laptop, 8 inches from my Davis console, 8 inches from another Pi, 4 inches from an extension cable, etc, I see about 250 disturbers per minute (approx 4 per second). Even now I’m only consuming about 1/100th of the sensor’s processing capacity which isn’t a huge amount and should mean that 99% of the time the sensor will see a real stroke when one appears. So from a sensor perspective I don’t think that 250 events per minutes is a terrible number, even though it sounds horrendous.
We’ve also got to bear in mind that, if not masked, each disturber needs some processing time on the Pi. I don’t really know what the maximum capacity of my software is in terms of events per second. I know from experience that it can handle at least 4 events per second, but if, for example, it can only handle 5 events per second then if it’s busy dealing with a stream of 4 disturbers per when the interrupt goes off for a lightning strike there is the possibility that my software will miss that interrupt and therefore miss the lightning stroke. I have a nagging feeling, but no easy way to test, that the ‘unknown reason code = 0’ log entries that we see relate to event interrupts happening too fast to be handled by my code. The way to test that would be to re-code everything in C/C++ and see if things worked better with no code zeroes. That’s way too big a job for now so not something I’m going to do.
So what I’m going to suggest is that we don’t get too hung up by the number of disturbers we’re seeing. Perhaps we look at it this way…
- Start with disturbers unmasked
- Use the number of disturbers per minute shown in the stats as an analytical tool
- Firstly see if you can identify any causes of disturbers that you can affect, e.g. you’ve got a sparky motor nearby that needs servicing and fixing.
- See if slightly higher values of WDTH and/or SREJ can significantly reduce the disturbers per minute. For example, with WDTH=2 you see 200 disturbers per minute but with WDTH=3 that drops to 100. Then increasing WDTH upwards from 4 to 8 only drops the disturbers to 80. I’d say stick with the benefit of WDTH=3 and a slightly reduced lightning distance capability rather than setting WDTH=8 and getting a worse lighting detection capability.
- Having reduced disturbers as low as possible by solving the problem at source and increasing WDTH/SREJ then just turn ‘mask disturbers’ on. The sensor will still see them and have to deal with them, but probably at a rate that it can easily handle and also at a rate that means it’s fairly unlikely that a disturber and real lightning will happen at the same time and cause the real lightning to be missed. Masking disturbers means that my software doesn’t have to deal with lots of unnecessary false events meaning it will be more ready to deal with a real stroke and it also means that your log files will be much smaller.
So, that’s my thoughts. The ramblings of a crazy man or something worth trying? Let’s hear your opinions…and I’m happy to have possible/real errors in my thought process discussed!
Of course, the best way to know about this is to use the sensor in a real storm, but this isn’t a good year for them here. It’s not a hot summer (so far) so no big storm clouds around to rub up against each other to build up that static charge :lol:
I think I have solved my issues. With the WDTH set to only 2 and location set to outdoors. I see very little noise and Disturbers after 40 minutes
That’s really good. I assume that 4m from your house isn’t a good place to locate it though?
One other thing I forgot to mention in my last post is that it should be possible to get the sensor further away from the Pi, although perhaps not far enough in your case. If we were to use one of these… SparkFun Lightning Detector - AS3935 - SEN-15441 - SparkFun Electronics then it could be put on the end of a cable. Not a long cable though. I’ve seen different numbers quoted for unassisted SPI bus cables, but they seem to be between 3m and 5m maximum. 3m might be enough to get the sensor a bit further away from the worst of the noise and it might work OK on 5m of cable. The other thing to bear in mind is that the sensor needs to be powered, but as it draws tiny amounts of current, i.e. less than 1mA at it’s most hungry, I’m pretty sure that you could stick 3.3v down a few metres of Cat5/6 cable and still have enough voltage/current at the other end to run the chip. It does have an LED so that will also add to the current requirement, but probably not significantly.
I have one of the Sparkfun boards but haven’t yet had a chance to try wiring it up to a Pi.
Actually, I’m not thinking very well. The Thunder Click board could also be put on the end of a cable. It doesn’t need to be plugged into the Click Shield. With a suitable cable (probably needing soldering skills) it could be connected directly to the relevant Pi GPIO pins.
Maybe someone might like to try experimenting by putting one of these boards on the end of some different lengths of cable to try to find out what works and what doesn’t. Just be careful though, if you’re wiring direct to the GPIO connector then if you get the connections wrong you might fry the sensor!
All I did was run a 25 meter A/C extension to the Pi power supply. It’s still well inside the range of my WIFI so all is good
Another thing I was thinking of doing later on what connecting a sparkfun board to a ESP8266 ( I have a few of them around here)