I wanted to mention that the i2c connection using the Qwiic connector (does) work when connected to a raspberry Pi 3b+ using the Qwiic Pi pHAT.
I ran into only two problems:
-
The Qwiic connection became unstable when simultaneously connecting an i2c Relay board by Qwiic, so I had to use a USB attached relay board instead. By unstable I mean ‘consistently’ the AS3935 would fail to initialize or show up on the i2c bus then disappear. Using the i2c but (only) for the AS3935 seems to have eliminated the problem.
-
The Demo code for the Python library I am using absolutely required the Interrupt Pin to be connected in order to service the reports generated by the AS3935. One of the allures of the Qwiic bus is that you don’t have to do any soldering, but you do need to solder a wire from this to GPIO designated by your code… or use a test probe lead to make a connection. After that the demo code began reporting disturbers and lightning with leading storm distance.
My project I wanted to use CACTI to monitor Lightning strikes and respond by using a relay board to disconnect a DSL line when a threshold was reached. So far I have not been able to figure out how to do this.
The board likes to generate none periodic “Interrupt” reports, and cannot be polled for a counter or gauge version of the data.
For example:
A counter of how many lightning strikes per 5 minutes, 10 minutes or per hour.
A gauge of the the last leading storm distance measurement.
I think rrdtool databases can interpolate (some) on input for none periodic data… but cannot handle the wider random behavior of the AS3935 reports.
I would guess some code should be able to set, update, and periodically service clearing a polling register or buffer value in a file or socket… but I’m not sure of the correct way to do that wouldn’t block or randomly confuse CACTI if accessed at the same time it was being updated. I think a socket like a FIFO is the proper way to do it… but I’m not sure.
Hi jwillis84,
I just wanted to let you know that using I2C with the AS3935 is going to be problematic and erratic at times like you have noted in your first problem. This is due to some strange behavior from the IC that causes a kind of “hiccup” on the SDA line during initialization and communication. We did not notice it in our initial tests and production runs but as you can see from [this long post users were not able to get the sensor to properly initialize consistently via I2C.
We have since released a [revised breakout built to use SPI instead of I2C (although I2C is still technically available but just not supported) and have a new [Hookup Guide for using that version of the board. The previous, Qwiic version of this breakout is being phased out and will be retired from our catalog soon.
I hope some of this information helps you troubleshoot the issues you have run into or at least gives you a heads up on any possible issues you may run into using I2C with this breakout.](https://learn.sparkfun.com/tutorials/sparkfun-as3935-lightning-detector-hookup-guide-v20)](https://www.sparkfun.com/products/15441)](https://forum.sparkfun.com/viewtopic.php?f=105&t=49838)
Well I was making great progress… until apt-get upgrade really screwed up my install of raspbian.
The I2C bus was settled down and completely stable using the I2C only for that one detector (this seems untenable for some, but was okay for me). Of course I also power cycled once a day too… but it always came back up on the I2C.
I will look into SPI when I get a chance. I just ordered another Lightning detector from Sparkfun… hope it gets here soon.
On the data processing side… I found using Bash cmdline that
stdbuf python ./demo.py >> lightning.log &
Would generate a log and I could then grep for “km” to get a total count of strikes, regardless of the distance… I could compound grep to get single line counts for all of the distances since they are fairly chunky and not a smooth continuum.
Cacti installed fairly easily, setting it up to graph the script generate data points as a “counter” seems to be the ticket.
I’m working on Thold for cacti… and 1.32 is not compatible with 1.2 version of Cacti… so that is why I started to try a raspbian apt-get upgrade… big mistake. Its not debian that’s for sure… the repos trashed my install. So I had to restore the microSD card from a backup and start again.