Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ADC reads incorrect values randomly. #16

Closed
piplup1222 opened this issue Jan 10, 2018 · 8 comments
Closed

ADC reads incorrect values randomly. #16

piplup1222 opened this issue Jan 10, 2018 · 8 comments
Assignees
Labels

Comments

@piplup1222
Copy link

I am doing a project for the company I work for to monitor when our shop doors are locked as well as collect temperature data. There is a prox sensor in each of the doors that monitors when the dead bolts are locked. They are 24V prox sensors that run 24V to their respective inputs on that hat when the door is locked. I have four doors, three of which are connected to the digital input and the fourth is connected to the first input of the ADC. The temperature reading is connected to the second ADC input. I created a threshold for the temperature to cure its random spikes and dips from the misreading of the hat, but ultimately cannot do the same for the door that is connected to the first ADC input. I have read different threads about how the LED is what is causing the issue, but I don't even power an LED in my code and it still doesn't work properly. I have attached an image of the graph of 48-hours of a door that has been locked the entire time that is never used. I have also attached an image of my python code.

python code image

door plot image

@Gadgetoid Gadgetoid self-assigned this Jan 19, 2018
@Gadgetoid Gadgetoid added the bug label Jan 19, 2018
@Gadgetoid
Copy link
Member

Regardless of whether you change the LEDs or not, the current Automation HAT library sets up a thread to keep them updated with the status of inputs/outputs.

The LEDs are attached to an i2c device and I believe having two threads accessing i2c simultaneously is causing a race condition/conflict whereby the response from one devices is misdirected to the other.

Among other changes, I'm currently rewriting the way this works to a use single thread and run the lights in lock-step with the ADC polling to avoid this problem.

@Gadgetoid
Copy link
Member

This is - hopefully- fixed in 0.1.0, give it a try and let me know: https://github.com/pimoroni/automation-hat/releases/tag/v0.1.0

@brvier
Copy link

brvier commented Apr 20, 2018

Unfortunatly i siill have the same problem in 0.1.0 while i didn t have with 0.0.4

this simple code show the error quickly

import automationhat
while(True):
    v = automationhat.analog.one.read()
    if a>1:
        print(a)

The adc one is wired to gnd. and quickly less than 3 seconds it s read value between 4.5 and 4.9

@truher
Copy link

truher commented May 12, 2018

i'm seeing the same thing. could we reopen this issue? wire adc one to 5v (the example in the doc), see mostly 5v but many readings near zero, or near 4v.

[edited]

ah, it's the "autolights" feature that screws this up. turning autolights off fixes it:

automationhat.enable_auto_lights(False)

yay!

@Gadgetoid Gadgetoid reopened this May 15, 2018
@Gadgetoid
Copy link
Member

The refactor of the way auto lights and the ADC reads co-exist should have fixed this problem- I'm going to have to investigate further. Have re-opened this issue accordingly.

@Gadgetoid
Copy link
Member

The bug is caused by interleaving threads. A classic race condition. My efforts to solve it were largely in vain because I wasn't fixing the right problem.

While it's not possible to trigger two consecutive ADC integrations, I believe what's happening is that the first integration (the process of converting an analog value into a digital one) is finishing, and then being overwritten by a subsequent integration trigger just before the first thread reads out the value. This causes an invalid value to be read occasionally (when the planets align).

I think I've found a proper fix for this that uses the status register to ensure no value is read when a conversion is ongoing. This may cause some readings to be delayed fractionally if the clobbering occurs, but should ensure their accuracy.

As suggested above by @truher if you're not using the fancy LED lighting effects, it's best to disable them altogether with automationhat.enable_auto_lights(False). This way the LED lighting routine wont ever clobber your readings.

Use threads problems you've got now two!

@ijustwant
Copy link

i'm seeing the same thing. could we reopen this issue? wire adc one to 5v (the example in the doc), see mostly 5v but many readings near zero, or near 4v.

[edited]

ah, it's the "autolights" feature that screws this up. turning autolights off fixes it:

automationhat.enable_auto_lights(False)

yay!

That fixed the problem for me as well :)

@premier-boats
Copy link

The fix to spurious voltage readings on the ADC channels seems to be working. With 0.1.0 of the automationhat library (fetched with apt-get) on node red, using @shortbloke's https://github.com/shortbloke/node-red-contrib-automation-hat, I was getting phantom readings to the analog inputs unless I disabled auto-lights.

Installing the automationhat library from by cloning from github, those readings are gone, so I no longer have to disable auto-lights. Though the library version still reads as 0.1.0. I'm wondering if there's plans for a release with this and other fixes over the last year so I can use this on my production system without a "cutting edge" patch to keep things reliable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants