-
...absolutely! (My earlier - now dropped - code was wrong in this respect).
Initally, my guts wanted to go for your formula as well - and was also part of the reason to store the users provided value with a skalar and proportianly reference to the actual value vs irregular config value - but my reasoning got messed up for some other reason and overrode my guts...
The other part of reasoning was: if the object stores the translated property, it cannot be asked what the config was, because the GAINS 'table' object is inaccessible form the outsite and would require an extra method (getGain) to get the gain value back...
Above paragraph is a segue way into the postponed discussion of the value of the CONFIG object as integrated part of the runtime module:
Since the CONFIG object is not accessible for the app, it is useless... sounds harsh, but is true. I like the idea of having a nicely crafted CONFIG / options object with well named properties... but it's unavailability to the app makes not just useless, but worse: a resource freezer. It is very well compacting, but still of no use. It requires a new module... That was the reason to put config stuff into a separate module with methods to pull the desired values. Therefore, I'd still would like to go back to a ADS1x15BB - bare bones - and a ADS1x15Cfg - config - module, and the bare bones module with the optional config parm available in connect() and getADC(); I would keep it interface compatible with existing ADS1x15 module - in respect to connect(), getADC(), and (if insisted on) setGain() - to have it interchangeable, but slim down the internals.
Obviously I can't test, but am I right in thinking that the actual voltage should be
value * ads.gain / 32768000
?