When in continuous mode, first read returns previous pin value

[zacnelson]

Using an ADS1115 on a Raspberry Pi 4 with Python3.7

Test case:
p1 should return a value around 13200
p2 should return a value close to 0

ads.mode = Mode.CONTINUOUS
ads.data_rate = 860
p1 = AnalogIn(ads, ADS.P1)
p2 = AnalogIn(ads, ADS.P2)

output:

>>> p1.value
13185
>>> p1.value
13156
>>> p1.value
13186
>>> p2.value
13182    <-- incorrect
>>> p2.value
4
>>> p2.value
4
>>> p1.value
4        <-- incorrect
>>> p1.value
13194
>>> p1.value
13181

[zacnelson]

From my quick debugging it seems like this my be due to the fact that once the requested pin has been changed, it takes a certain amount of time for the ADS to recapture and convert the value. The library isn't waiting for this conversion time and instead returns what is in the memory address immediately.

[evaherrada]

@zacnelson Hey, are you still having this issue/did it ever go away? If you are still having it, I can try to take a look in a few days.

[zacnelson]

@zacnelson Hey, are you still having this issue/did it ever go away? If you are still having it, I can try to take a look in a few days.

It didn't go away. Based on the commit history it also doesn't seem to have been addressed since filing the bug. Thanks for looking into it!

[evaherrada]

@zacnelson Ok, just got the hardware. I'll try to take a look at this sometime today or tomorrow.

[evaherrada]

Ok, so I got it working, but I'm not entirely sure why, and I need to make the solution less janky.

So, in continuous mode, it just reads whatever was the last value calculated by the ADC, so if the last value was from p1, no matter if you're calling p1 or p2, it'll give you p1's value.

Now, I think there must be a better way to go about doing this, such as requesting the value from a specific analog port on the ADC, so I'll take a look at the datasheet to see how I'm supposed to do that.

[caternuson]

@dherrada FYI - the logic that is in place was done as an attempt to provide "fast" reads in a simple way without breaking the current API. There's a huge discussion here:
#27

[zacnelson]

@caternuson thanks for referencing that issue. I read through your development and the end goal makes sense - reduce I2C traffic overhead and get the data as quick as possible. If I understand it correctly, when we're in continuous mode and the pin doesn't change, then we just grab the latest value from the previously set data register. If the pin does change, then we update the ADSx accordingly and then get the latest value from a new data register: https://github.com/adafruit/Adafruit_CircuitPython_ADS1x15/blob/master/adafruit_ads1x15/ads1x15.py#L161.
In this way, continuous mode is really designed to read from 1 pin over and over. If I were to read back and forth from P1 to P2 then the returned data would never really be accurate.
One suggestion would be to wait the correct amount of conversion time before returning a result when the pin changes. OR return an invalid result or error until enough time has passed.

[evaherrada]

One suggestion would be to wait the correct amount of conversion time before returning a result

@zacnelson I believe that's essentially what single mode does.

[evaherrada]

@caternuson Do you think it'd be worth putting something in the README that mentions that using single mode is better for when you are reading multiple inputs?

[caternuson]

In this way, continuous mode is really designed to read from 1 pin over and over.

That's how I see it also. Since changing pins requires sending the updated mux setting out over I2C, it really limits the data read rate on multiple pins.

OR return an invalid result or error until enough time has passed.

The key here is how to make this determination. There's a status register that can be read, but that's more I2C traffic which slows things down. Better is to use the data ready pin somehow, but that soon becomes a discussion about interrupts.

[caternuson]

@dherrada Sure, that could help. There's also a "fast read" example that shows the general usage. It might even be worth a Learn Guide page to discuss the general issues with trying to read the ADS as fast as possible.

[evaherrada]

@caternuson Ok, I'll add a sentence or two to the readme and then add a new page to the existing learn guide

[caternuson]

I've recreated this issue. Which is weird, as I thought this used to work. Seems like maybe something has changed. I'll try and investigate also.