COMP_POL reversed

[lynx985]

COMP_POL reversed

[RobTillaart]

Thanks for these tests,
Need to confirm these so it might take (serious) time before I have a HW setup.

[RobTillaart]

@lynx985
Updated the readme.md with all the detailed insights from above.
Took more time than expected and imho it was worth the effort to understand these details
New version 0.4.4 will be (expect) this weekend.

[lynx985]

thanks for all your work =)

[RobTillaart]

@lynx985

First results of 4 test runs.

  //  test polarity
  //  MODE                COMP_POL    ALERT/RDY PIN
  //  0 = continuous      0 = LOW     LOW with 8 us HIGH pulse
  //  0 = continuous      1 = HIGH    HIGH with 8 us LOW pulse
  //  1 = single          0 = LOW     continuous HIGH
  //  1 = single          1 = HIGH    continuous LOW

In single mode I get no pulses (yet).

Test sketch

//
//    FILE: ADS_COMP_POL.ino
//  AUTHOR: Rob.Tillaart
// PURPOSE: read analog input
//     URL: https://github.com/RobTillaart/ADS1X15/issues/76

#include "ADS1X15.h"

// choose your sensor
// ADS1013 ADS(0x48);
// ADS1014 ADS(0x48);
// ADS1015 ADS(0x48);
// ADS1113 ADS(0x48);
// ADS1114 ADS(0x48);

ADS1115 ADS(0x48);

void setup()
{
  Serial.begin(115200);
  Serial.println(__FILE__);
  Serial.print("ADS1X15_LIB_VERSION: ");
  Serial.println(ADS1X15_LIB_VERSION);

  Wire.begin();

  ADS.begin();
  ADS.setGain(0);  //  6.144 volt

  //  test polarity
  //  MODE                COMP_POL    ALERT/RDY PIN
  //  0 = continuous      0 = LOW     8 us HIGH PULSE
  //  0 = continuous      1 = HIGH    8 us LOW pulse
  //  1 = single          0 = LOW     continuous HIGH
  //  1 = single          1 = HIGH    continuous LOW
  ADS.setMode(1);
  ADS.setComparatorPolarity(1);
  //  enable ALERT/RDY pin
  ADS.setComparatorThresholdHigh(0x8000);
  ADS.setComparatorThresholdLow(0x1000);
  ADS.setComparatorQueConvert(0);

  Serial.println("Voltage");
}

void loop()
{
  int16_t raw = ADS.readADC(0);
  delay(1000);
  Serial.println(ADS.toVoltage(raw), 3);
  delay(1000);
}

//  -- END OF FILE --

[RobTillaart]

@lynx985

Fetched a better scope to check for pulses - see 3 screenshots below - resulted in the following observations.

TEST	MODE	COMP_POL	ALERT/RDY PIN	Notes
1	0 = continuous	0 = LOW	LOW with 8 us HIGH pulse	micro second pulse as specified in datasheet
2	0 = continuous	1 = HIGH	HIGH with 8 us LOW pulse	micro second pulse as specified in datasheet
3	1 = single	0 = LOW	HIGH with an 8 ms LOW pulse	1000 x longer pulse
4	1 = single	1 = HIGH	LOW with an 8 ms HIGH pulse	1000 x longer pulse

Observations:

• polarity in single mode seems indeed inverted
• length of the pulse in continuous mode and in single mode differs a factor 1000.

---

Screenshots

MODE = 0, COMP_POL = 1, DATARATE = 4

---

MODE = 1, COMP_POL = 0, DATARATE = 4

---

MODE = 1, COMP_POL = 1, DATARATE = 4

[RobTillaart]

TODO: add note in the readme.md

[RobTillaart]

Created a new develop branch with updated readme.md (and some minor edits).

[RobTillaart]

so did a short test

measured the RDY-pin on an oscilloscope

in single shot mode RDY remains high/low until the next request is made (not just a pulse)

but COMP_POL seems to be switched COMP_POL (0) goes LOW while convertig (around 1.2 ms) and HIGH when ready for as long as one wishes COMP_POL(1) goes HIGH while convertig (around 1.2 ms) and LOW when ready

Can you post your test sketch, so I can confirm (understand) your observations as these are slightly different than mine.

What board do you ise?

[RobTillaart]

Note that my above observations are made with a fixed data rate and synchronous calls.
Todo: investigate effect data rate
Todo:: investigate async calls.

---

Hypothesis
Maybe the single shot mode is not inverted, but only looks that way due to sync call.
Todo: what is state of the ALERT/RDY pin before any request, after request, and after read.
Might be e.g. LOW before, HIGH after request, and Low after read again. (Mode 0).

[RobTillaart]

Investigate effect data rate

Same sketch as above + ADS.setDataRate()

• MODE = 1 (Single shot modus)
• COMP_POL = 1
• DATA_RATE = 0..7

datarate	pulse length
0	125 ms
1	62 ms
2	32 ms
3	16 ms
4	8 ms
5	4.4 ms
6	2.4 ms
7	1.2 ms

Quick estimates from scope.

[RobTillaart]

Investigate level before any call

Same sketch as above minus code in loop()

• MODE = 1 (Single shot modus)
• COMP_POL = 1
• DATA_RATE = 4

After power off and no request the polarity is indeed HIGH.

• MODE = 1 (Single shot modus)
• COMP_POL = 0
• DATA_RATE = 4

After power off and no request the polarity is still HIGH.

mmmm, lets think....

---

aha, settings are not activated as the library does that in the requestADC() call

Added call to ADS.requestADC() at end of setup()

COMP_POL = 0 => gave HIGH with a 8 ms LOW pulse (as before).
COMP_POL = 1 => gave LOW with a 8 ms HIGH pulse

Conclusions

• COMP_POL is indeed behaving inverted in single shot mode.
• conversion ready always gives a pulse
• the length of the pulse depends on the data rate in single shot mode.

[RobTillaart]

@lynx985

See my tests above,

And yes, when switching from POL 0 to 1 or vice versa, the ADS only activates this setting when a requestADC() call is made.

I will (try to) document this all in the readme.

[RobTillaart]

@lynx985

Found the right phrasing for the semantics of COMP_POL:

• if COMP_POL = 0, a FALLING edge indicates conversion ready.
• if COMP_POL = 1, a RISING edge indicates conversion ready.

This is true for both continuous and single mode.

[RobTillaart]

I am not convinced yet the (my) story about the COMP_POL is 100% complete.
However the part described seems correct, logical and useful, and I expect some small updates to fill some gaps.

[RobTillaart]

@lynx985
My latest insights are as follows:

MODE	COMP_POL	IDLE	START	CONVERT	READY
0 = continuous	0 = LOW	HIGH	FALLING	LOW	RISING
0 = continuous	1 = HIGH	LOW	RISING	HIGH	FALLING
1 = single	0 = LOW	HIGH	FALLING	LOW	RISING
1 = single	1 = HIGH	LOW	RISING	HIGH	FALLING

This view matches with all the scope images above and observations including those in your first post.

It shows that the 8us pulse in continuous mode shows the IDLE time,
while one should look at the CONVERT time as the actual pulse.

Yes, it need time to get good insights.
Will update the readme any time soon.