I noticed you have your Vref set to Vdd/2. That is a pretty noisy ref selection.
You would be better off using internal 1.024, bypassed as the selection. But
then you have a CM problem in that you would need to offset the bridge, maybe
an R in the hot leg......an analysis would be needed as that would alter G.
Instead of wasting time fighting analog circuits why not to switch to one of the low-cost PSoC5LP boards (-059 kit, FreeSoC, SchmartBoard, ...)? Then you can use DelSigADC directly (no OPAMPs necessary). Moreover, I notice that you want to modulate voltage to the bridge, so it will be essentially lock-in detector. For that DelSigADC has special modulation input to change polarity. If you switch to PSoC5LP, I will provide you a lock-in project example.
Other thing is that if you provide voltage to the bridge from digital pins, do not expect it to be nice and steady. There surely be digital noise and instabilities.
SAR Ultra-High Speed when power consumption not primary concern? N bits - 2^N -1 Comparators Caps increase by a factor of 2 for each bit. Thermometer Code Encoding Sparkle codes / metastability, high power consumption, large size, expensive. Conversion Time does not change with increased resolution. Component matching typically limits resolution to 8 bits. 2^N-1 comparators, Die size and power increases exponentially with resolution.
Here is a chart of the SAR ADC . I looked at your scope trace and I think you have a great oscillator. Start adding some bypass caps and inductors to shunt that oscillaiton to ground. I still say to try the star ground process..
The development started on the PSoC 4 BLE because it was shiny and new and I didn't know all its limitations yet. Now the client wants a demo in a few days so there is no time to get new parts and change direction at this point. I'll just get it to look as good as it can by any means necessary.
The irony is that we were already talking about going to a PSoC 5 plus a PRoC for the next version.
After carefully hand-building a prototype "shield" with perf board (I know, I know), I was still seeing noise equal to as much of 20% of full scale. I was pretty discouraged at that moment, but I went ahead and tried some heavy smoothing (time-weighted moving average) of the samples in firmware (256 to 512 samples averaged, perhaps overkill).
Well, unlike the near-oscillator-like noise I was getting earlier, this noise must have been pretty Gaussian because the averaging generally yielded results within a gram or two across a range of close to 500 gm, or less than 1% error.
If we do move on to a second alpha or beta design, however, I am DEFINITELY looking at the PSoC 5 and its 20-bit delta-sigma converters.
Yes, diminishing returns, as the square root -
You have a very impressive library of documents and it seems you can recall where and what they all are at a moment's notice.
This one should be useful in improving the perceived overall speed/timing performance of the device, which is important for a proof-of-concept demo. Thank you.
Who am I again ?........
When I was a student in 1970 I discovered Motorola published ap notes.
So I wrote them a letter, explaining who I was etc.., and asked if I could
get some of them. In a week several boxes showed up, ~ 250 ap notes
at the time as I recall, and I was estatic. Over the next several years I
read I think ~ 80 % of them.
That was the start, now the net is my presonal library so to speak. My
only complaint is cannot get access to IEEE library w/o some steep
dues. But I think that will change, hopefully.