SparkFun Forums 

Where electronics enthusiasts find answers.

Questions &/or issues related to products in the Environment category should be posted in this forum. Includes Air Quality, Altitude, Atmospheric & barometric pressure, Combo boards & other, Temperature & humidity, etc.
#207575
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:

1. 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.

2. 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.
#207663
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.