Author Topic: LM399 based 10 V reference (Read 729394 times)

branadic · « **Reply #800 on:** January 09, 2019, 10:13:05 pm »

Hi Andreas,

thanks for your efffort. I still think power consumption can be reduced by using a lower frequency crystal such as 8MHz. The question left is, what about TC with external crystal and R15 tap as suggested by Kleinstein?

-branadic-

Andreas · « **Reply #801 on:** January 09, 2019, 10:38:03 pm »

Hello branadic,

one step after the other.
my plan is to measure first the current setup with 20 MHz and sleep mode.
2nd step is to change back to low noise R15 tap.

And finally go to lower X-TAL frequency.
My preferred frequency would be 4.9152 MHz to get to a standard baud rate from within interrupt routine.

With best regards

Andreas

Andreas · « **Reply #802 on:** January 12, 2019, 07:07:47 pm »

Hello,

some further measurements with branadics PCB:

- 09.01.2019: removed R15 tap against Measurement of 07.01.2019

(RC-oscillator 8MHz + Sleep mode active ~ 6.6 mA no R15 tap)

box-TC. 1.3 ppm/K
average linear T.C. -1.34 ppm/K
3rd order TC @ 25 deg C -1.30 ppm/K

so no significant change in T.C. against R15 tap.

- 10.01.2019 changed back to 20 MHz XTAL oscillator

(XTAL-oscillator 20MHz + Sleep mode active ~ 11.6 mA no R15 tap)

box-TC. 0.12 ppm/K
average linear T.C. -0.10 ppm/K
3rd order TC @ 25 deg C -0.09 ppm/K

so comparable against first T.C. measurement with factor 10 lower T.C.

- 11.01.2019: re-installed R15 tap

(XTAL-oscillator 20MHz + Sleep mode active ~ 11.2 mA with R15 tap)

box-TC. 0.10 ppm/K
average linear T.C. -0.07 ppm/K
3rd order TC @ 25 deg C -0.04 ppm/K

So R15 tap seems to generage a slightly lower T.C.
(But I also guess that repeatability of measurement is around +/- 0.03 ppm/K)
But T.C. over temperature looks rather non - linear.

I have made a overview table over all T.C. measurements.

next measurement will be with 4.9152 MHz XTAL which looks promising with ~4.5 mA.

with best regards

Andreas

Edit: typo on XTAL frequency

branadic · « **Reply #803 on:** January 16, 2019, 07:45:18 pm »

Thanks for the results.

Quote

next measurement will be with 4.9152 MHz XTAL which looks promising with ~4.5 mA.

So you will run the pwm at 2.4kHz (with prescaler set to /8) or will you change the prescaler to 4 or 2?

-branadic-

Andreas · « **Reply #804 on:** January 16, 2019, 08:00:12 pm »

Hello branadic,

unfortunately there is only a ratio 1:1 or 1:8 as pre-scaler for the used PWM-unit.
The interrupt routine takes around 300 clock cycles (at the 22 bit version of the SW).
(so with 1:1 the interrupt routine would calculate longer than the PWM cycle)

So the PWM-frequency has to drop to 2400 Hz.

I have some strange effects with ~5 MHz now where I do not know if I have contact problems or if the ATTINY oscillator cirquit has generally problems with lower frequencies. -> will have to repeat some tests.
Also the 8 MHz R/C oscillator shows instabilities (high T.C.) here as already shown.

Can you check wether you have the same instabilities with the R/C clock as I have here?
Could also be that I got a bad batch of ATTINies on my side.

with best regards

Andreas

Kleinstein · « **Reply #805 on:** January 16, 2019, 08:39:32 pm »

300 Clock cycles for the fractional divider sounds like quite a lot. So I assume this would be C code. If it is just die divider and not much interface via UART, one could write ASM code. For a different project I have done a fractional before - AFAIR the ISR was more like 20 cycles. So the power savings due to sleep mode could get more efficient. However it is still the oscillator running.

I don't think one would need a prescaler at the timer - this does not make much sense, it would mainly give away some resolution with no savings in current consumption.

Andreas · « **Reply #806 on:** January 16, 2019, 08:54:35 pm »

Quote from: Kleinstein on January 16, 2019, 08:39:32 pm

AFAIR the ISR was more like 20 cycles.

perhaps microseconds (at 16-20 MHz).
in C alone the saving/restoring of internal registers used by the Interrupt needs about 50 cycles.

And remember Its not only a fractional divider it is a fractional divider with dithering which takes a lot of the calculations.
(Have not analyzed yet if it could be optimized).

with best regards

Andreas

Kleinstein · « **Reply #807 on:** January 16, 2019, 09:19:54 pm »

Of cause it's not a fractional divider, but sigma delta type modulation of the PWM setting. However the code is very similar to a factional divider - about the same code length just updating different registers.

C code can be quite long because of saving the registers. This is where ASM can come handy, as one can get away without it, or at least much less savings. In ASM its about 20 cycles if I remember right. It essentially adding a 16 Bit value, and than moving one bit from the result to the PWM setting. So it's really short code and thus easy to write in ASM.

As the timer is 8 bit, it would only need some 2.5 MHz clock to get a 10 kHz PWM frequency.
The ISR would than handle something like 15 or 16 extra bits, though it might be better not to use all of them, but this would be more like choosing the suitable settings.

The ISR would be something like
ADD sum_L , increment
ADC sum_H, increment
"Bit 7 of sum_H to T" (currently don't know the command)
"T reg. to bit 0 of PWM value"
out compare1A, PWM value

RTI and go back to sleep mode in main loop

So this would be something like 6 cyles + interrupt start overhead and RTI, which should be around 10 cycles.

Using the UART could cause some minor glitches, but may be OK too.

The difficult part would be converting the incoming UART commands and such things.

Edit:
The end of the code suggestion is wrong. Right would be something like this:
mov temp, PMW_coarse
adc temp, Reg=0
out OC1A,temp

e61_phil · « **Reply #808 on:** January 17, 2019, 07:42:55 am »

I haven't in mind what is done over the UART, but if it is only setting new PWM values I wouldn't use an ISR for the PWM at all. One can save the time for pushing everything to the stack and popping it back afterwards. Just a loop which checks for a new UART byte and doing the PWM. If there are new PWM settings it shouldn't matter if the PWM glitches during the new setting.

Kleinstein · « **Reply #809 on:** January 17, 2019, 08:30:04 am »

To get the high resolution without too much amplitude at the lowest frequencies, it is not just simple PWM, but PWM modulated in a Sigma delta way. So the main PWM frequency is around 10 kHz, but some low amplitude components can extend down to 10 Hz.

The more I look at it, it might not even work so simple, starting with 8 bit PWM - so it may need more advanced software to emulate a higher PWM resolution from the start. Or one would have to start with an even higher PWM frequency.

I would normally prefer a µC that has 16 Bit (or at least 10 Bit) PWM in hardware. So it would be starting with 10 or 11 bit resolution PWM and get the finer part by modulation.

branadic · « **Reply #810 on:** January 17, 2019, 06:09:46 pm »

Quote

Can you check wether you have the same instabilities with the R/C clock as I have here?
Could also be that I got a bad batch of ATTINies on my side.

Can do that next week, the reference is currently measured with 3458A.

-branadic-

branadic · « **Reply #811 on:** January 17, 2019, 09:41:40 pm »

Since the source code is accessable via the former link we can also quote it here, so it becomes obvious what is done and the base for a discussion:

Code: [Select]

/*******************************************
Original code: adver ([url]http://radiokot.ru/forum/viewtopic.php?p=3112844#p3112844[/url])
Modified & ported to AVR Studio: Mickle T.
*******************************************
Compiler                : WinAVR
System Clock            : 16-20 MHz
Fuses					: Ceramic Resonator, NO prescaler
*******************************************/
#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>
#include <avr/eeprom.h>
//******************************************
#define BASIS 14            // 14 bits of fractional part (8+14bit total => 2.4uV resolution)
#define DIVISOR (1<<14)
#define Key_Up()   !(PINB & ~(1<<PB1))		// Is "UP" pressed?
#define Key_Down() !(PINB & ~(1<<PB2))		// Is "DOWN" pressed?
//******************************************
unsigned long Value = 2885765UL;         
// Value have a fixed point format [8.14]
// 256/Value = amplification factor of 7-10 V converter
// If LM399 output voltage = U_Zener, then 
// Value = (U_Zener/10.000 V)*256*(1<<BASIS) = (U_Zener/10.000 V)*4194304
// Value = (6,877576V  / 10V) *256 * 16384 = 2884664,4527104 = 2884664
//******************************************
// MASH internal variables
unsigned int ValInt;                        // Integer part of Value
unsigned int ValFrac;                       // Fractional part of Value
unsigned int q[3]={1,0,0}; 	                // Latch outputs 16bit
char c[3][3]={{0,0,0}, {0,0,0}, {0,0,0}};   // Carry flip flops 1bit
unsigned int d[3];                          // Adder output / latch data input 16bit
//******************************************
// Calibration factor (Value), saved in EEPROM
EEMEM unsigned long CFG_CAL_VALUE = 2885765UL;
//******************************************
void Init(void) 
{
    DDRB |= (1 << PB0);                 // PWM active
    DDRB &= ~((1<<PB1) | (1<<PB2));     // UP & DOWN key pins config
    PORTB |= (1 << PB1) | (1 << PB2);   // Pullup resistors

    ValInt = Value >> BASIS;
    ValFrac = Value % DIVISOR;
    OCR0A = ValInt-1;          			// PWM compare match register initial value
    TCCR0A = (1<<COM0A1) | (1<<COM0A0) | (0<<COM0B1) | (0<<COM0B0) | (1<<WGM01) | (1<<WGM00);       
    // Set OC0A on Compare Match, BOTTOM, Normal mode, OC0B disconnected, Fast PWM Mode (WGM = 3) 
    TCCR0B = (0<<WGM02) | (0<<CS02) | (1<<CS01) | (0<<CS00);    // Prescaler CK/8 
    TIMSK = (1 << TOIE0);  				// Enable overflow interrupt
    sei();
}
//******************************************
ISR (TIM0_OVF_vect)
{
    // Carry flip-flops
    c[1][1] = c[1][0];  c[2][2] = c[2][1]; c[2][1] = c[2][0];
    // Adders
    d[0] = (q[0]+ValFrac) % DIVISOR;
    d[1] = (q[1]+d[0]) % DIVISOR;
    d[2] = (q[2]+d[1]) % DIVISOR;
    // Carries
    c[0][0] = (q[0]+ValFrac) >> BASIS;
    c[1][0] = (q[1]+d[0]) >> BASIS;
    c[2][0] = (q[2]+d[1]) >> BASIS;
    // Latch
    for (int i=0; i<3; i++) q[i] = d[i];
    OCR0A = ValInt - 1 
            + c[0][0]
            + c[1][0] -   c[1][1]
            + c[2][0] - 2*c[2][1] +   c[2][2];
}
//******************************************
// PWM configuration update
//****************************************** 
void Update(void) 
{
    cli();
    ValInt = Value >> BASIS;
    ValFrac = Value % DIVISOR;
    OCR0A = ValInt-1;          
    sei();
}
//******************************************
// Loading the calibration factor (Value) from EEPROM
//******************************************
void ConfigLoad (void)
{
// If the both keys was pressed on the startup,
// only the failsafe initial value is loaded !!!
    if (!Key_Up() && !Key_Down()) {
      eeprom_read_block(&Value,&CFG_CAL_VALUE,4);
      _delay_ms(3000); };
}
//******************************************
// Update calibration factor in EEPROM
//******************************************
void ConfigUpdate (void)
{
    eeprom_update_block(&Value,&CFG_CAL_VALUE,4);
    _delay_ms(3000);
}
//******************************************
int main( void ) 
{
    ConfigLoad();					// If UP & DOWN keys was pressed at startup
									// then load default config 
    Init();

    while(1) {
      if (Key_Up() && Key_Down()) 	// If UP & DOWN keys was pressed
	    ConfigUpdate(); 			// then save config to EEPROM
      if (Key_Up() && !Key_Down()) {
        Value ++;
        Update(); };
      if (!Key_Up() && Key_Down()) {
        Value --;
        Update(); };
      _delay_ms(300);
    };
}

-branadic-

fmaimon · « **Reply #812 on:** January 17, 2019, 11:07:39 pm »

Branadic,
Why not use something simpler like the ones below? It's much faster!

Sample code for ISR
https://www.eevblog.com/forum/projects/general-purpose-power-supply-design-7488/msg105509/#msg105509
Full code, including crude uart
https://www.eevblog.com/forum/projects/general-purpose-power-supply-design-7488/msg125081/#msg125081

Assembler optimized ISR https://www.eevblog.com/forum/projects/general-purpose-power-supply-design-7488/msg125776/#msg125776

iMo · « **Reply #813 on:** January 19, 2019, 03:41:00 pm »

An MCU is a generator of a broadband noise (almost continual spectra from mHz to hundreds MHz). For a cleaner PWM output I would recommend to use a buffer, ie those 5pin smd cmos gates, powered by a clean stable source.
For example: http://www.ti.com/product/sn74ahc1g08

Andreas · « **Reply #814 on:** January 20, 2019, 03:56:17 pm »

Hello,

some measurement results.
I think we have first to understand what is happening before we do changes to software/hardware.

The instabilities on 8 MHz R/C clock come together with a very high noise level on the 10V output.
My ADC25 measures around 80-90uVpp in the original cirquit and around 40uVpp with the R15 tap which filters away some noise.
You have to be aware that the 160 ms conversion time of my ADCs have 80 ms for self adjustment and 4*20 ms settling time for the 4rth order SD-Filter.
So effective it corresponds to a around 1 NPLC measurement on a normal instrument.

In the 20 MHz crystal oscillator measurements I did not find any excessive noise up to now. Only the normal ~10uVpp which belong to the LTC2400 of my ADCs.

with 4.9152 MHz (~5 MHz) crystals there is sometimes excessive noise. It seems to be temperature dependant. But sometimes at higher (with R15 Tap) and sometimes at lower temperatures (without R15 Tap). It is almost not visible with the R15 tap but always when the additional filtering is not active.
I also made different oscillator settings (3..8 MHz or > 8MHz) which seems to have some influence on noise and the resulting deviation/hysteresis from the LMS curve.

So I think the oscillator is critical in this application.

Another point:
Voltage across R15 is also dependant on clock (PWM) frequency. At 20 MHz we have 2.466 mV across R15 and At 4.9152 MHz it is 2.222 mV.
This gives 16.2 uV/MHz sensitivity if the (lower noise) R15 tap suggestion of Kleinstein is used.

I checked the output of the spread spectrum algorithm with a PC software:
Results are:
Repetition Period is 32768 PWM periods. (see Autocorrelation). So > 3 seconds with 10 kHz.
Nominal PWM output is exact the fractional part. (as claimed=2862050/2^22)
Noise is with gaussian distribution.
Allan deviation shows ideal stability of the nominal values.
the spread spectrum uses 8 different PWM values for the output, with the original program parameters.

with best regards

Andreas

Andreas · « **Reply #815 on:** January 21, 2019, 10:31:21 pm »

Hello,

some jitter measurements for the PWM output of the ATTINY85.
I used my scope for this since I do not have a frequency counter.

The spread spectrum of the PWM output is on the rising edge.
Unfortunately my scope does frequency measurements only on the rising edge.
But fortunately there is a math function to invert the signal.
So I did the frequency measurements on the inverted signal.

With the 20 MHz XTAL we get 0.002 Hz standard deviation.
The 8 MHz R/C oscillator shows 4.3 Hz. So that explains why I have such a instable 10V output with the R/C oscillator.
The 4.9152 MHz XTAL oscillator has 0.00044 Hz standard deviation. (so around a Factor 4 lower than the 20 MHz)
I guess that I had a temperature without excessive noise for the ~5 MHz XTAL.

When looking at the 10V output we see that there is a visible ripple on the PWM output.
(all measurements without R15 tap).

with 20 MHz around 0.25 mVpp
with 8 MHz 0.93 mVpp
and with ~5 MHz 1.7mVpp

so obviously we will have to improve the low pass filter.

with best regards

Andreas

Inverted18650 · « **Reply #816 on:** January 22, 2019, 09:05:29 am »

Quote from: Andreas on January 21, 2019, 10:31:21 pm

I used my scope for this since I do not have a frequency counter.

If you would, please Sir, allow me to send you an HP5342A, as a thank you. Please just PM me the address and I will send it out tomorrow. Please allow me to do this. It would mean a lot to me (and everyone here), because the work you do is amazing.

branadic · « **Reply #817 on:** January 22, 2019, 07:39:35 pm »

Quote

With the 20 MHz XTAL we get 0.002 Hz standard deviation.
The 8 MHz R/C oscillator shows 4.3 Hz. So that explains why I have such a instable 10V output with the R/C oscillator.
The 4.9152 MHz XTAL oscillator has 0.00044 Hz standard deviation. (so around a Factor 4 lower than the 20 MHz)
I guess that I had a temperature without excessive noise for the ~5 MHz XTAL.

So relative to their frequency the jitter is the same for both crystals (20MHz: 0.1ppb, 4.9152MHz: 0.09ppb) while the R/C oscillator shows 0.5ppm jitter.
However, I don't really get the numbers for the standard deviation, what are they related to? If they are related to the PWM frequency the question is, what is the nominal mean PWM frequency depending on the clock source?
Attached the second rising edge of the inverted PWM signal in infinity mode with the 20MHz smd crystal assembled. I can see ~400ps noise + jitter with high resolution mode activated. The resolution of the integrated frequency counter of the DSO is not good enough to make a statement concerning mean pwm frequency.

-branadic-

Andreas · « **Reply #818 on:** January 23, 2019, 10:15:42 pm »

Quote from: Inverted18650 on January 22, 2019, 09:05:29 am

because the work you do is amazing.

Thank you liking my measurements.
But as a volt nut I would rarely use such a high end counter.

Quote from: branadic on January 22, 2019, 07:39:35 pm

So relative to their frequency the jitter is the same for both crystals (20MHz: 0.1ppb, 4.9152MHz: 0.09ppb) while the R/C oscillator shows 0.5ppm jitter.

Mhm when we relate the jitter to the PWM frequency (9.7 kHz, 4kHz and 2.4 kHz) the numbers get more handy.
The standard deviation is in Hz so it is an absolute value.
for the voltage output change I would relate it to the PWM frequency.
But the jitter is also filtered like the PWM frequency so we have no direct relation to output noise.

0.4 ns / 100us (10kHz) gives around 4 ppm peak to peak jitter.
my 0.002 Hz in 10kHz standard deviation give 0.2 ppm rms jitter or with 6 sigma around 1.2ppm peak to peak jitter.
So both measurements are in the same ball park.
But I guess with a crystal oscillator we are both at the limit what can be done with a scope measurement.
(which has also a jitter, which is specced with 3 ps RMS in my case).
Would be interesting if the R/C oscillator shows a much more jitter also on your side.

with best regards

Andreas

Andreas · « **Reply #819 on:** January 23, 2019, 10:25:06 pm »

Hello,

and some further measurements on the 10V output.
This time with R15 tap according to Kleinstein.

The pwm ripple can now only be detected in the FFT.
In the time based mode the oscilloscope noise is dominant.

with best regards.

Andreas

branadic · « **Reply #820 on:** January 24, 2019, 06:22:24 pm »

Quote

Would be interesting if the R/C oscillator shows a much more jitter also on your side.

For exact comparison, how did you set the fuses for use of internal R/C oscillator?

-branadic-

nsrmagazin · « **Reply #821 on:** January 24, 2019, 06:25:51 pm »

You don't need 0.01% resistors, you can achieve the same with 1%.

Andreas · « **Reply #822 on:** January 25, 2019, 06:54:28 am »

Quote from: branadic on January 24, 2019, 06:22:24 pm

For exact comparison, how did you set the fuses for use of internal R/C oscillator?

Attached:
Fuses settings (on RC I use minimum startup times but it should not make any difference)
with XTAL I use maximum startup times to let the crystal stabilize on power on.

my current software with sleep mode active and Keys deactivated.

Persistance measurement on my side to be comparable with your measurements with R/C 8 Mhz oscillator.
I used indefinite persistance in this shot to get maximum width because with 5 sec persistance you get only about the half value where the center travels from left to right and back. (drunken walk).

with best regards

Andreas

branadic · « **Reply #823 on:** January 25, 2019, 07:35:52 pm »

Hi Andreas,

thanks for your input. I tested jitter with your program with 20MHz crystal and internal 8MHz R/C oscillator. Even though I can't reproduce your exact numbers they seem to be in the same ball park.
In my measurements including the one above I used infinity persistance.

-branadic-

iMo · « **Reply #824 on:** January 26, 2019, 08:56:26 pm »

In case you are chasing the best clock performance forget the xtal oscillator with the MCU. You have to use an external one, the best performance comes usually from a discrete solution. Ask RF people.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: LM399 based 10 V reference (Read 729394 times)

Share me