ADS1115 channel results sporadically mixed

[chunter1]

I just updated an ESP8266 with an ADS1115 connected to release mega-20200703. Now i got the issue, that the results of the two configured channels on the ADS1115 get sporadically mixed.

Input multiplexer of the first channel is set to "AIN0 - GND (Single Ended)" Input multiplexer of the second channel is set to "AIN3 - GND (Single Ended)"

[uzi18]

Please show your task settings

[TD-er]

How is the data gathered? From within rules, or sent via a controller?

[chunter1]

Data is sent via two controllers to two separate FHEM servers using FHEM HTTP protocol. I just tested the previous releases and the last release that seems to work correctly is "Release mega-2020-03-01".

Please find attached as example one of the two task configurations.

[TD-er]

If it is sending 'sporadically' the wrong version, how long have you tested the supposedly correct version?

[chunter1]

So far only around 2 hours. You can see the stable line since two hours as compared to the faulty changing states before. Same pattern applies to the second channel. No change in configuration, just different firmware releases.

[uzi18]

So you have 2 tasks and you shown only one task configuration

[chunter1]

So you have 2 tasks and you shown only one task configuration

As mentioned before, the other task is configured exactly the same except "AIN3 - GND (Single Ended)".

[TD-er]

So to summarize:

• There are 2 tasks, operating on the same plugin.
• Task 1 does sometimes get values configured from the input configured in task 2 and vice verse.
• Both tasks send out their data via a controller (FHEM HTTP)

Is that correct?

Aside from that, I wonder why the plugin only outputs a single value... Both run with the same interval?

[chunter1]

So to summarize:

• There are 2 tasks, operating on the same plugin. Correct - the "Analog input - ADS1115" plugin
• Task 1 does sometimes get values configured from the input configured in task 2 and vice verse. Correct - I am observing all combinations of data "twist" (A,B or B,A or A,A or B,B)
• Both tasks send out their data via a controller (FHEM HTTP) Both tasks send out their data through two controllers, one controller for FHEM server1 and one for FHEM server2.

Is that correct? Yes

Aside from that, I wonder why the plugin only outputs a single value... What exactly do you mean with single value? One ADC-task delivers one ADC value for the given channel, right? Both run with the same interval? Correct - 120s

Answers see above... Little update... with the old release it's now running 3h without issues.

[TD-er]

Little update... with the old release it's now running 3h without issues.

OK, so it may be a change in how values are being handled, which may be a bigger issue affecting all plugins and not only this plugin.

And about the remark of outputting a single value vs. multiple values. The ADS1115 can read multiple inputs and thus output more than one value per read. If you split it over several tasks, you have no guarantee both inputs are samples at the same time, which may be an issue in some use cases. I looked into the code and the plugin does not keep track of a state which may affect readings made by multiple tasks running the same plugin. So that should not be a problem here.

[TD-er]

@chunter1

Both tasks send out their data through two controllers, one controller for FHEM server1 and one for FHEM server2.

I just noticed this reply of you. I think this may be the issue here, as the queue elements have only one queue per controller and not 100% sure they check the controller index to get the credentials. How does FHEM filter on the source of the sample? The message sent does have a deviceName and a valueName. Could a message sent to the wrong server (out of order processing of the queue) also result in values being mixed up?

[chunter1]

@chunter1

Both tasks send out their data through two controllers, one controller for FHEM server1 and one for FHEM server2. How does FHEM filter on the source of the sample? The message sent does have a deviceName and a valueName. Could a message sent to the wrong server (out of order processing of the queue) also result in values being mixed up?

I'm using the ESPEasy modul of FHEM which (as far as i understand it) generates a device based on the device name and readings according to the value names received. Both ADC readings are sent to both FHEM servers so i don't think it's an issue on how FHEM processes the values. If i remember correctly, i saw the mixing of the values already in the log of espeasy. The single queue seems indeed to be the most promising point of failue - however, why didn't this issue show up years before then?

[TD-er]

Right now, I don't have a clue yet what causes this. So I have to keep all open.

But if it would be queue related, then it should have happened before, even very occasional. I agree it is then unlikely the single queue may be the cause here.

[TD-er]

If you can build your own version, can you please check if this will fix it...

In _Plugin.ino, around line 1316:

        if (Function == PLUGIN_GET_DEVICEVALUENAMES) {
          // FIXME TD-er: Is this still needed? (or correct?)
          ExtraTaskSettings.TaskIndex = event->TaskIndex;
        }

Please remove these lines, as I am sure this is a bug. The only way I can explain why it only now turns up in your setup is that there may have been some code optimizations which cause both plugins to try to read the names of taskname or taskvalue names right after each other, where they didn't before. (some other task or controller inbetween calling the lookup)

[chunter1]

But if it would be queue related, then it should have happened before, even very occasional.

I got that modul running several years now and never observed that issue before. Something significant must have changed at the transition from "Release mega-2020-03-01" to "Release mega-20200305".

[chunter1]

If you can build your own version, can you please check if this will fix it...

Ok, i will try tonight.

[pm-cz]

Are you sure you are getting data from another channel? I have similar behaviour in latest version (with 2.5.x ESP8266 library and 2.7.x core) and the culprit is probably increased maximum speed of I2C bus. The ADS1115 datasheet actually mentions this, as it normally operates in Fast mode and to activate the high speed mode:

No special action is required to use the ADS1113/4/5 the master must first write an appropriate value to the in standard or fast mode, but high-speed mode must be activated. To activate high-speed mode, send a special address byte of 00001xxx following the START condition, where xxx are bits unique to the Hs-capable master.

Maybe this is not happening? I am including graphs before and after reducing I2C speed:

Before:

After:

[TD-er]

That's indeed a very good observation. I will add the option to allow the high speed mode and also check the current I2C clock speed.

[chunter1]

Are you sure you are getting data from another channel?

Yes, since the values are exactly the same just mixed. However, maybe this is just an artefact of what you found might be the root cause.

[pm-cz]

Sorry for the high-speed mode, I may have made a mistake as the explanation in the datasheet was not clear, According to I2C documentation Fast mode should be working up to 400000, but it was not clear if it is including the 400000 or not for me from the datasheet. So maybe switching is not necessary in this special case. But there is clearly some issue with the communication on higher speed.

[TD-er]

Don't forget that the total capacitance of the I2C bus affects the max. frequency you can use. The wires (or PCB traces) and all connected I2C devices add to this capacitance. The mentioned datasheet also states when switching to high speed mode, the internal capacitance of the chip is changed. You may also add some pull-up resistors, or lower their value a bit to allow for faster rise times of the signal.

[KieranBaines]

I found that changing the Delay on line 184 from 8 to 9 fixed the issues I have had, I'd read something about this on the Adafruit forums.

[TD-er]

This part you mean:

https://github.com/letscontrolit/ESPEasy/blob/866fc88f9279f47715296931aef67cbfe89faef2/src/_P025_ADS1115.ino#L161-L185

Do you have a link to the discussion on the Adafruit forum?

As you can see, the config is set to 128 samples/sec. One reading should be about 7.81 msec I can imagine it may take some time to switch and copy data, so I get it why it may make a difference to set it to 9 msec. But on the other hand, how critical is this timing?

[KieranBaines]

Yep that's the part

I'm sorry https://forums.adafruit.com/viewtopic.php?f=19&t=59304 I'm not a programmer in any sense of the word, but I happened to have big problems with my ADS1115 i had 7 and only one worked correctly channel 0 would show on 1, 1 would show on 2 and 2 on 3, and 4 back on 1. If i edited any of the confrig in espeasy, it would randomly swap the channels around again, until next reboot, where they would go back to the order above. However on changing the delay all worked perfectly. I believe they call it the ADS1015_CONVERSIONDELAY.

Hope this helps, it might have just been luck on my part, but i have been building my own versions in Atom for the last few releases and its worked every time.

[TD-er]

It does make sense, after I read the datasheet.

9.4.2.1 Single-Shot Mode When the MODE bit in the Config register is set to 1, the ADS111x enter a power-down state, and operate in single-shot mode. This power-down state is the default state for the ADS111x when power is first applied. Although powered down, the devices still respond to commands. The ADS111x remain in this power-down state until a 1 is written to the operational status (OS) bit in the Config register. When the OS bit is asserted, the device powers up in approximately 25 μs, resets the OS bit to 0, and starts a single conversion. When conversion data are ready for retrieval, the device powers down again. Writing a 1 to the OS bit while a conversion is ongoing has no effect. To switch to continuous-conversion mode, write a 0 to the MODE bit in the Config register.

It does need 25 usec to wake up, which makes it roughly 7.84 msec. So there's roughly 160 usec left for the other steps needed, which is quite close to 8msec.

[TD-er]

According to the datasheet and some post on TI's site, it appears the clock in the chip may drift a bit. It may drift up to 10%, so then we're over the 8 msec for sure and thus 9 msec wait seems to be a good value. N.B. this 10% oscillator drift I only found in that post, not in the datasheet.

[wclintdavis]

I am having this exact same issue and cannot find any resolve, what is thee answer?

[TD-er]

What build are you using? If I remember correctly, there was one user a few weeks (months?) ago mentioning something similar. Not sure if that was on the forum or here on GitHub....

[TD-er]

Found the topic... here

[wclintdavis]

I’m using mega-20220809_57b0c0c I’ve tried numerous builds. I have a new ads1115 on the way to test, but I’ve tried three. They are from the same lot though…