The net effect of the input circuit is a 30 K input impedance and a forward gain of 0.825. If the 30 K impedance is important (as in required by whatever is producing the input signal), then a 2-resistor attenuator followed by a simple voltage follower will produce the same low output impedance with fewer components, fewer error terms, and lower noise. And, you can cover both inputs with one dual opamp, eliminating U4.

Separate from that, why do the input circuit and A/D input have different grounds? Shouldn't the analog input conditioning stage be referenced to the same potential as the analog converter input? As it is now, any potential difference getween the two grounds, which mostly will be noise, will appear on top of the input signal at the A/D input.

ak

There is no requirement to use 30k, but some piece of information I read about suggesting using high input resistance for this type circuit so it was what I selected. If the OP AMP isn't required, I will look into redesigning it without it in the future.

There are two separate grounds for digital and analog signals that meet toward the center of the board. This part of the design was difficult for me to solidify my understanding of what should be connected to which one, and it was an unintended mistake on my part that they reference two different grounds. It is fixed in the current edition of the board.

It isn't my idea or desire to use separate grounds in the first place, but I am a smaller part of a team of amatuers so a lot of this design is failing upward.

 

just to look at the original question:
you say " issues with reading values correctly "

what do you mean by that.

You have an input range , what happens when you apply a fixed voltage abotu mid range.
do you readback a constant value,
what is the voltage you apply and the value you read back ,

There are three places that things can go wrong, and we need to localize:

a) the input / circuit can be wrong
b) the way the serial data is received can be wrong
c) the way the serial received data is decode to a voltage number can be wrong.

So I am able to apply a voltage between 0-12V and measure approximately 0-3.3V on the input of the ADC. I am currently testing it with 6V in -> 1.5V to both of the ADC inputs. It doesn't exactly matter what I set the input voltage to, the MCU is receiving data that appear to be random but discrete values. It can be a number between 0-65535, but some numbers seem to appear more than others. Some instances the numbers of both inputs are the same. Overall though, it jumps around without a clear pattern. I would have to log the data to extract any information but I think I am focusing on the B and C of the problem.

The ADC converts the input when I cycle the CS and readies it on the SDO line for the next toggling of CS. The data is two's compliment format, and I wrote software that checks for that condition and negates numbers where the MSB is 1. Though none of my numbers should be negative in an ideal working state.

I am going to look into the way I am receiving the data a little more, though I have matched what I see on the SDO line bit wise with the digital value of the variable in software so there isn't a bad translation of data internally, but maybe an improper interpretation of it that only makes it appear random.

 

What does the 0-12V signal represent? How fast does it vary? How often are you reading the data?

0-12V is part of the requirement of the system unfortunately. It is required to be converted to digital value that represents a desired position of a motor along a 120 degree sector. I am currently initiating a read every 225 us, which takes approximately 300us until I receive the last bit of data. Slowing this down did not produce better results even I am already within the spec of 500kSPS. Every read is a different value. It appears random, but sometimes both inputs are exactly the same number, maybe one in ten samples.

 

So I am able to apply a voltage between 0-12V and measure approximately 0-3.3V on the input of the ADC. I am currently testing it with 6V in -> 1.5V to both of the ADC inputs. It doesn't exactly matter what I set the input voltage to, the MCU is receiving data that appear to be random but discrete values. It can be a number between 0-65535, but some numbers seem to appear more than others. Some instances the numbers of both inputs are the same. Overall though, it jumps around without a clear pattern. I would have to log the data to extract any information but I think I am focusing on the B and C of the problem.

The ADC converts the input when I cycle the CS and readies it on the SDO line for the next toggling of CS. The data is two's compliment format, and I wrote software that checks for that condition and negates numbers where the MSB is 1. Though none of my numbers should be negative in an ideal working state.

I am going to look into the way I am receiving the data a little more, though I have matched what I see on the SDO line bit wise with the digital value of the variable in software so there isn't a bad translation of data internally, but maybe an improper interpretation of it that only makes it appear random.

Are you sure the SPI mode for clock edges and idle are set correctly? I've seen this type of behavior when the data is clocked in at the wrong point (clock edges coincide with data edges) Post a scope or logic probe image of the MISO and SCK during a ADC data transaction.

 

Are you sure the SPI mode for clock edges and idle are set correctly? I've seen this type of behavior when the data is clocked in at the wrong point (clock edges coincide with data edges) Post a scope or logic probe image of the MISO and SCK during a ADC data transaction.

Here is a single ADC capture. SDO goes high when CS is logic low. I need to toggle it in order to initiate a conversion as per the datasheet. Then I send a command to generate a clock and wait to receive the first 16 bits, wait, receive the last 16 bits. That wait can be shorten but doesn't work without some delay. The data on the SDO line correctly translate to the digital value I read from the receive buffer.

I am currently using a rising edge clock polarity.

 

Here is a single ADC capture. SDO goes high when CS is logic low. I need to toggle it in order to initiate a conversion as per the datasheet. Then I send a command to generate a clock and wait to receive the first 16 bits, wait, receive the last 16 bits. That wait can be shorten but doesn't work without some delay. The data on the SDO line correctly translate to the digital value I read from the receive buffer.

You seem to have data when there is no clock. That‘s not right.

 

Here is a single ADC capture. SDO goes high when CS is logic low. I need to toggle it in order to initiate a conversion as per the datasheet. Then I send a command to generate a clock and wait to receive the first 16 bits, wait, receive the last 16 bits. That wait can be shorten but doesn't work without some delay. The data on the SDO line correctly translate to the digital value I read from the receive buffer.

It would be nice to see the CS on the image trace too.

For the controller MISO receiver input. I assume a setup of: sample middle, data idle low, sample on clock falling edge.

data sheet page 21:
1-Wire, boost Disabled, crc Disabled: 32 SCK cycles to read conversion data.

The CS signal frames a serial data transfer and initiates an ADC conversion process. The falling edge of CS puts the track-andhold into hold mode, at which point the analog input is sampled, and the bus is taken out of three-state.

The SCLK signal synchronizes data in and out of the device via
the SDOA, SDOB, and SDI signals. A minimum of 16 SCLK
cycles are required for a write to or read from a register. The
minimum numbers of SCLK cycles for a conversion read is
dependent on the resolution of the device and the configuration
settings (see Table 11).

The CS signal initiates the conversion process. A high to low
transition on the CS signal initiates a simultaneous conversion
of both ADCs, ADC A and ADC B. The AD4680/AD4681 have
a one-cycle readback latency. Therefore, the conversion results
are available on the next SPI access. Then, take the CS signal
low, and the conversion result clocks out on the serial output
pins. The next conversion is also initiated at this point.
The conversion result is shifted out of the device as a 16-bit
result for the AD4680/AD4681. The MSB of the conversion result
is shifted out on the CS falling edge. The remaining data is
shifted out of the device under the control of the SCLK input.
The data is shifted out on the rising edge of SCLK, and the data
bits are valid on both the falling edge and the rising edge. After
the final SCLK falling edge, take CS high again to return the SDOA
and SDOB/ALERT pins to a high impedance state.

 

It would be nice to see the CS on the image trace too.

For the controller MISO receiver input. I assume a setup of: sample middle, data idle low, sample on clock falling edge.

data sheet page 21:
1-Wire, boost Disabled, crc Disabled: 32 SCK cycles to read conversion data.

Here is a screenshot that includes the CS line.

 

You seem to have data when there is no clock. That‘s not right.

The datasheet indicates that SDO is in high impedance state when the CS is high

 

I‘ll return to @nsaspook ’s question - is your micro set to read the data on the falling edge of the clock?

 

Here is a screenshot that includes the CS line.

Why are you toggling CS low and back to high before the data CS low that starts a conversion and readies the previous conversion data for output?

 

I‘ll return to @nsaspook ’s question - is your micro set to read the data on the falling edge of the clock?

Datasheet indicates data is valid on both the rising and falling edge of the clock. I will look more into how the software is running to confirm though I believe it is set on the rising edge.

 

Why are you toggling CS low and back to high before the data CS low that starts a conversion and readies the previous conversion data for output?

My interpretation of the one cycle latency referenced in the datasheet and the timing sequence provided below. I seem to have focused on the low latency diagram that indicates that CS needs to be toggled for low throughput. It can be toggled only once at the beginning of the sequence and each subsequent sample doesn't require it at faster speeds, but disabling the initial toggle does not solve the problem in my case.

 

Datasheet indicates data is valid on both the rising and falling edge of the clock. I will look more into how the software is running to confirm though I believe it is set on the rising edge.

Changing the clock polarity from rising to falling does not change the outcome. I did this by changing the value of:

SpiaRegs.SPICCR.bit.CLKPOLARITY to 1

If this was incorrect, I will dig deeper but there are no comments in the registers for SpiaReg that specifically describe reading on the falling or rising edge.

 

There is no requirement to use 30k, but some piece of information I read about suggesting using high input resistance for this type circuit so it was what I selected.

My post was in error. the forward gain is 0.275, not 0.825.

ak

 

Just a wag, check the soldering.

Are you sure the analog side of the chip is powered (VCC) correctly? I've seen cases of BGA type package chips where a one or more power VCC pins were not making contact with the PCB while the VDD digital interfaces side was connected. The device would communicate correctly but the analog data was garbage or analog related commands were not responsive.

 

If for a fixed input voltage your getting "random" data out of the ADC,
then either the ADC is not working, or your receiving the data wrong.

My gut is saying
double check you driving the ADC digital controls as per the data sheet,
check your grabbing the data correct.

 

Just a wag, check the soldering.

Are you sure the analog side of the chip is powered (VCC) correctly? I've seen cases of BGA type package chips where a one or more power VCC pins were not making contact with the PCB while the VDD digital interfaces side was connected. The device would communicate correctly but the analog data was garbage or analog related commands were not responsive.

I may have to shelve the problem until the new batch of board shows up. I'm leaning more toward an internal issue with the ADC at this point. I cannot see underneath the device to ensure contact is made, but did try to solder the exposed footprint.

 

I have misunderstood the nature of the parts I am working with and would appreciate help in understanding where I went wrong and possible means of correcting the design to avoid unwanted voltage swing.

The problem is that my circuit produces a sine wave with a Vp-p greater than 3V when a DC voltage is applied to the input. I am unable to properly convert this to usable data with either my onboard ADC or the one integrated into the MCU.

My old oscilloscope lost the ability to transfer screen captures, so the best I have is a picture of the output when no voltage is applied. The circuit diagram is attached and shows that I am using the LT1630 which are dual channel rail-to-rail OP AMPS. I provide the correct supply voltages to achieve my desired output swing, and using a multimeter, can verify the output is properly being converted down to 0-3.3V (with .3V offset).

I am confident that my reference to system ground on the input of the ADC is incorrect so I attempted to use the MCU ADC with more success. But the digital value isn't static due to the sinusoidal nature of the output voltage. I created a simulation in LTSpice to set myself up with the expectation that a DC voltage would produce a static DC voltage but that is not the case. My peak-to-peak voltage is between 3-4V along the input range.