I have an analog signal from a fluid flow sensor that is buffered to the input of a BeagleBone Black ADC input line. The buffer ensures the signal does not exceed the Beagle's max input voltage of 1.8VDC.

With the Beagle, we can access the ADC using either a program running on the ARM processor under Linux or a program running on one of the programmable real-time units on the AM355x SOC from TI. On the ADC side we are using the 'off the shelf' ADC kernel driver which by default samples all 7 ADC inputs, and is set up to take average 16 readings.

On the PRU side, we set our own configuration and only read three analog lines and average 4 readings.

Everything is written in C.

We monitor this analog value using a Diligent USB1408-FS DAQ and their DAQami software.

When running the system using the ARM/Linux code, the baseline value seen in the DAQami software stays about zero.

Using the PRU code, the baseline value drifts up to a DC offset of about 300-400mv seen using the DAQami software.

I'm puzzled why a different ADC configuration would cause the actual voltage (not the ADC's output digital equivalent) to shift like this. Why would this happen?

Here is the schematic of the unity gain isolation amp circuit. This is a prototype built on a protoboard currently.
This circuit serves two purposes

  1. primarily, our microcontrollers ADC has a max input of 1.8V. R1 and R2 are precision 2.94k resistors that divide the voltage 50/50 resulting in a max input of 1.5V, below the max ADC input of 1.8V. We lose some resolution but in this application that is not an issue.
  2. As a double safety, we power the LM10 from a 1.8V regulator (U2). Thus, the output can't go above 1.8V.

R3 is 22k C1 & C2 are 0.1uF J1, J2 and J3 are Phoenix 2 position screw terminal connectors

enter image description here

  • \$\begingroup\$ Schematic of the buffer circuit? \$\endgroup\$ 2 days ago
  • \$\begingroup\$ I can get it. It hasn't changed between when this did not exhibit this behaviour and now that it does. \$\endgroup\$ 2 days ago
  • \$\begingroup\$ Assuming the Beaglebone ADC is some kind of SAR with an input multiplexer, there can be some amount of charge injection that happens at start of sample acquisition — this is more noticeable with sensors that have high source impedance, or with shorter acquisition time. There can also be charge injection when the input multiplexer scans from one channel to another. You might try repeatedly sampling on the same channel without scanning, or configure a different sampling rate, to see if that has a noticeable effect. Input network RC values will also influence this effect. \$\endgroup\$
    – MarkU
    2 days ago
  • \$\begingroup\$ I've added a schematic to the original post with some additional information. \$\endgroup\$ yesterday
  • \$\begingroup\$ The ADC is built into the TI AM3358 microcontroller. It has a touchscreen controller & general purpose ADC modes. We use the latter. It's 12-bit & has 7 addressable input channels. The 8th isn't exposed for use with the BeagleBone Black. TI's docs don't specify if it is SAR but I think it's likely a safe assumption given how it can be software configured with 16 possible steps, open delays, several averaging options, etc. I think you are on the right track. We use the same isolation amp circuit on our desktop prototype on a breadboard and have no drift/offset. \$\endgroup\$ yesterday


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Browse other questions tagged or ask your own question.