The analogue channel frequently (approx 10% of the time) gives incorrect readings, often 4.37, or 0.03. I’ve wired to the HAT 3.3V and 5V sources as well as a 1.5V battery. I’ve also tried tieing unused channels to ground, and confirmed similar behaviour on all channels. Attached screenshot shows very simple code which reads and prints every 2 seconds with the inut tied to the Pi’s 5V. The white LED also blinks despite constant voltage. Please help.
The Pinout is here,
If your not plugging it directly onto the Pi’s GPIO, make sure you have all the grounds connected. At least all the ones with a black marker in the pinout I posted.
Thanks for reply. To be clear the hat is directly connected to gpio. The behaviour occurs even if the signal is directly wired to the pi. I found a similar post but there was no reply. One thing to note is that the white led occassionally blinks off even when connected to steady 5v so I suspect this is electrical not software.
Ok, I wasn’t quit sure how you had it hooked up. Missing a ground connection can cause weird things to happen if you had been using jumpers etc.
I have one of the smaller automation pHAT’s and just ran the same code. Input is 100% steady, so I suspect it could be a faulty HAT. I attach a similar post from Mar 26 from CasaJizoh which is the same problem. I f I don’t get a response to this post I will contact customer support directly
On the main Shop page, there is a contact us link at the bottom. Click that and you can e-mail tech support directly. I’d also put a link to this thread in the e-mail. That should speed things up and get somebody from Pimoroni to post back here.
Hey, I’m having this same issue. I’m guessing it’s also the issue encountered here and maybe here. I’ve followed the troubleshooting steps taken so far by the earlier users, and I’m starting with a clean and up-to-date Raspberry Pi OS before installing the Pimoroni python libs.
My test setup is as shown below:
I have a hat with an ADS1115, judging by the “BOGI” marking.
Like jpkelly, I’m finding that grounding the unused analog channels doesn’t make the problem go away. The 5V reading still seems to jump around the channels as reported by the automationhat.analog.read() method, with the while loop of “analog.py” modified to read and report all four channels. Here’s that loop:
while True:
one = automationhat.analog[0].read()
two = automationhat.analog[1].read()
three = automationhat.analog[2].read()
four = automationhat.analog[3].read()
print(one, two, three, four)
time.sleep(0.5)
and here’s some sample output:
0.02 4.5 4.5 0.57
5.06 5.06 0.02 0.0
0.02 4.5 4.5 0.57
5.05 5.05 0.02 0.0
0.02 4.5 4.5 0.57
5.06 5.06 0.02 0.0
0.02 4.5 4.5 0.57
5.05 5.05 0.02 0.0
5.0 5.0 0.02 0.0
5.03 5.03 0.02 0.0
0.02 4.5 4.5 0.57
5.06 5.06 0.02 0.64
5.05 5.05 0.02 0.0
5.06 5.06 0.02 0.64
5.06 5.06 0.02 0.0
5.05 5.05 0.02 0.65
5.05 5.05 0.02 0.0
5.06 5.06 0.02 0.65
5.06 5.06 0.02 0.0
0.02 5.06 5.06 0.0
5.06 5.06 0.02 0.0
5.06 5.06 0.02 0.0
0.02 5.06 5.06 0.0
5.06 5.06 0.02 0.0
5.06 5.06 0.02 0.0
0.02 0.02 0.02 0.0
What’s really weird is how I’ve got the +5v wire on the “3” terminal, but the “1” and “2” lights are staying on, and these correspond to the channels that report ~5v. This makes me think the ADC channels might be getting twisted somehow. I don’t think the ads1015.py driver is to blame, as everything in there looks like it’s exactly what it needs to be. I’m getting sensible data out, it’s just getting put in the wrong places, and where it gets put is inconsistent.
There might be a connection routing issue on the circuit board, but this is unlikely given the reading is moving around when the wire’s in the same place. This might a gremlin resulting from the sample rate difference between the ADS1115 and the ADS1015, but given that the ADS1115 is reportedly a 2020 chip shortage substitute, and the earlier complaints predate this by a few years, I don’t think it’s that, either.
In concept, this hat’s exactly what I want to use for my application. Any advice on what I can do with my copy to get it working?
Interestingly, when I edit the sample rate map in ads1015.py to match the datasheet for the ads1115, the weird behavior goes away. Here’s that map:
SAMPLES_PER_SECOND_MAP = {8: 0x0000, 16: 0x0020, 32: 0x0040, 64: 0x0060, 128: 0x0080, 250: 0x00A0, 475: 0x00C0, 860: 0x00E0}
I then edited the first line of the ads1015.read() definition st. samples_per_second=860. My analog input scan loop now produces this:
0.02 0.02 5.05 0.58
0.02 0.02 5.06 0.57
0.02 0.02 5.06 0.57
0.02 0.02 5.06 0.57
0.02 0.02 5.06 0.57
0.02 0.02 5.06 0.57
0.02 0.02 5.06 0.57
0.02 0.02 5.06 0.57
I think the part where the ads1015.read() function delays the i2c read for a time determined by samples_per_second is causing mis-timed i2c reads from the ads1115 somehow, if the delay is less than the actual cycle time of the ADC. With the unmodified driver, read() calls might be getting data from earlier conversions. Just a hunch, can’t really confirm.
This hack is enough to get me working, but I’ll admit that it’s kind of a pain. It requires reading the tiny etching on the ADC to know what you’re working with, and modifying the driver files after install. For your product to work as intended, you might need to move the ADC disambiguation test to setup(), and set the sample rate map and default sample rate there.