Electronic – Identifying Source of Periodic Artifact at Op-Amp Output

Most likely a common-mode voltage violation. See Figure 15 of the datasheet. Unfortunately it does not give you the limits for a single power supply, but shows you that common-mode and output voltage limits go hand in hand.

Actions that may solve your problem:

• Use dual power supply.
• Lift inputs above ground.
• Use a lower gain setting.

EDIT:

As pointed out by Dave Tweed, the datasheet does have information on common-mode and output voltage ranges for single supply. See Figure 13 on page 10 of the datasheet (your case is the blue triangular area). Your common-mode input is practically ground, so as soon as your output exceeds about 0.7 V, the limit is exceeded, and your device will not behave as specified. This will happen even if you change Vref to 2.5 V: the output limit will be 3.2 V for a common-mode input voltage of ground to become invalid.

Sounds like you have several things going on. Aliasing is highly likely. First, you are sending data at 115200 baud. That is in bits per second, so with 10 bits per byte, it takes about 200uS to send a 2 byte int. That is about 5K bandwidth. You say that you are sampling at 76.9K, samples per second.

Then you are doing some reasonably complicated math (map()), for an 8 bit micro, on the data which may have an impact on the sampling response. And you have a delay. All of that will have an impact on the sampling rate.

On top of that, and probably more importantly, you are updating the variable 'aval' in your ADC interrupt. 'aval' is a two byte int, so, in an 8 bit processor, it takes two memory moves to save the value. How do you guarantee that you don't get an interrupt between byte moves and have 'aval' be half of one reading and half of a different reading?

Then you are performing the map() function on that data. Is the map() function re-entrant? If the map function retrieves the 'aval' data several times in side the function, it is likely that the data will be updated by the interrupt during that time.

I would try to synchronize the interrupt to your main loop so the 'aval' value is not changed while you are operating on it. I would create another int and, at the beginning of your main loop, disable interrupts, copy 'aval' to that new variable, re-enable interrupts, then operate on the new variable.

That may clean things up some, but I think you will still have a bandwidth issue between the sampling and communications.