Electronic – MCP3561 Sampling Interval

adc

I am using an MCP3561 ADC (Datasheet) to convert analog readings from a load cell to digital signals to be processed by an ATSAMD20G16 Microcontroller (Datasheet). I have configured the ADC to exhibit the following properties:

Prescaler: 2
Oversampling Rate: 98304
Gain:1
Continuous Conversion

This corresponds to a sampling interval of approximately 100ms given Equation 4.3 on page 27 of the ADC datasheet and an 8 MHz master clock from the MCU. My application continuously polls the IRQ register on the ADC to check the !DR_STATUS bit. When this bit indicates data is ready, the program reads the contents of the ADC's data register and transfers it to the MCU over SPI.

I have configured my main loop to print the value of the ADC read and the time interval between reads over the serial port. I observe a consistent 98-99ms interval between samples. Occasionally, however, the inter-sample interval is doubled. The occurrence of this doubling is unpredictable; sometimes there is a cluster of double intervals in rapid succession, other times it takes 20 or 30 seconds before a double interval occurs.

I edited my ADC read function to toggle a GPIO pin on the MCU every time it reads a sample so I could correlate the serial output to a signal on the oscilloscope. Then I stripped every piece of extraneous code from my main loop, including the serial print statements, with the hopes of isolating the cause of this anomoly. Unfortunately, the behavior persisted, and I am no closer to an answer.

Has anyone experienced this behavior (or anything similar) when using this IC? If so, were you able to determine the cause/develop a solution? Any insight would be appreciated!

Thanks in advance!

Best Answer

Voice of (painful) experience: when using Microchip products, always check out the errata sheet. Your issue and a workaround are described in http://ww1.microchip.com/downloads/en/DeviceDoc/MCP3X5X-Family-Data-Sheet-Errata-DS80000845B.pdf .

Related Solutions

Electronic – Arduino sampling accelerometer

You can send transmit roughly 11 bytes per millisecond at 115200 baud. So as long as you restrict your output to 10 characters and a newline per sample, that should be fine.

The math behind that is 115200 baud means 115200 bit-times/second, and there are 10 bit-times per byte transmitted on the UART (start bit, 8 data bits, and stop bit). So 115200 / 10 = 11520 bytes / second = 11.520 bytes / millisecond (and I round down).

In summary, 100Hz sampling should be easy.

The canonical approach to interval timing is demonstrated in the BlinkWithoutDelay Arduino example. Consolidated it looks like the following:

long previousMillis = 0;
long interval = 10; // interval in milliseconds (10ms => 100Hz)

void setup() {
   // whatever
   Serial.begin(115200);
   Serial.println("Hello World");
}

void loop(){
   unsigned long currentMillis = millis();
   if(currentMillis - previousMillis > interval) {
      previousMillis = currentMillis;

      // do your task
      Serial.println(analogRead(0));
   }
}

PLL synchronized ADC sampling

Yes this is quite feasible and I remember doin this back in the 80s on one job because the processing power we had was not enough to create too many samples per cycle and, with an exact integer number of samples per cycle, you can avoid certain errors thus the calulation is quite precise. Here's a little picture showing what I mean: -

enter image description here

The pink trace is a pure sinewave and there are exactly 8 samples taken in one cycle of the sinusoid. If you take all the sample values and calculate RMS you get exactly 0.7071.

It's also worth pointing out that the samples don't need to be aligned with the sinewave's zero crossing. Should the samples have began a little late at 22.5 degrees, the accumulation of squared samples would be: -

0.1464 + 0.8536 + 0.8536 + + 0.1464 + 0.1464 + 0.8536 + 0.8536 + 0.1464 = 4

Dividing by # of samples gets 0.5 and taking the square root yields 0.7071 i.e. exactly the same.

Should your sampling have been asynchronous to the sinewave, there would have been an error on the first cycle of calculations that would eventually even-out over enough cycles but if you want to do this quickly, with minimal CPU overhead then using a PLL to "sync" sampling to the AC waveform works.

Of course, if you take more samples per cycle the error reduces and, if you average over several cycles the error also reduces.

One extra word of warning about sampling - the harmonic distortion in your waveform can affect this calculation due to aliasing - as ever, you need to sample greater than twice the highest frequency in the waveform you are analysing.

Related Topic