Hello world!
Curious if anyone has had this issue before; I've got an ADS1115 hooked up and streaming some sensor data. All goes well over I2c, but the time between each sample varies significantly. Sampling rate is fine, though, cooking up to 560 sps.
Anybody seen this?
How do you measure this time between samples?
Also, are you using continuous or single shot mode? Alert pin?
Try posting your code, that will help us help you. Also your annotated schematic with links to the modules you are using. The particular Arduino you are using also can be a problem, they have interrupts running in the background.
At the standard 100 kHz I²C clock rate, the ADS1115 can still operate at its maximum 860 samples per second.
At 860 SPS:
- Conversion time: 1.163 ms
- I²C clock period: 10 µs
- Reading a 16-bit conversion result typically requires approximately 45 I²C clock cycles, or 0.45 ms, including addressing and acknowledgments.
For your Arduino UNO, using the standard Wire library at 100 kHz, 860 SPS on one channel is achievable, particularly in continuous-conversion mode. This is from Texas Instruments data sheet.
If you're switching between four channels, allow for the configuration writes and conversion timing. The practical per-channel rate will be somewhat lower than the theoretical 215 SPS.
Hopefully this helps.
I believe this AD works at 8xx samples per second only in continuous mode for a single channel.
You must use it with irq/alert.
If you are using multiple channels, that is single shot mode and it's slower.
Please post your code. It will answer a number of questions which will otherwise have to be asked explicitly such as 8bit or 32bit board, I2C bus speed, your measurement method etc. If the code is too large then create a minimal version for this forum. Same goes for a schematic to preempt questions about MCU, I2C pullup resistors, what else is on the bus etc. etc.
Did you consider an SPI chip such as ADS1158 instead ?
Not according to the datasheet.
This is what my 45 clock cycles is based on , reading the conversion register requires more than the two data bytes cycles.:
START
Address + Write + ACK 9 clocks
Register pointer 0x00 + ACK 9 clocks
REPEATED START
Address + Read + ACK 9 clocks
Data MSB + ACK 9 clocks
Data LSB + NACK 9 clocks
STOP
However, one would think that 2x45 (90) clocks would be required to read 32-bit (n = 4) data when you say -- Reading a 16-bit conversion result typically requires approximately 45 I²C clock cycles. The fact is that to read 4-byte data, the required clocks are:
9 + 9 + +9 + 4 * 9
==> 63 clocks and NOT 90 clocks!
What's it running on and what is running in the background?
but not five
Here, cycle refers to the bus cycle and not the clock cycle. A bus cycle consists of 9 clock cycles in I2C protocol. So, reading the 16-bit data from ADS1115 essentially requires 9 bus cycles.
An example from 8085:
STA 3600H ; 32 00 36`
To complete the above instruction, the MPU needs 4 bus cycles.
In either case @gilshultz is wrong.
The original statement was that reading a 16-bit conversion result from the ADS1115 typically requires approximately 45 I²C clock pulses.
That is correct for a complete transaction that includes setting the conversion register pointer:
9 + 9 + 9 + 18 = 45 clocks.
For a four-byte transfer using the same transaction, the calculation becomes:
9 + 9 + 9 + 36 = 63 clocks.
The transaction overhead is not repeated for each additional data byte.
Also, a distinction should be made between I²C clock pulses and transactions. Each byte transfer requires 8 data clocks plus a ninth ACK/NACK clock. The complete 16-bit register-read sequence involves five byte transfers, not nine.
If the ADS1115 register pointer is already set correctly, a direct two-byte read needs only 27 clocks.
The ADS1115 conversion register is 16 bits, so the original discussion concerned a two-byte result, not a four-byte transfer.
Repeat as may times as you want it's still wrong
If we did not use the library, we would go like this to read the ADC value. Assume continuous conversion mode configured in setup().
Wire.beginTransmission(adcAddress); //1 bus cycle = 9 clocks)
Wire.wrie(lowByteAddress); //1 bus cycle = 9 clokcs
Wire.endTransmission();
//--------------------------------
Wire.requestFrom(adcAddress, 2); //1 bus cycle = 9 clocks)
int adcValue = WireRead() | WireRead() << 8; //2 bus cycles = 2x9 cocks
Total 45 clocks, and establishes @gilshultz proposition.
Which is still wrong.
You have presented a puzzle!
Have you read the datasheet?
ADS1115 is with an 8-bit oriented UNO R3 board. Therefore, I think, it is enough to know the I2C protocol to compute the number of bus cycles required to read 2-byte data from the ADC. I will setup an experiment and measure the time to execute the code of post #16.