LM399 based 10 V reference

[Andreas]

Regarding the ripple, what if, as a test/temporary solution, instead of lowering MCU consumption you try a reverse way - don't allow MCU to rest ?
This way instead of sleep mode in the main loop, this will become busy loop, doing anything (maybe just the same detection of button press).

Hello,

thats what Kleinstein already suggested.
But I do not like to patch hardware problems by software without knowing the reason.
Experience says that the problems will return. (then when you do not expect it).

with best regards

Andreas

[branadic]

Andreas,

are you sure about the problems of the oscillator itself? A difference between your circuit and mine is, I use AD8675 for the first and LTC2057 for the second opamp. Could it be that you measure some interference? Just a thought, maybe it's abolutely on the wrong track.

-branadic-

[Andreas]

Hello,

thats really a point worth checking.
On the other side: Up to now I have never seen the excessive noise with the 20 MHz XTAL
only with the 4.9152 MHz.

I see this as indication for the oscillator with low frequencies.

with best regards

Andreas

[Andreas]

Hello,

now it is clear to me what is going on with the 4.9152 MHz X-TAL.
It is not a instability of the Oscillator but simply a very marginal analog filter together with the short integration time of my ADCs.

To analyze this I monitored the 2400 Hz PWM signal with a mask test of the oscilloscope.
But all what I could find is that the 417 us period time changed around 2 ns over temperature.
(so around 5 ppm change over 20 deg C)

The oscilloscope probe 12-15 pF also changed the output voltage by 1-2 ppm.
So it is shurely worth to keep the parasitic capacitances constant around the PWM signal by shielding it on both sides.

For further analyzing I made a LTSPICE model of the complete cirquit.
Since there is no model for the ADG419 available on the ADI site I looked for a replacement.
I found a FAQ note that the switch in ADG411 is the same than for the ADG419 and so you can replace the ADG419 with a ADG413 which is in the same datasheet as the 411.

Then it got clear: the remaining ripple at the output of the filter is > 1mVpp with the 5 MHz XTAL. With a effective integration time of 20ms (1 NPLC) and if there is no exact integer number as ratio between the 2400 and 50 Hz we have only a dampening of a factor < 50 due to the integration time. So I see up to around 30 uVpp at the ADC depending on the LTC2400 internal oscillator frequency against the XTAL oscillator frequency.
That also explains why I have sometimes the excessive noise at high temperature and sometimes at low temperatures: The LTC2400 is not held at constant temperature.

Even at 20 MHz XTAL the ripple of the ION filter (without R15 tap) is > 100uVpp which is in my opinion too much for a reference cirquit.
So in any case we have to improve the filter.

with best regards

Andreas

[Andreas]

Hello,

I also tried to optimize the code for the ATTINY.
Here the first result (up to now only tested in simulator).

With this implementation the interrupt routine is around 120 cycles so the timer can be operated with a 1:1 divider instead of 8:1.
So a 2.45 MHz XTAL will give nearly the same PWM frequency like 20 MHz with 8:1.
But hopefully with much less current.
I think I will try this on week end.

with best regards

Andreas

[Kleinstein]

The new code looks odd - very much like the PIC code, but I don't see how the information flow from the q to the c values should work. I only see the shifts for the c's and no effect from the q's. So I guess there is something wrong in the code.

I very much like the idea of improved code to make it work inside the 250 cycle window and thus 1:1 timer clock. In this case one may not need a sleep mode anymore and still get low power consumption.

The oscillator has different settings for different frequency ranges. So one may have to adjust the fuse settings when going from a 20 MHz to a 4 MHz crystal.

[branadic]

First: 2.5MHz crystals are available, so this could help to prevent 1/8 divider for the timer.
https://www.reichelt.de/standardquarz-grundton-2-500000-mhz-2-5000-hc18-p1852.html?&trstct=pol_1

Second: Andreas, were you able to verify the simulated results by real world measurements in time and frequency domain? Up to know I couldn't measure such voltage swings.

Third: What if you change your simulation to R15 tap? Any improvements?

Instead of AD411 I used a switch model in LTSpice with parameters such as slew rate and resistance given from the datasheet.

I'm not an expert on software/microcontroller firmware so if anyone here with the necessary skills on AVR microcontrollers and Assembler programming would make a code suggestion we can test it. I can also setup one board for you to join the club.

-branadic-

[Andreas]

The new code looks odd - very much like the PIC code, but I don't see how the information flow from the q to the c values should work. I only see the shifts for the c's and no effect from the q's. So I guess there is something wrong in the code.

You have to think in assembler.
It is essentially the "Bresenham" code but 3rd order interleaved.

with the 8.14 code I have to shift all fractional values by 2 bits left (ValFrac4 = ValFrac * 4)
So I get an overflow into the C bit of the Status register when 65536 or above is reached.
The inline code shifts this Carry-Bit directly into the Bit 0 of the C0, C1 or C2 variable.
All other bits are shifted left (so I avoid the assignments from c[2] = c[1] ...)
In the disassembler the ROL command is translated as ADC Rx,Rx (which is the equivalent).

I have tested both codes in simulator in parallel and have compared the output values over
a simulation time of > 70 seconds real time. (so more than 10 cycles of the random code).
 the error counter of comparison of the two results was zero the whole time.
So dont tell me that it does not work.

With best regards

Andreas

[Andreas]

Second: Andreas, were you able to verify the simulated results by real world measurements in time and frequency domain? Up to know I couldn't measure such voltage swings.

Third: What if you change your simulation to R15 tap? Any improvements?


-branadic-

The measurement for the 20+5 MHz xtal is on the previous page see e.g.:

https://www.eevblog.com/forum/metrology/lm399-based-10-v-reference/?action=dlattach;attach=630511
The results are not exact but similar.

Attached the LTSPICE cirquit and the ADG413 model so you can evaluate the R15 tap by your own.

Note that you will see the ripple only with either the scope or with a relative short integration time (1 NPLC).

with best regards

Andreas

[Kleinstein]

The new code looks odd - very much like the PIC code, but I don't see how the information flow from the q to the c values should work. I only see the shifts for the c's and no effect from the q's. So I guess there is something wrong in the code.

You have to think in assembler.
It is essentially the "Bresenham" code but 3rd order interleaved.

with the 8.14 code I have to shift all fractional values by 2 bits left (ValFrac4 = ValFrac * 4)
So I get an overflow into the C bit of the Status register when 65536 or above is reached.
The inline code shifts this Carry-Bit directly into the Bit 0 of the C0, C1 or C2 variable.
All other bits are shifted left (so I avoid the assignments from c[2] = c[1] ...)
In the disassembler the ROL command is translated as ADC Rx,Rx (which is the equivalent).

I have tested both codes in simulator in parallel and have compared the output values over
a simulation time of > 70 seconds real time. (so more than 10 cycles of the random code).
 the error counter of comparison of the two results was zero the whole time.
So dont tell me that it does not work.

With best regards

Andreas

OK I now see how it works:  It uses the carry flag from the C instruction before. This is a rather tricky way of combining C and ASM code - it works here, but depends on the code the compiler creates for the given C code. So it's slightly fragile code - though I won't expect a different compiler version to create much different code. But better not try -O3 here.

[branadic]

Andreas,

I've a different value for C6 in your LTSpice, which I changed to 100nF also on my board. I made a comparison with and without R15 tap on my spice model of the circuit. Attached is the circuit for cross checking. You can see that with R15 tap (vout2) there is no oscillation, while without R15 tap (vout1) it's clearly visible.

-branadic-

[Kleinstein]

The extra oscillation (which should better be called ripple) is likely due to charge injection from the CMOS switch. It presents quite some load and even with the capacitors to ground (C4 / C11) can cause the extra ripple. So the original circuit (vout1) shows more (especially high frequency) ripple. However the modified circuit should show extra nonlinearity (or better a more complicated function).

If one is after lower ripple, one could consider having the first filter cap (C10/ C3)  no towards the OPs output but to ground. At least in the simulation of the filter it showed better suppression of higher frequency ripple, where the OPs output impedance is not very low. How large the effect in real life is can depend on the OP model and layout.

[Andreas]

The extra oscillation (which should better be called ripple) is likely due to charge injection from the CMOS switch.

Charge injection is not modeled in the normal switch model.
And practically parasytic capacitances + charge injection are less than 10% in real world.
Most of the ripple in the output (without R15 tap) is from the voltage divider built from the
100R and the 100K resistor working against the 3V (charging + discharging)
of the feedback capacitor (C3).

So one measure to try (without R15 tap) would be reducing the 100R to 10-22R if the OP-Amp allows this (stability).
Usually the LTC2057 is stable with 22R and capacitive loads.

If one is after lower ripple, one could consider having the first filter cap (C10/ C3)  no towards the OPs output but to ground.

In my closed loop simulation C3 against ground showed no effect.

I've a different value for C6 in your LTSpice, which I changed to 100nF also on my board.

100nF gives a improvement of around factor 10 in simulation.  (corner frequency with 100nF is 340 Hz)
(On my board I still have the 10nF as I had to fix the ground pin of the output LTC2057 somewhere).

And your simulation works with 10kHz PWM frequency and not with 2400 Hz.

The R15 tap also gives further improvement. (never saw excessive noise with R15 tap and XTAL).

with best regards

Andreas

[serg-el]

Attached is the circuit for cross checking. You can see that with R15 tap (vout2) there is no oscillation, while without R15 tap (vout1) it's clearly visible.

-branadic-

Edit.
Rise 21 nS. Fall 8.5 nS.

Edit 2
Delay

Edit 3
79 kHz
8+14 bit
source code

[iMo]

In order to run the above schematics of Andreas, you have to open the ADG413.cir, go to
.SUBCKT ADG413   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
right click on the "ADG413" and do "Create Symbol". It creates and saves the ADG413 symbol into your LTspice repo. Open the simulation again and you will see the yellow ADG413 symbol there.

[iMo]

Another simulation..

[serg-el]

Сomparison of different models, and test output.

[Andreas]

Edit 3
79 kHz
8+14 bit
source code

I am still missing your source code implementation for the 79 kHz.

I have further optimized the code now being at ~100 cycles and verification is running at the moment.

The ideas:
C0 is not needed after being output so you can save the storage to a global variable and use a local register variable.
If you calculate the results for C1 and C2 directly 2 registers are not used (and do not need to be pushed and popped)
Further optimization is possible if not using the "+" operator together with and-masks. resulting in single bit operations.

with best regards

Andreas

[branadic]

Andreas,

I performed some simulations last night for verification and could reproduce all of your results. So for a redesign of this LM399 PWM DAC reference board we can conclude:

- R15 tap modification should be implemented in the board (did that already with bodge wires)
- C6 (simulation) / C22 (board files) should be changed from 10nF to 100nF (did that already on my board long time ago)
- replace SMD crystal by HC49 as this gives more flexibility in choosing the frequency value (e.g. from 2.5MHz up to 20MHz, while 2.5MHz has the advantage to surrender 1/8 prescaler and reduce power consuption of the circuit, while PWM frequency remains the same 10kHz)
- additional 100nF MKS2 at the output of second opamp

This board design could also be used for a reference based on 2DW233 by choosing an appropiate value for R2 in the board files.

To use the main circuit idea for a 7V --> 10V boost on LTZ1000 reference there are still some improvements to make, especially if the reference is used as a portable type to get power consumption down. However, the board design will look different as in this case the board doesn't need to fit into a Hammond 1455 case.
Time to order a redesign at Elecrow?

-branadic-

[Kleinstein]

Getting the code down to well below 200 cycles for the ISR is a big step forward, as it allows to use the timer at full speed.  I see relatively little advantage in even fast code - with still about 50% of the CPU time needed It may not be worth using a sleep mode, unless really low power is aimed for.  In this case I would consider a different µC that supports 16 bit or similar PWM in hardware. One could than use something like 10 or 12 Bit HW PWM and have only some 5-10% CPU usage to allow more power savings. The Tiny13A seems to not support an external crystal - so not a good candidate.

A higher native PWM resolution might also be an advantage for a not power critical case. One could havehigher resolution,  less modulation or a lower PWM frequency without need for higher capacitance in the filter.

[Andreas]

- R15 tap modification should be implemented in the board (did that already with bodge wires)
- C6 (simulation) / C22 (board files) should be changed from 10nF to 100nF (did that already on my board long time ago)
- replace SMD crystal by HC49 as this gives more flexibility in choosing the frequency value (e.g. from 2.5MHz up to 20MHz, while 2.5MHz has the advantage to surrender 1/8 prescaler and reduce power consuption of the circuit, while PWM frequency remains the same 10kHz)
- additional 100nF MKS2 at the output of second opamp

Hello Branadic,

I see the R15 tap still as a option. The 2.4 mV (average) voltage drop on the 100R resistor is outside the regulation loop.
I would change C22 even to 1-10uF as Foil (MKS2) capacitor.
HC49: yes (since I have all usually used frequencies in HC18/HC49 in my drawer).
C25 at the output with 100nF is also ok (EMI reduction).

Other things not to forget:
C8: I want to populate 2.2uF (0805) is ok but do not forget either a 10uF Ta Size A or a 47uF 6.3 mm diameter in parallel for voltage regulator stability.
I want to increase C1-C3 to test lower PWM-frequencies. (The 100k resistors could be on the soldering side if space is a concern).
The PWM-clock from Tiny to switch should be close to a digital ground line. (or even surrounded by it).

As it is chinese new year until mid of next week I would not hurry too much with ordering.
I want to simulate the spitted 100k resistors this week end if there would be a advantage (or if we could leave it off).

with best regards

Andreas

[Andreas]

Hello,

attached the 2.45 MHz version with 9.6 kHz PWM and optimized Interrupt service routine.
I get occasionally jitter of 5-6ns on the 9.6kHz period time but seems to have no influence on the 10V output.

with best regards

Andreas

[pigrew]

Questions from an observer:

Frequency modulation is often good from an EMI standpoint for DC-DC power converters (many recent papers on random frequency variation). Also, multi-channel converters are often used.

Should these techniques be applied to a PWM-DAC? Multiple channels should get sqrt(N) extra bits of DAC resolution. The design in my head would have all channels be equal-weight, so the mismatch could be averaged out over time. I think that four-channels may be a reasonable.

But, I don't know if the frequency modulation would help or hurt the filtering. Though, it is certainly much more computationally intensive.

Also, how was the 9.6 kHz frequency obtained? Was it because the analog circuit is less ideal at higher frequencies, or due to computational concerns?

I'm tempted to put together a similar proof-of-concept circuit with 2DW232 and glow-cost eneric SMD parts, and see if I can get good performance and digital temperature correction.

Thoughts?

-Nathan

[Andreas]

But, I don't know if the frequency modulation would help or hurt the filtering. Though, it is certainly much more computationally intensive.

Also, how was the 9.6 kHz frequency obtained? Was it because the analog circuit is less ideal at higher frequencies, or due to computational concerns?

Hello Nathan,

I guess with frequency modulation (which is usually in the 1-2% range similar to the 1% frequency jitter what I had when trying the internal R/C oscillator) we get the same result as with the internal R/C-Oscillator where I had > 70uVpp noise and instable voltage readings.
So I would say it hurts.
But of cause it depends.
I personally would never use a CPU with PLL or spread spectrum in this application. (except if you can do the frequency change exactly at the full PWM period times).

The ~10 kHz PWM is a design decision from adver, see also
https://www.eevblog.com/forum/metrology/lm399-based-10-v-reference/msg1955149/#msg1955149

I personally would go lower in PWM-frequency exactly for that reason.
On the other side: with my cirquit I had the lowest T.C. with the 20 MHz XTAL (so with 9.7 kHz PWM frequency) -> strange.
As the ripple measurements / simulations have shown: with a lower PWM frequency you will have also to improve the filter cirquit.

But there are limits: the 3*100k resistors are already at a value which is above that what you would want to have at the input of a LTC2057. (max around 70K). And good quality foil capacitors are rare to get above 10uF.

So I will make next some T.C. measurements at different frequencies to see if there is a "sweet spot" together with the ADG419.
The resulting errors are the lower the lower the initial T.C. is. (Because the temperature sensor is never at the place where it should be and thus measures not the exact temperature what you would need for the compensation).

By the way: with the 2.45 MHz X-TAL I am now at 4.7 mA without sleep mode and at 4.1 mA with sleep mode.
So the analog part of the cirquit draws obviously the most current.

with best regards

Andreas

[Kleinstein]

If the 100 K resistors are a concern, one could consider making the resistors more towards the OP a little smaller (e.g. 47 k) and maybe use 2.2 µF caps. In my simulation I see no real advantage to have the middle capacitor larger (1.5 µF compared to the other 1 µF) - so 3 same size caps are likely OK. The initial 100 K resistor sets the values the R_on of the DG419 is measured when it comes to linearity - so here it's not that good to make the resistor much smaller.
For C6/C22 I would consider the same 1 µF value as for the filter, so it would already filter the 10 kHz main PWM frequency. Due to the smaller resistor it's not as effective as the cap at the main filter. It is more for some ripple that gets around the filter due to parasitic effects.

If the drop over R15 is an issue, one could still add an inductor (> 50µH as first guess) in parallel.

One might need an improved filter, if the µC clock gets to low. One could likely still use a lower PWM frequency if the µC supports higher PWM resolution. So it would than be 10 or 12 bit from the hardware PWM and less from modulation. The real difficulty for the filter should not be the PWM frequency, but the lower frequency contend due to the modulation - it's low amplitude, but can also contain rather low frequency parts.