QUESTION: What's the typical conversion time?

[robtillaart]

QUESTION: What's the typical conversion time?

[RobTillaart]

Hi, i must check the datasheet for this and or do some tests to check what numbers i could get.

That said,
3300 samples per second is ~0.3 ms per sample.
Your math is ok, note that is the time the ADC needs internally to make the sample.

Then you have communication time, the time you need to get the value from the ADC into the processor.
An important parameter is the I2C bus speed.
From my head the 1015 can run on 400kHz which allows max 400.000 bits per second to be transported under ideal conditions. In the datasheet one can see how many bits are needed to fetch 1 sample.
I expect 50-60 including ack etc maybe more.
This would mean ~5000-8000 samples max per second. However your processor does process the data too, taking time ...so the number drops substantially depending on what you do.

Does this help?

[RobTillaart]

If you run ADS_performance.ino what output do you get?

add the line Wire.setClock(400000); after ADS.begin(); in that sketch to increase bus speed and run again.

---

from datasheet

8.5.1.3 I2C Speed Modes
The I2C bus operates at one of three speeds. Standard mode allows a clock frequency of up to 100 kHz; fast
mode permits a clock frequency of up to 400 kHz; and high-speed mode (also called Hs mode) allows a clock
frequency of up to 3.4 MHz. The ADS101x are fully compatible with all three modes.

3.400.000 would minimize communication even more, don't know up to which speed the ESP Wire lib works.
try in steps of 500.000 ?

[RobTillaart]

Note: the timings are for 100 reads in microseconds.

Note: increasing I2C with a factor 4 only result in a gain of 2 or less.
(might still be worth it)

at DATARATE 4 a single shot read takes ~ 2.3 milliseconds @100 kHz
at DATARATE 7 in continuous mode a read takes 0.263 milliseconds @400 kHz

so roughly a factor 10 performance difference by choosing parameters (==> price = quality of measurement)

[RobTillaart]

You should be able to just do Wire.setClock(1000000) on a ESP32,
I will have a check in the core code to see if I can detect some upper limit.

Biggest problem that can bite you is that at higher speeds the I2C pulses becoming less "squarish" which can lead to faulty reads.
Reducing the pull up resistors to e.g. 1K helps a lot to prevent this.

You might also consider using https://github.com/RobTillaart/MCP_ADC e.g. MCP3008 which use the SPI bus,
These go up to ~200.000 samples per second which is pretty fast.

You should not blame your brain, things got really more complex in 4 decades, seldom it became simpler :)
( for inspiration about old, check- http://www.prmvr.otsu.shiga.jp/library/master/samuelullman/youth.html )

[RobTillaart]

If you know someone who can do calligraphy, and hand write it for you, it can be really a nice gift

[marcdraco]

From one of your examples Rob. Please understand that I'm in no way blaming you, I'm just foxed given the apparently low speed compared to the (albeit hideously inaccurate) ones in the ESP32 but even the relatively sedate SAMD21 still provided much faster results. Here's a sample from your performance example (I've only included the faster results) to see if they agree with what you're seeing. I have two Open Source projects in mind for these - one can happily cope with single shot, differential readings and may only need to average ten or reads so to do its job more than adequately. I've ordered a 16-bit breakout to test that one since the voltages are quite low and I'm trying to avoid increasing errors with more amplification steps than I need.

It may well be that the Wire library is the bottleneck here, per your suggestion:

DR:	4
test_single_shot	227975
test_continuous		62899
		FACTOR:	3.62
DR:	5
test_single_shot	166959
test_continuous		62908
		FACTOR:	2.65
DR:	6
test_single_shot	166962
test_continuous		62906
		FACTOR:	2.65
DR:	7
test_single_shot	166962
test_continuous		62906
		FACTOR:	2.65

After Wire.stClock(400000):

DR:	4
test_single_shot	119424
test_continuous		26447
		FACTOR:	4.52
DR:	5
test_single_shot	93545
test_continuous		26324
		FACTOR:	3.55
DR:	6
test_single_shot	93543
test_continuous		26332
		FACTOR:	3.55
DR:	7
test_single_shot	93533
test_continuous		26332
		FACTOR:	3.55

I'll try bumping it a little and see when the wheels come off! :)

EDIT:

Best I could get was 3.61 with smaller pull-ups (almost got some magic smoke there too!) so it looks like the Wire library is the hold up, because it refuses to go any faster no matter what sort of ridiculous values I throw at the constructor.

So it appears that I'll have to massage something (or, heaven forfend, use the internal ADC which is ... wobbly at best).

[marcdraco]

I'll have to see if the faster mode works any better in my application but I suspect it's not going to cut it.

HS I2C needs a special library function (there was a woosh when the details when over my head) but I read here: https://www.i2c-bus.org/fast-mode-plus/ there is a compatible mode that runs at 1MHz. I wonder if there's any way to hack the existing Wire library to support those timings?

I think the gotcha that caught me by the short and curlies was reading the datasheet and not allowing for the transmission time bottleneck. (I mean, I've only been doing this for >45 years so you'd think I'd know that by now, but nooooo.) I'm blaming Covid brain or old age. ;)

This particular application only needs 8-10 bits of accuracy, but it needs the data in real-time at frequencies up to about 200Hz (sine).

Of course, I could use a SAMD21 or one of the ST Microelectronics (Blue Pill/Black Pill) boards to do the real-time conversion in 10-bit and then bit-bang the data back to the ESP32 but that bumps the complexity up and it's likely that will create problems of its own.

Gotta love development! :)

[marcdraco]

I hit the constructor with some silly numbers to see if it broke but that was as fast as I could get it.

Funny you should mention it, but I've got 1.2K pull ups in there right now to give them a good old yank! ;)

Luckily I treated myself to a new scope earlier in the year and it's fast enough to detect this sort of stutff. Larry Bank has a bit-banged I2C (https://www.arduino.cc/reference/en/libraries/bitbang_i2c/) which goes up to 2Mhz so that's pretty close to what the ADS can manage.

I haven't seen the MCP3008 Rob, I'll get my ass on eBay and get one ordered on pay day (I really need to stop collecting old laptops). SPI is certainly a better bus for high-speed stuff, it's all the spaghetti that gets in the way. I don't mind on a PCB where the layout is already sorted but lose wires are a massive pain, particularly when you're needing differential (twisted) pairs, etc.

thanks for that link, I'll take a break and give it a look-see! And thank you for your help. I do appreciate it.

[marcdraco]

Youth: 1918 by Samuel Ullman. Never heard of it before Rob, but wow isn't that so profound even over a century later. I need to memorise that and I know a few other people around my time of life who could use it too!

[marcdraco]

Yeah. On a really nice aged velum and placed in a decent frame. Almost delicious in the beauty and it's good for people of all faiths and none too. I was taught calligraphy as a kid but I don't have the dexterity any more and lack of practise means the muscle memory has long gone too. I can mock a decent one up in Photoshop (well, Affinity Photo or Gimp)

[RobTillaart]

@marcdraco
Is your issue investigated enough or are there questions left?

[marcdraco]

Absolutely Rob, sorry didn't see a notification.

I've re-engineered the design to use a much slower conversion rate that synchronises with the wave that it's trying to measure. I'll be sure to hit you up when I have a product but I've been diverted to finish a Proton Pack (movie prop) for now!