search

esphome / feature-requests

ESPHome Feature Request Tracker
https://esphome.io/
411 stars 26 forks source link

Auto-calibration for AS3935 #451

Open RichardDern opened 4 years ago

RichardDern commented 4 years ago

Describe the problem you have/What new integration you would like

Auto-calibration implementation for AS3935 lightning sensor would be a nice feature to have.

Please describe your use case for this integration and alternatives you've tried:

The AS3935 can be auto-calibrated. Inspiration could be taken from Embedded Adventures and their MOD-1016.

Maybe the calibration could be automatically done every x days or something.

Additional context

OttoWinter commented 4 years ago

As far as I see, there's two types of calibration:

First, the RCO calibration - both the TRCO and SRCO are separate oscillators on the chip that can get out of sync. A simple CALIB_RCO (0x3D) command (see page 23 of datasheet) calibrates that.

Second, there's the resonance frequency tuning - according to the datasheet (page 23) this needs to be within ±3.5% for optimal performance. It looks like the intended way is to sample at all 4 frequency division ratios and see which one gets closest to 500kHz.

But it doesn't look like the calibration would need to be done often - the datasheet says that the values are automatically compensated for temperature etc. Power cycles will clear those settings out though.

CC @TheEggi - do you know more about the AS3935 and its accuracy without tuning/calibrating?

RichardDern commented 4 years ago

Maybe it doesn't need to be re-calibrated often, but it needs to be at least once, otherwise Embedded Adventures wouldn't provide a calibration frequency specific to each MOD-1016 (a number between 0 to 15). Fortunately, they provide the source code for auto-calibration for people like me who have lost this number 😄

If something like scheduled auto-calibration wouldn't be done, maybe it would worth it to implement auto-calibration at boot time.

TheEggi commented 4 years ago

@OttoWinter the intended use was for an outdoor weather station and I have to say that I never had any thunderstorms lately. My tests were pretty much all indoor by just using a lighter, which at least triggered the IRQ pin - just by using the default values.

SparkFun did also not provide any of those functions in their libs - Some more details about the settings https://learn.sparkfun.com/tutorials/sparkfun-as3935-lightning-detector-hookup-guide-v20/all

RichardDern commented 4 years ago

That's why I linked the Embedded Adventures library: it is a bit more documented and features-rich, and works perfectly in a stand-alone Arduino project (the demo project provided in the repository).

OttoWinter commented 4 years ago

@RichardDern Yeah, but I would say let's get some empirical data on this first. If sparkfun didn't include this in their libs it probably doesn't make that big of a difference. I would suggest let's first have some users use the AS3935 and if it's inaccurate we can still do this.

RichardDern commented 4 years ago

Sparkfun do provide calibration example here.

marek-obuchowicz commented 3 years ago

I can confirm that without calibration, I couldn't get any lightings detected during several thunderstorms. I tried with various noise floor settings, but never managed to get it working.

I've measured oscillator frequency and when ~divided~ multiplied by div_ratio, i got ~510kHz, which is an optimal value according to the documentation (500kHz +/- 3.5%) so ~i~ no capacitance tuning is needed. It also means that it should have successfully detected lightings, which it didn't. I think missing calibration can be reason for this.

I've build a proof of concept implementation, which enables antenna trimming mode and basic calibration. Note, that for fully automatic calibration - we should enable trimming mode, measure frequency of signal from INT pin, multiply that by div_ratio and check if matches 500kHz +/- 3.5%, if not - adjust parameters accordingly. At the moment I don't have time and knowledge to implement antenna trimming. I've also checked AS3935 sensors I had in my workshop - both of them seem to work in optimal range, without need of any change - so I think that even though my PR solves calibration issue only partially, it could make situation better for users, who have sensors with correctly trimmed antenna frequency.

I haven't been touching C for a while, so please review and test https://github.com/esphome/esphome/pull/2084 thoroughly. My units have those changes in place and seem to work. Still need to wait for next thunderstorm to check, if sensor readings got better... Any help with unit tests is appreciated!

drawgas commented 1 year ago

Any chance we could revive this and get @marek-obuchowicz changes merged?

mveinot commented 1 year ago

Also requesting this code/feature be reopened/merged.

marek-obuchowicz commented 12 months ago

I can sadly only say that I do not have time/capacity to work on this, especially that it requires access to hardware which I don't have next to me right now. If someone can pick it up, I would be very appreciated, apparently this PR brings value to community, it would be therefore pity to have it not merged as it's "almost ready" and needs only small refactoring.

mveinot commented 12 months ago

I am attempting to take this up and get the changes cleaned up for resubmission.

mveinot commented 12 months ago

You can follow any progress here https://github.com/esphome/esphome/pull/5366

I've merged it against the current dev branch and implemented all the requested changes. It's gotten through the automated CI tests. Just waiting for a human code review.