Low noise chopper and DIY nV meter

[miro123]

See attached example for initialization of IO as interrupt pins. Code was part of exeisiting project for STM32H7 but periphery should be the same for U5xx

[CurtisSeizert]

See attached example for initialization of IO as interrupt pins. Code was part of exeisiting project for STM32H7 but periphery should be the same for U5xx

Do you have a sense for how many clock cycles it took from the trigger on the EXTI pin to get into the ISR? I am using a board that I populated with just the MCU and associated components. I connected the timer for the CNV pin to EXTI0, and with a very minimal ISR, it is around 34 clock cycles from the falling edge of the trigger to the falling edge of NCS. It is only five lines of assembly code to do the write to the OCTOSPI IR to trigger the indirect read. I haven't used a profiler or anything to see how many lines it is to get to the ISR, but I imagine that is where the bulk of the time must be coming from. It is not really an issue for 500 kSPS, as falling edge of BUSY to rising edge of NCS is 974 ns at 48 MHz (using 4 lanes and prescaler of 1 on OCTOSPI), and I have 1.7 us to complete the transaction. Perhaps global interrupts are just not that fast and it would be better to handle things through GPDMA. For now that is not a concern, but it is something I am curious about. The code related to the ISR is below.

Code: [Select]


void nvicInit(void)
{
// Set Interrupt Priority
NVIC_SetPriority(EXTI0_IRQn, 0);
NVIC_SetPriority(GPDMA1_Channel1_IRQn, 1);
NVIC_SetPriority(TIM2_IRQn, 2);
NVIC_SetPriority(TIM7_IRQn, 3);

// Enable interrupts
/* EXTI0_IRQn is enabled separately after AD4032 has been set up */
NVIC_EnableIRQ(GPDMA1_Channel1_IRQn);
NVIC_EnableIRQ(TIM2_IRQn);
NVIC_EnableIRQ(TIM7_IRQn);

}

void EXTI0_IRQHandler(void)
{

OCTOSPIRead();

EXTI->FPR1 |= (1UL << 0);

}

uint32_t OCTOSPIRead(void)
{
OCTOSPI1->IR = 0U; // Trigger read by writing to OCTOSPI_IR

while(OCTOSPI1->SR & OCTOSPI_SR_BUSY); // Wait for operation to complete

OCTOSPI1->FCR |= OCTOSPI_FCR_CTCF;
return (uint32_t) OCTOSPI1->DR; // Read from FIFO
}

Also, I had assumed that the peripherals would be essentially the same between the F446 and the U575, but there are actually a number of subtle differences that make things tedious to sort through. The SPI FIFO is completely different, as is the way that OCTOSPI handles addresses, instructions, etc. The DMA is completely redone, but that's not a peripheral. More annoyingly, they have moved bitfields between various registers within these peripherals but have not done anything about the terrible non-contiguous bitfields that are apparently kept for compatibility in other peripherals. Maybe I'm in the minority here, but if you're going to break compatibility on nearly every peripheral, just get rid of the goddamn non-contiguous bitfields too.

Edit: Fixed a mistake in the conditional in OCTOSPIRead()

[CurtisSeizert]

I have given up on using octospi for the ADC reads, but thankfully I have SPI1 connected for reading and writing device registers on the AD4032, so I can use that for one-lane transfers of data, and I can stream output data over UART.

In the analog domain, things are getting there, but there is a large, persistent offset voltage on the output of the chopper block that is unrelated to the phase of the modulator/demodulator (about 0.8V on the 101x gain setting). My hypothesis is that it came from gate breakdown of one of the demodulator PE4140s when I was getting large swings on the Vcm node, leading to non-negligible gate leakage. It feels like things are getting close, so hopefully I can get some decent data out of this thing soon.

[CurtisSeizert]

It works! I had to make some modifications to the front end to make it essentially the same as it was in the first iteration to make it stable. I believe the persistent offset was from the load resistors being too small, but I changed them on a hunch and haven't had a chance to think of why it worked. The main issue in the oscillation was the dual emitter follower after the folded cascode. That was in place to better isolate the switching spikes from the demodulator switch, but I figured the capacitance in that switch is so small that it probably did not help much to have it in series with the base-emitter capacitance of the MBT6429. All of this work has used the LTC6655 version.

The ADC data make sense, but I still have some work to do to null out the ADC and associated signal conditioning offsets from that. Both the gain settings give very low residual offsets of 70 and 100 nV for low and high gain, respectively, with an arbitrarily chosen 250 Hz modulator frequency. I have set the offset DAC by hand with the debugger connected, and I have gotten it as low as I can with the scope. Closing the control loop in software at this point should not be too bad. Ultimately, I want to algorithmically set the switching levels for the modulator and demodulator to minimize injected charge, but that will be more difficult (and time consuming) to code.

With the default levels I chose, the switching spikes are much better than they were in the proof-of-concept version. I attached a trace at 1000x gain from the front end scaled to be RTI. The scope is AC coupled because the waveform is centered around 2.5V (RTO), and I used 50 averages because the scope is quite noisy at this level. At the op amp output, the previous version had switching spike peaks around 900 mV; these are less than 9 mV RTO. This is actually probably an overestimate because I am triggering on the spikes here, thus selecting the ones that are larger than the threshold. Changing polarity in the opposite direction actually gives much smaller spikes regardless, and dialing in the correction loop also helps.

I will continue testing once I get the code straightened out for automatic regulation of the Vos correction DAC and look at NSD, bias current, etc.

[Kleinstein]

The emitter followers at the input stage would add up to a factor of 5 to the front end gain. Without the emitter follower the transconductane gain is directly from the input stage. With the emitter follwer on should get a voltage gain with the 47 K to ground and then 2x5 K around the switch to convert back to a current.
So one would get a correspondingly higher speed or need larger compensation capacitors to get back to the old speed. This may explain a tendency to oscillate.

The switching spike is surprisigly short. So not much time lost for settling around the spike.
The ADC may already have some difficulty to resolve the spike, at least in real time.

For the scope picture the modulator clock should be a good trigger, to avoid trigering on a noisy signal, which may cause artifacts with averaging on the scope.

There is no absolute need to get exactly the same voltage for both phases. Even if there is a residual difference the average would still be a good way to get the result, at least for the slower sampling rates.  One has the freedom to accept some residual AC, if this helps reducing the switching spike at the input. It should help with the symmetry.
The critical spike / point to adjust would be at the input, not the spike at the OP-amp / output.

For the start I would use a manual adjustment to see how the gate voltages effect the spikes (could be different for both directions).
Only than could one think about an automated trim. This may need some extra hardware so that the µC can see the input spike, so not just coding.
I am not so sure that the output spike really correlates with the input spike.

[CurtisSeizert]

The emitter followers at the input stage would add up to a factor of 5 to the front end gain. Without the emitter follower the transconductane gain is directly from the input stage. With the emitter follwer on should get a voltage gain with the 47 K to ground and then 2x5 K around the switch to convert back to a current.
So one would get a correspondingly higher speed or need larger compensation capacitors to get back to the old speed. This may explain a tendency to oscillate.

The switching spike is surprisigly short. So not much time lost for settling around the spike.
The ADC may already have some difficulty to resolve the spike, at least in real time.

For the scope picture the modulator clock should be a good trigger, to avoid trigering on a noisy signal, which may cause artifacts with averaging on the scope.

There is no absolute need to get exactly the same voltage for both phases. Even if there is a residual difference the average would still be a good way to get the result, at least for the slower sampling rates.  One has the freedom to accept some residual AC, if this helps reducing the switching spike at the input. It should help with the symmetry.
The critical spike / point to adjust would be at the input, not the spike at the OP-amp / output.

For the start I would use a manual adjustment to see how the gate voltages effect the spikes (could be different for both directions).
Only than could one think about an automated trim. This may need some extra hardware so that the µC can see the input spike, so not just coding.
I am not so sure that the output spike really correlates with the input spike.

The emitter followers I deleted (Q19 in the attached) don't provide any additional voltage gain prior to the op amp. The point of the resistors around the switch was to increase the impedance at the inverting input to slow down the op amp integrator. They are symmetrically placed about the switch so that source and drain see approximately equal impedances. When I was simulating this input stage, increasing the value of those resistors did not increase the loop gain, but it did alter the frequency response. They may speed things up, but they are operating at a a rather low collector current, so they also introduce some delay. I calculated this while I was selecting values, but I don't have the results handy.

I actually have triggered on the demodulator clock, but doing so shifted the levels of the switching cycle as observed on the scope somewhat. I may try to use both outputs and subtract them to see if that helps things. It appears to be helpful to keep the transitions as small as possible for minimizing switching spikes from playing around with this some more. My control loop seems to have a tendency to work well and then go crazy. I think this may be due to something going awry with the DAC SPI bus. The problem seems to disappear when I put a breakpoint around where the update DAC code is, so I haven't figured out what the issue is yet.

The ADC input circuitry will slow down the spike somewhat, though I don't know exactly how much it will delay it by. The auto adjustment was actually for overall bias current by switching in a 10k resistor between the inputs with a relay that is available on the board. I can adjust the levels to try to match the voltages with and without the resistor switched in. I will need to see if the results of such a thing actually correlate with reduced input bias current well, but I am not quite there yet. I have done some experiments on a board I made to experiment on just switching levels with the PE4140, but I'll have to see if those lessons hold for this more complex system.

[Kleinstein]

If removing the emitter follower work well, this is good. The added dealy from slow. low current transistors can indeed be an added problem.

The scope probe could be enough loading to effect the timing of the chopper signal a little.

The 10 K resistors may be a bit low to measure the bias current, but it could be enough to compare the response right after switching. The larger input current spike, the larger effect of the 10 K resistor at the input on the switching spike seen at the output. If going by the bias, one could increase the chopper frequency for the adjustment as the bias current from switching should scale with the frequency.

For the adjustment of the spikes there may also be the option to use a little delay between the chopper side and the demodulator side. The demodulator side may also have a short neutral phase. So it is not just the gate voltages, but also some timing to play with.

A SW problem that disappears with a breakpoint can be hard to track - maybe be a timming issue / race condition.

[CurtisSeizert]

OK, at this point, I think it is fair to say that I have it in a reasonable state where the core feature works. The issue I was having with inconsistent SPI writes to the offset DAC was due to a number of things going wrong, actually. I made the way the data are indexed more robust so that it resynchronizes to the timers that drive the modulator, etc., every cycle. I am trying to get DMA to work on this thing so I can offload the UART transfers, which take a fair bit of processor time waiting for various flags to be set when it's run in a blocking configuration, but I accepted doing blocking transfers for the moment to get a feel for how the meter is working.

The way that data are gathered is reasonably simple, at least at a high level. The ADC input switches operate at half the frequency of the modulator/demodulator. When the modulator changes phase, the meter waits for a settling time to elapse (I have used 10 us as a default) and then begins triggering conversions using the onboard sample averaging of the AD4030-24 (I ended up using the 2 MSPS-capable part). The ADC data are used to populate an array for each mod cycle, and average offset is calculated by subtracting the elements of the second half of this array from those of the first half. If the ADC input switches are in the inverted configuration, the average and average offset are negated. This is done for some whole number of ADC input switch cycles, and if the offset is positive, the offset DAC code is incremented. If it's negative, it's decremented. This actually seems to make the average offset stay considerably below the calculated LSB size of 43 nV, even when the update is done much more slowly than the time constant of the RC filter on the DAC amp. It settles out quickly enough this way that there's no need for anything fancier, though I have programmed in a known value that's pretty close as the default.

I will probably need to do a bit more work on sample processing. As one can see from the NSD of some data taken at 7.5 SPS using 1000x gain, there are spikes at f/(2^n) where f is one of the clock frequencies. They are all harmonically related, so I don't know which. These may be related to insufficient settling time (remember, the ADC signal conditioning is much slower than the front end amplifier). I suspect the ADC switching is the likeliest culprit because it is slower and probably spikier. I will continue investigating on that front. Even with this, the noise at 101x gain is remarkably good, and it is looking like a dynamic range of >140 dB is doable.

I attached some sample data showing settling of the meter from reset at 101x gain and the NSD to 0.01 Hz at 1001x gain. Both were 7.5 SPS with a modulator frequency of 30 Hz. Also, I have noticed that the modulator frequency has a noticeable but relatively minor impact on offset voltage. On 1001x gain, I see about 75 nV offset at 30 Hz and about 105 nV at 990 Hz.

[Kleinstein]

There is still something odd going one, with a period of some 8 seconds on so.  The 30 Hz modulation may cause interference with 60 Hz mains, though ideally it should still suppress mains hum well.

Some 8 seconds could also be the speed of thermal oscillations - at least I have found some such oscillations in that frequency range with a closed case. The protection part is still befor the chopper part and could react to themperature changes. It could make a difference if the short is internal via the relay or external, including the protection.

Except for the extra low frequency the noise spectrum looks really good.
As a baseline it could also be interesting to look at the noise of the amplifier without chopping. This could give a hint on where the 1/f starts to become significant and when faster chopping would not help much anymore. Chances are one could get away without polarity reversals at the ADC for this.

[CurtisSeizert]

I looked at the spectrum again, and I realized it's not what I originally said - the spikes are harmonics of about 0.12 Hz. I think it is plausible that it's aliasing from the line frequency, but I'll see what I can figure out. The very low frequency noise is a bit odd; I have the output attached to my 3458 and it is very quiet at 100 NPLC, even with thermal EMFs from the SMB connectors. I am not powering it with a battery but rather with a bench supply feeding 15V to the SMPS daughterboard, so it's possible that ground loops with the debugger attached are to blame. I'll test these things and report back. From simulation, the NSD should be around 1.1 nV/rt Hz. The ADC and associated drivers will not add much to that because of the first stage gain.

[CurtisSeizert]

I've done a handful of experiments on the NSD, and I have noticed a few things about the spikes:

-The fundamental is always f_mod/64
-Changing modulation frequency has no impact on the frequency ratio
-Changing the number of cycles per DAC update has no impact
-Changing the gain has less than a 10x change on the size of the fundamental, but it does change the lp filtering characteristic for the peaks (see the attached spectra to see what I mean)
-Turning off the ADC input switching has no impact
-Adjusting switching levels and dead times for the modulator and demodulator has minimal impact (but is helpful to optimize nonetheless)
-The spikes are also present in the offset data, but I have not compared the phase between offset and average

I feel like the spikes represent an idle tone of some sort, but that is strictly at hunch level. As the fundamental is 1/64 * modulator frequency, a repeating sequence using every combination available for six bits would generate such a spectrum. I haven't done the math on which bits those would be based on the power contained in the spikes, but that's where I am at with it. I don't think it represents a problem per se because those spikes can be filtered by averaging. I am curious to see whether the spikes are present in the analog output of the chopper stage.

I have also been checking the overrange flags from the AD4030, and there are some clear patterns, but the reasons for some of these issues are unclear. For example, the amount of settling time required to avoid an overrange flag is very large considering we're looking at like 100 uV at the input to the ADC signal conditioning block with a range of about -2.3 to 2.3 V. At 315 Hz modulator frequency, I would get sporadic OR flags at 100 us settling time but none at 105 us. There is also some frequency dependence, with 100 us settling at 165 Hz giving OR flags for maybe 10-15% of data points. Some of the datapoints with OR flags are clear outliers, maybe 30 nV from the mean, others are right in line with everything else. I am guessing these are an issue with the code, but I haven't gotten around to putting a probe on the ADC inputs to confirm this.

I do have some pretty good data from an overnight capture I took after optimizing the deadtimes and at least partly optimizing the switching levels. Ultimately, I will probably need to do a design of experiments to optimize these parameters once things are farther along. The capture was taken without the board in a proper enclosure as one panel was missing and a couple polyester cleanroom wipes were stuffed in the opening. The NSD is flat down to just below 0.1 Hz, with some increase in noise density at very low frequencies. I am pretty confident this increase is due to thermal fluctuation. In the time domain, when average the data down to give 1 sample per 10 seconds, I get 5.6 nV p-p over a 20k second interval. I can't get it to be this quiet during the day, so the fluctuations that are present on a long time scale are probably thermal drift of some description. I imagine a proper enclosure would help. Also, these data have only been processed by averaging; the residual offset is really only about 50-something nV. It looks like the sensitivity to temperature variation is better with this revision, but I would need a head-to-head comparison to really determine this. I will also have to bring up the multiple TMP117s on the board to correlate offset to temperature.

[Kleinstein]

In the time domain data from the earlier post is looks like there are some outliers every 8 seconds or so. To gether with a fixed ratio to the modulation this looks really like a software or maybe communication issue (e.g. DMA buffer warp around if a circular buffer is used).  External interference should not give a fixed ratio to the modulation frequency. I would also not absolutely exclude an isssue with the ADC - it is a relatively new chips.

Getting the OR flag is indeed strange - maybe the comparator based external protection is somehow triggert sometimes and this way adding an extra spike in the ADC buffer part. As far as I anderstand it the ADC already does averaging inside the chip to reduce the data rate - so short spikes or fast ringing that causes an overflow my not be visible after averaging. There may also be an issue with waiting and restarting the conversions, e.g. with a buffer not fully empty. It may be worth to also look at the more raw data, as there is a chance that the extra peaks in the frequency domain are a result from a small number of very wrong readings in the time domain, right at the same time in the cycle. The strong harmincs also point in this direction. If it is the first reading after the wait, maybe include a dummy reading instead of waiting.

edit:
It may also be worth to try it without the DAC updates, so a fixed offset setting. The DAC updates could cause extra settling.

[CurtisSeizert]

I am having fun trying to get to the bottom of this. So, the obvious question to ask is do we see those peaks in the analog output. I took a capture at 1 kSPS, got the FFT (attached, referring to the log x axis one), and I immediately thought, no it's not present in the analog output. But then I checked out the modulator peak, and there it is - it just hasn't been aliased as it has in the ADC data. At this point, however, we have people coming over, and I risk the wrath of my fiance if I'm not ready. So, for anyone playing along from home, here are the data. My immediate suspicion is I accidentally enabled dithering on one of the PWM signals, but I don't have time to dig into that.

[CurtisSeizert]

First off, when I suppressed DAC updates after the loop had settled, there were no spikes in the analog out. I know the DAC updates were staying in sync with the modulator, so I worked off the hypothesis that the spikes were probably a phase modulation spectrum of the modulator frequency. I think the broad humps off to the side represent a amplitude modulation from the random chance that the DAC code will increment or decrement, but I may be wrong.

I looked into it, and there were actually a few problems with the code. The OR flag issue was probably caused because the SPI bus could not complete the read within the allotted 1.7 us window, which I think was a function of how busy the CPU was when the interrupt was generated. I didn't check on the actual board and fixed all the timing issues (there were more) on my MCU-only board where the CNV signal is tied to the BUSY line. I had to use some sketchy code to do this, as I am not sure there is a way of using DMA to trigger the SPI bus when NCS is controlled by GPIO. The SPI start signal actually comes before the register write to pull NCS low because it takes a very consistent (but long) time to actually start pulsing SCK after giving this signal. I had to increase the overall processor speed to 64 MHz to do this, but this had no noticeable impact on current draw of the SMPS board (50 mA before and after, much of which is because my stopgap Cuk coupled inductor is probably saturated).

On top of this, the CNV pin was going high during initialization of TIM8, which controls it, so all the blocks were out of phase by one sample. The DAC updates were being performed in a callback function after some unrelated flow control, so there was a variable amount of time from a phase change to a DAC update, which was part of the issue causing the spikes. I ended up putting the update in an ISR that triggers every modulator cycle, so the DAC code actually changes one cycle after it is calculated. This was not enough, and it actually made things somewhat worse because it put the spikes closer to the fundamental and thus at lower frequency in the ADC readings (by a factor of 2). I figured this was probably because the blocking UART transfers were making it take a variable number of cycles to get to the ISR, so I had to figure out why the DMA was not working for that. For the STM32U5, the UART has an 8-byte FIFO, which I had enabled. There is no mention in the reference manual (that I could find) that this will make it not work with DMA, but that seems to be the case. Once I had solved this, the spikes were gone.

With proper phasing of the ADC reads, there is remarkably little energy in the fundamental in the analog out, but there are two broad side lobes. Looking at the ADC data, there are no spikes and the spectrum is essentially flat. The white noise density is closer to the analog out than before, but still a bit higher. If you look at a spectrum of the offset data, you see the lobes, and the white noise density is a factor of sqrt(2) higher. Fixing this stuff did not affect the very low frequency noise, which is still probably dominated by thermal fluctuations. I hope to bring up the TMP117s today to be able to correlate these data with temperature.

[Kleinstein]

The data look really good now.
The side lobes seen at around some 295 and 335 Hz seem to correspond to the position of the noise peak in the offset noise spectrum around 20 Hz. It is still a bit odd where the 20 Hz (or a little more) come from. The difference from the chopper and mains harmonics would be more like 15 Hz.
It is nice that there is not that much extra noise or interference at around the modulation. So there is no limitation to frequencies well below the chopper frequency as with a classical chopper.

I also suspect thermal fluctuations as the main source for the extra low frequency noise. It could make quite some difference between the internal short via K1 and an external short that includes the protection and the terminals.

[CurtisSeizert]

I realized there is an issue with how the correction DAC feedback works, and this is the cause of the humps in the offset spectrum (and sidebands in the analog out). The LSB size for the correction DAC equates to about a 40 nV change in offset (this uses 22k degeneration resistors and a 93 uA tail current for the correction diff pair). The feedback was structured such that if the offset voltage was >0, the DAC code would increment, and it would decrement if it were less than or equal to zero. The problem here is not hard to see - if the offset voltage is, say, 10 nV, incrementing the DAC should bring it to around -30 nV the next cycle, increasing the absolute value of the offset. Next cycle it jumps back positive, making an improvement. So when the loop settles, just under 50% of the DAC updates increase the absolute magnitude of the offset voltage. The broad peak is a resonance in the network, and I believe it should always be centered on a value corresponding to an integer divisor in f_update/n. Here, f_update is 157.5 Hz, and the peak is centered around 22.5 Hz. If you actually change the code to increment or decrement the DAC value by four codes, Q increases, and the center frequency increases to 26.25 Hz (157.5/6). Interesting stuff.

I added a deadband where the code is neither incremented nor decremented to improve the situation. There is still oscillation with a 1 LSB deadband centered on 0. Increasing the deadband to about 2 LSB makes it no longer oscillate, with the offset spectrum presumably looking just like the NSD of the front end were it not modulated. Of the two, this gives less total power in the offset spectrum (up to 55 Hz to avoid the mains frequency). This makes sense, as the direction of the next transition should be random if the code change puts the offset at (theoretically) 0 nV. With the 1 LSB deadband, a code change is more likely to result in an opposite code change next. You can see from the analog out that the fundamental is still pretty tame, and the total noise power related to the fundamental (including the side bands) is lower here by about a factor of 4 (subtracting out broadband noise). The amplitude of the fundamental here is about 5 nVRMS integrating from 312 to 318 Hz and subtracting out white noise.

[CurtisSeizert]

With the temp sensors running, I put everything in an actual enclosure (kind of - there were wires going out to the DC power supply) to get some data on offset voltage measuring the internal short. The modulator frequency was the standard 315 Hz that I have been using, with 104 us settling time and the ADC running at 520 kSPS. The DAC update deadband was +/- 40 nV. Unfortunately, once I put it in the case, the sporadic issue I was having with the temperature sensor near the input stage popped up again, but there are two other sensors, and I just used the sensor near where the ADR1399 is in these plots. Without the voltage reference there, this sensor gives a pretty good idea of the ambient temperature in the case. The sensor near the ADC, which is under a metal shielding cover, reads consistently 0.95 C higher. I also took a capture starting the moment I turned it on to show the warm-up time. There is an excursion in the very beginning of that capture where I turned it off and on again when I realized the input stage temperature sensor was giving bad data in hopes that would fix it. All the captures are averaged down to 0.1 SPS.

The stability of the offset for long-term captures is about an order of magnitude better than the proof-of-concept version, which was sensitive to changing temperatures (i.e., the offset was correlated to the first derivative of temperature). In the enclosure, the residual offset is about 20x better than it was for the internal short on the proof-of-concept version. With the LTC6655 reference, the output is stable within about 1 nV in 15 minutes, 20 if you're being careful. The "corner frequency" in the FFT in the enclosure is reduced as well, and it's about 5-6 mHz in the spectrum I took. Stability will probably take longer with the ADR1399 because I expect the board will dissipate about 50% more power with it.

[Kleinstein]

The temperature shows still some "periodic" part, with a bit under 1000 seconds period. Is this an external temperature variation, e.g. from the heating / AC system ?
I have seen temperature oscillations inside a case, but this was considerably faster (more 10 seconds). So I don't think it is this.
There seems to be some part in the voltage reading with a similar frequency. So there could still be some thermal part to limit the stability.

The LTC6655 reference should be good enough for most purposes. The amplifier and scaling before the ADC has quite some resistors to effect the gain. So the advantage from a super stable reference would be limited anyway. At least with a gain of 1000 and likely still a gain of 100 the meter is limited by the amplifier noise, not the ADC or reference noise.

Higher power does not directly translate to longer settling time. It is more the heat capacity and thermal resistance to set the speed. The regulated temperature in the ADR1399 would more speed up the time needed to reach a stable temperature. Higher power may need more time constants because the difference from cold to hot is larger.

[CurtisSeizert]

The periodic part of the temperature is, as far as I can surmise, the fan cycling on and off for the HVAC system. The reason for the ADR1399 is the gain of 100x (200 actually, including the ADC driver). The RTO noise density of all the analog signal conditioning is around 360 nV/rt Hz at that gain. For a full scale input, reference noise will dominate below 0.1 Hz with the LTC6655. Anyways, I have both, so we will see if there is a noticeable difference at some point.

Here's a capture during the day (I averaged over 20 s to make things a bit clearer). I turned the thermostat up 1 F around 12000s, and you can see that the board does react to the change in the first derivative, but there is no noticeable impact on offset voltage once the temperature settles. You can see some periodicity to the noise for the voltage. It seems to be lagging the periodic temp fluctuations by about 90 degrees.

[dietert1]

I had this first derivative temperature dependence, too, when looking at my low thermal EMF DIY relay scanner. In my understanding the effect is caused by temperature changes "creeping" inside the board and causing transient thermal gradients and thus EMV.
That scanner is well protected from ambient temperature changes, but does not have active temperature control. So i installed a precision measurement of the temperature and calculated the first derivative to correct the effect numerically. This improved residual EMF from some nV to a fraction of a nV. See: https://www.eevblog.com/forum/metrology/scannermultiplexers-for-voltage-references/msg3971414/#msg3971414.

Regards, Dieter

[CurtisSeizert]

That scheme for temperature drift compensation is what I hand in mind here, at least as an option. I figured that heat conducted from the edges of the board to the case would be more problematic, so I added isolation slots around sensitive junctions and removed the ground plane from the edges of the board. It would be interesting to see if the performance is better when it is supported by standoffs, but that would require putting it in a somewhat larger enclosure, which could also skew the results.

I have a reasonably functional interface up and running, so I can pause the acquisition, update the parameters, and restart it to see the impact, which is nice for automating experiments.

I made an interesting observation about the noise floor of the lower gain setting, and I haven't been able to figure out what exactly is going on. At the analog out, the RTI NSD with shorted inputs is around 1.8 nV/rt Hz, but the ADC readings showed higher, around 3.0 nV/rt Hz. I changed the ADC input switches so they were both connected to IN-, and I saw a similar noise density, scaled as if I were measuring something at the low gain setting. This was sensitive to sampling frequency changes, with it getting noticeably better going down from 520 kSPS to 500 kSPS, but going up again as I reduced the sampling frequency further to 400 kSPS. That made me think it was EMI from either the ADC reads or I2C, but I ruled out both. In the first case, I showed there is no impact on NSD from altering block size over a span of 4 powers of two, and in the second I just turned off the I2C bus.

I adjusted the parameters so I would only get one block per phase so that ADC reads would not interfere with sampling, as I can only do slightly more than 500 kSPS without NCS going high during the quiet zone for the next sample. At 1 MSPS, the NSD dropped significantly to 0.8 nV/rtHz (again, RTI as if I were actually connected to the chopper stage), and at 2 MSPS it went down even more, to 0.25 nV/rt Hz. According to ADI's calculator (for the AD4630), with my input RC filter, this is far to fast for the input to settle from charge kickback (at 2 MSPS, it is 54 LSBs with 68R/2.7nF, 3.5 LSBs at 1 MSPS, and 0.02 LSBs at 500 kSPS). I thought I must have been just seeing the RMS sum of input stage noise and ADC + driver noise at this point, but when I ran the acquisition as normal at 2 MSPS, the RTI noise was still significantly greater than at the analog out, about 2.5 nV/rt Hz. So there seems to be some interaction term here, but I haven't been able to get to the bottom of it yet. There is a pole-zero network in the feedback for that gain setting (the gain really needs to be 60 dB at high frequencies for stability), so aliasing could be a concern here. The poles of the filters for the ADC drivers are about 160 and 110 kHz.

I also found that both gain settings seem to benefit from running at much higher modulator frequencies with a greater number of modulator cycles per ADC switch cycle. The impact on residual offset jumping from 315 Hz to 7200 Hz is <10 nV, and a much shorter settling time of 4 us is required at the faster modulator frequency to get a good aperture ratio (It is about 0.92 with the settings I used at 7200 Hz). This brings the noise for the high gain down to 1.1 nV/rt Hz, which if you correct for the aperture ratio would be 1.06 nV/rt Hz, which is essentially the same as what it is in simulation.

I have also done some experiments with the input bias current by checking the change in offset by switching the relay that shorts a 10k source resistor. There is some impact with modulator high levels, with the highest setting seemingly the best. Consistent with my experiments using just the PE4140, the bias current is best when the switch just barely turns off. In this case, a low level of -40 mV was good (I didn't try 0 mV, and this is very close to the threshold voltage, which is around +30 mV). I do feel as though this would reduce the source impedance somewhat, but the NSD for 10k was right on the dot, so it hasn't been reduced catastrophically. Anyways the input bias current was around -1.7 pA at this level (i.e., the average reading was 17 nV lower with 10k than with a short). This is at 315 Hz. I will need to run more experiments to see if this is actually a good idea and also what the impact of deadtimes is. The relay switching the capacitor is stuck, so I need to replace it to see the impact of input capacitance.

[Kleinstein]

An input bias current in the 2 pA range would be really good for such a low voltage noise. There is however still a chance that adding the 10 K resistor to the input can have more effect than just from the bias current. The resistor could also change the settling, which may be an issue at least for the faster modulation and short dead time.

I am a bit surprised to see so much effect of faster modulation on the noise. Normally the JFE2140 and other parts should not have that much 1/f noise at 315 Hz and higher. Beside noise, it could of cause also be mains hum - the magnetic part is hard to shield.

[voltsandjolts]

Interesting topic but I'm an amateur at this stuff. Just a thought on transient thermal emf's.....if the PCB had components on topside only, it could be placed atop a copper plate to act as an iso-thermal block, perhaps with thermal conductive sponge sheet between them.

[CurtisSeizert]

Interesting topic but I'm an amateur at this stuff. Just a thought on transient thermal emf's.....if the PCB had components on topside only, it could be placed atop a copper plate to act as an iso-thermal block, perhaps with thermal conductive sponge sheet between them.

I had that thought about using a vapor chamber attached to the PCB with thermal epoxy for a nanovolt relay scanner card, but I hadn't really considered it for this because there are a lot of components.

An input bias current in the 2 pA range would be really good for such a low voltage noise. There is however still a chance that adding the 10 K resistor to the input can have more effect than just from the bias current. The resistor could also change the settling, which may be an issue at least for the faster modulation and short dead time.

I am a bit surprised to see so much effect of faster modulation on the noise. Normally the JFE2140 and other parts should not have that much 1/f noise at 315 Hz and higher. Beside noise, it could of cause also be mains hum - the magnetic part is hard to shield.

I don't know the reason why it would be any better at such high frequency. I am now in a better position to do systematic testing for such things, so I can map out the impact of modulation frequency on noise. I had initially tried higher frequency because it is above the zero in the feedback network at 101x gain, so the modulated offset signal would be fed to the ADC at a higher gain. It actually seems to have more of a relative effect on the higher gain noise, which does not have the intentional zero in the feedback network.

I am going to map out the impact of different parameters on things like the apparent bias current, but I am still at the stage of figuring out what matters before I setup a design to get a response surface. It seems that it will be feasible to null out the apparent bias current at a given frequency, but it does not seem that one code will give a null at all frequencies or what the relationship there will be. The impact is quite linear at a given frequency, so by measuring two points, you can probably get within 1 pA of zero in one or two tries. At 3600 Hz, the resolution in the limited space I explored was about 250 fA/LSB of that DAC. I guessed 485 would be close from points at 400, 500, and 600, and I got a bias current of 0.34 pA. That corresponds to uncanceled charge injection of about 0.1 fC per cycle.  It was dicier at 7200 Hz, but I managed to get it down to -2 pA. My hypothesis about this effect was that there is JFET leakage current that is not dependent on modulator frequency and dynamic current from charge injection. Presumably were the static component zero, the code required to reach a null would not vary much with frequency. That doesn't seem to match the data at this point, but I'll need more data to rule it out. I attached two plots of modulator low level DAC code vs. bias current.

The way the code is set up right now, it will automatically fill up each cycle will the maximum number of ADC sample blocks when you feed it a modulator frequency, settling time, ADC sample frequency, and ADC block size. I will add an option to suppress that so I can take quick bursts at a variety of points in the switching cycle. With the input 10 nF capacitor switched in, the bandwidth with the 10k resistor in is only 1.6 kHz, so at 7.2 kHz modulator frequency, there should not be much change. I did that experiment, using a block that took about half the cycle and put it at the beginning and end. In that case, the difference was not statistically significant. When the modulator frequency is less than the bandwidth, there almost certainly will be an impact of dead time.

[Kleinstein]

A combination of a fixed bias (e.g. leakage from FETs and diodes) and a net charge injection from the modulator sounds resonabel. The slope in the two curves with bias vs DAC value is close to the 2:1 frequency ratio.  A DAC value of ~ 490 to gets zero bias with 3600 Hz. At 7200 this would 2 fold compensate the static bias.  This would suggest some +160 pA of static bias.

The diodes and JFE2140 should not give that much leakage. So chance are it could be from the modulator FETs, that are made for RF performance and not so much for low leakage.