Is the duplicate call to delayAccToRate() in setCompareChannels() necessary?
rickwargo opened this issue · 3 comments
It seems there is a good-sized delay already (I recall you mentioning it should be the sample time) and this is more. If two delays are really necessary, maybe add a comment stating so, otherwise I'd be happy to offer a PR to resolve.
Hi @rickwargo, yes two times dealy is necessary (in continuous mode. It is two times the conversion time. The reason is:
- You can read the ADS1115 at any time and you will always read the value from last conversion.
- When you change the channel while a conversion is ongoing, the conversion will be completed first.
The consequence of 2) is that in worst case you have to wait for conversion period. After that, you will have to wait for another conversion period until the first value from the new channel is available.
If you want to change channels quickly, the single shot method is much better.
I have to admit that it looks like copy-paste error or so and I should add a comment and/or put it the delay in a for-loop.
Thank you for raising this.
Thank you for your quick response, @wollewald. That reasoning makes complete sense. Your library is very helpful as I am trying to squeeze the performance out of my two ADCs.
Perhaps there could be a override capability to not perform the delay and have the calling code be responsible for the correct delay. In a best worse-case scenario, at 860 SPS, it takes ~1,167 µSeconds to complete the conversion, twice that delay is only slightly more than the single delay of 2ms. And if code executed between the first conversion and the call to setCompareChannels, then just a little less time would be necessary.
Just a thought. Anyways, thank you again for your support of open source!
Hi @rickwargo, maybe I add a "continuous non-blocking" mode. On the othe hand, there is a simple solution, which is the single-shot mode. Will think about this. Thanks!