That’s a winner! Lots of Pi stuff to learn.
I appreciate it.
Hi
glad you got it sorted mldenison learning curve for me too
Chris i am seeing a lot of disturbers in the event history log which is 20+mb in size on the pi4 and has as many as 7 per second but it varies the archive file is as large, is this related to adjusting watchdog_threshold and spike_rej or is there something else i need to adjust
Harold
It should be possible to reduce disturbers using the watchdog_threshold and spike_rej values.
All was going well Chris till reboot a few days ago, 
just getting connected like Asobig at start of thread, tried a few things, no joy, installed 3.1, same so today done a complete buster re-install from scratch and installed 3.1,.
I moved click board to position 1 and set config file to 00, still the same, what have I done #-o
Mine’s stable through several reboots.
It’s currently raining here with a lot of precipsw through the se of us (York on the map). As far as I can tell, any thunderstorm activity is south of us as well, perhaps 30 - 60 miles away.
As long as I’ve had the Pi up, there’s been no thunderstorms close by.
However, all perceived lightning strikes reported are at 0.6 miles away.
I’ve turned off the disturbers (quite a few) and increased noise from 1 to 2 which eliminated reported noise.
So I’m not sure if it’s reporting actual lightening strikes with incorrect distances or what.
I’m not sure what’s going on. My programs don’t update any config settings, other than for the current run. So once they’re shut down and restarted they are back to how the config file says they’re set up. I assume that the sensor comes up in either a default (or random) state when powered on so nothing should persist through a complete power down. So I’m a little puzzled why things seem to go wrong and then stay wrong!
I did wonder whether it might be different versions of libraries on different machines and maybe the machines are being updated when powered up again after being moved. However, I’m pretty certain that I’ve got all the latest modules and other updates applied to my Pi.
I’m still checking the code to see if I can see any potential pitfalls. I’ve found, and corrected, one thing so far. I don’t know what effect that might have had, but my system has been happily running with the wrong code. I’ll finish my code review and then publish 3.2 to see if that helps.
hi Chris
i could hear some thunder around 5pm and checked the web page on the pi4 (buster 8gb 128gb) although the page was viewable the info was from yesterday evening and the right hand side showed nothing, after a reboot the web page was working ok and was showing some strikes this unit supplies the nowcast to wd and that had not updated either till the reboot
the pi3+ (stretch 1gb 32gb) was updating ok but was showing no strikes
just checked the pi3+ again via web page and that appears to have stopped updating although still accessible but as above
this time i stopped the web service, stopped the monitor changed disturbers to masked true and restarted both and web page ok again have also changed the pi4 disturbers to masked true
the as3935_web.log on both units have no info at all in, but what ever happens part of the web server appears to stall so not sure what is the cause
Harold
My web server also locked up this morning. I restarted the Pi and is working fine again.
As per the lightening strike distances - no close by t-storms so all my hits are at .6214 miles which equates to 1.0000464 KM. Is that the max distance that’s reportable?
1km is the minimum possible distance and it effectively means the storm is overhead.
I’ve been doing a lot of digging into the AS3935 code today and have found a number of ‘improvements’. Some are cosmetic to make it easier for me to maintain. Some change the way some functions work, but seem to be correcting things that wouldn’t normally be used so are unlikely to be affecting people. There’s one, or maybe two, changes that might make a difference to how things are running for people. I’ve got a suspicion that one of them might prevent the apparent hang when starting the services up. I’ve got the changed code running on my Pi now so I’ll leave it overnight to see how it goes. In the hour before I put the new code in place I was seeing a lot of disturbers (250/minute over the whole hour!) I’ve been running the new code for 20 minutes and the disturbers have dropped back to 10% of the level of the previous hour. I’m taking that as a good sign.
If things go well overnight then I’ll package v3.2 up and release it tomorrow. It’s also got some new functionality in it as well as bug fixes.
hopefully 3.2 will work for me. For the life of me, I can’t get it to work. It will run on a fresh install, but not after a reboot
V3.2 ran overnight and I’ve just rebooted without a power off and rebooted with a power down and it came up automatically each time. Having said that mine always has.
I’m pinning my hopes on the addition of a sensor reset command that I’m now sending as soon as the monitor program connects to the sensor chip. I’d always intended to do this but I only noticed yesterday that I’d forgotten to add it in.
I’m hoping that different sensors start up with different, perhaps random, settings in the control registers. If there’s an important register that I’m not setting because it’s supposed to have the correct default value but it starts up with the non-default value in some chips then the reset command should set it correctly without me having to specifically set it. Maybe the register always sets to default on my chip?
I’m going to leave it running for an hour or so and then try v3.2 on a fresh build OS. Then it’s packaging and documentation time. Hopefully I’ll get that all done by about lunch time (UK) so we’ll be able to see how things go later on.
One last thing that I’ve just thought of as I typed this. Which socket do you have your Thunder Click board plugged into? Mine has always been in socket 2 and I’ve never tested it in socket 1. I’ve assumed that as there’s only a difference of address between 0 and 1 in the software that it was a trivial matter but maybe things behave differently between the two sockets. It should be the same but I’ll test it when I create the fresh build this morning.
Doing a new install of buster so I shall be ready to go, I always used socket 2, up to yesterday when I tried socket 1, will go back to 2, same as you Chris.
OK…I’ve found something big! I’m surprised that the software works at all when the Thunder Click is plugged into socket 1, even before a reboot. I misread the Pi Click Shield schematic and thought that the same interrupt (IRQ) was used for both sockets. Having swapped my board over to socket 1 and found it didn’t work I’ve re-checked and found that socket 1 uses GPIO6 and socket 2 uses GPIO26 for the interrupt line. The calibration and monitor programs both heavily use interrupts so with the sensor in socket 1 they shouldn’t work at all. I need to check why the auto-calibration function didn’t throw its dummy out of the pram though because it’s supposed to check that it gets a good value for the tuning capacitor and it could never get one with the wrong IRQ.
I need to do some re-coding so v3.2 will be delayed a little. Until then, if you have a Click Shield with two sockets try swapping the Thunder Click into socket 2 (power down the Pi first!) and see if things behave better for you.
Socket 1, In the log file Chris I was getting a warning auto-calibration failed, can’t remember the exact wording, I’ve re installed buster so can’t check log
I’ve checked the code. It did log a warning about calibration failure, but I was then setting a default of ‘8’ and carrying on which probably wasn’t the best thing to do. Now I log an error and end the program. If i’d done that before then people would have found the monitor wasn’t running and we’d have checked the log to see the calibration error. I don’t know if that would have helped track the error down sooner but maybe it would have done.
I’ve now fixed the code to use the correct IRQ for each socket and tested it. Next job is to complete my fresh build and then do a full re-install. I’ll check in socket 1 and 2 before v3.2 is released!
Whilst testing I think I found something that could cause problems after a reboot so I’m hopeful that I’ve fixed that now. I kept of trying to think of what persisted across reboots and I’ve worked it out now 
I’ve run tests with the Thunder board in socket 1 and that’s all working properly, even across a reboot. I’ve just swapped the board from socket 1 to 2 and with the config file modified to the new address everything fired up correctly first time.
I’m getting hungry now…so it’s lunch time. After lunch I’ll write some upgrade notes/modify the installation instructions and upload the new version.
Version 3.2 is uploaded and attached to the first message in this thread. That message also includes information (near the bottom) about how to upgrade if you have a current v3.0/v3.1 installation.
I’m hoping this proves to be more reliable for more people!
Installed Chris, working fine,got to move it now,set up wifi, hope that stops all these disturbers