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

0 Members and 2 Guests are viewing this topic.

Offline e61_phil

  • Frequent Contributor
  • **
  • Posts: 819
  • Country: de
Re: LM399 based 10 V reference
« Reply #825 on: January 26, 2019, 09:46:12 pm »
I like this research here very much. It shows that many things aren't that easy in pratice. Starting with the RC oscillator and internal xtal oscillator also shows a lot.

Great work! Thanks!
 
The following users thanked this post: Andreas

Online Andreas

  • Super Contributor
  • ***
  • Posts: 2452
  • Country: de
Re: LM399 based 10 V reference
« Reply #826 on: January 26, 2019, 10:17:16 pm »
Hello,

my personal goal with this cirquit is not "best oscillator performance"
I want to have a 7->10V transfer that is:
- stable over temperature (target < 0.1 ppm/K with some temperature compensation)
- power consumption less than around 5 mA
- low noise compared to a LTZ1000 (so less than 0.4 uVpp for the cirquit)

So far as I have seen the oscillator has to be short term stable (within one PWM cycle only) and that over the whole 10-40 deg C temperature range.

What I have seen now:
- A 20 MHz oscillator which is stable enough but takes ~13 mA power.
- A R/C oscillator with 1% peak/peak change of frequency which gives some 10 ppm output variation on the 10V output.
- a 5 MHz oscillator which is in my 5mA target but shows larger instabilities over temperature.

Do you know a external stable Oscillator which takes less than around 2 mA power (since the analog section alone needs 2-3 mA).

Theoretically with lower PWM frequency the analog switch should deliver a more stable ratio (over temperature) at the output.
But what I have seen is more or less contrary. So perhaps we have some compensation effect.

with best regards

Andreas


 

Offline e61_phil

  • Frequent Contributor
  • **
  • Posts: 819
  • Country: de
Re: LM399 based 10 V reference
« Reply #827 on: January 26, 2019, 10:21:36 pm »
Isn't it possible to go into a deep sleep mode during transportation and use the 20MHz oscillator only if you really need it?
 

Online Andreas

  • Super Contributor
  • ***
  • Posts: 2452
  • Country: de
Re: LM399 based 10 V reference
« Reply #828 on: January 26, 2019, 11:04:06 pm »
I like this research here very much. It shows that many things aren't that easy in pratice. Starting with the RC oscillator and internal xtal oscillator also shows a lot.

Hello,

I already knew that it would not be easy.
Making the divider digital does not mean that all problems are solved against a resistive divider.
The problems are only different.
But what I really did not expect is that the clock stability (even with crystals) is a mayor issue.
I more suspected the rise time over temperature from the switch would be the largest problem.

Perhaps I should try a different processor or a larger crystal size ...

with best regards

Andreas
 

Offline branadic

  • Super Contributor
  • ***
  • Posts: 1511
  • Country: de
Re: LM399 based 10 V reference
« Reply #829 on: January 26, 2019, 11:04:12 pm »
Andreas, let's reflect the observations:

the 20MHz Euroquartz crystal is specified

Frequency stability*
 -10° to +60°C from ±5ppm
 -20° to +70°C from ±10ppm
 -40° to +85°C from ±15ppm

Calibration Tolerance at 25ºC: ±30ppm
https://www.reichelt.de/keramik-smd-quarz-2-5x3-2x0-7mm-20-0-mhz-20-000000-mt-p101040.html

while the 4,9152MHz crystal is specified
 -10° to +60°C from ±50ppm
https://www.reichelt.de/smd-quarz-grundton-4-915200-mhz-4-9152-hc49-smd-p72506.html

So to meet your requirements you need a crystal of low frequency and good temperature stability. What do you think of using Euroquartz 6,0 MHz MQ?
https://www.reichelt.de/keramik-smd-quarz-5x7x1-2mm-6-0-mhz-6-000000-mq-p84988.html

Frequency stability
 -10° to +60°C from ±5ppm
 -20° to +70°C from ±10ppm
 -40° to +90°C from ±15ppm
 -55 to +125°C from ±20ppm

Calibration Tolerance at 25ºC: ±30ppm

This should fit your current budget as it is ~1/4 of the clock frequency for the µC but also low frequency for the pwm (~2.93 kHz).
The only trade off is, it's not the optimum frequency for communication via optocoupler and FT232RL-USB converter.

EDIT: You could also turn of 10V boost circuit during transport to save another few mili amps.

-branadic-
« Last Edit: January 26, 2019, 11:24:49 pm by branadic »
Fluke 8050A | Prema 5000 | Prema 5017 SC | Advantest R6581D | GenRad 1434-G | Datron 4000A | Tek 2465A | VNWA2.x with TCXO upgrade and access to: Keysight 3458A, Keithley 2002, Prema 5017 SC, 34401A, 34410A, Keithley 2182A, HDO6054, Keysight 53230A and other goodies at work
 

Online Andreas

  • Super Contributor
  • ***
  • Posts: 2452
  • Country: de
Re: LM399 based 10 V reference
« Reply #830 on: January 27, 2019, 08:40:15 am »
So to meet your requirements you need a crystal of low frequency and good temperature stability. What do you think of using Euroquartz 6,0 MHz MQ?

EDIT: You could also turn of 10V boost circuit during transport to save another few mili amps.

Hello,

I do not think that I have a problem with the tempco of the XTAL.
The output change is less than 1 ppm per 1% frequency change if the oscillator is stable.
https://www.eevblog.com/forum/metrology/lm399-based-10-v-reference/msg2103421/#msg2103421

It is more the short term fluctuations of the combination of XTAL and Oscillator cirquit at certain temperatures.

And up to now I also have not recognized a difference between the 20 MHz SMD ceramic XTAL and this one
https://www.reichelt.de/standardquarz-grundton-20-000000-mhz-20-0000-hc49u-s-p32853.html?
that I am using since January 11th.

There are many options. Including using a resistor divider for a raw adjustment of the output voltage.
And doing a fine trimming of output voltage and T.C. per PWM only.
This would also reduce the requirements for filtering...

I will build a 2nd sample without the processor part.
So I also can check if a different processor will do the job and/or if the one that I picked is the only one which has a problem with the oscillator.
A PIC12F1840 consumes around 2 mA @ 20 MHz according to data sheet and should be able to do a 5 kHz 8 Bit PWM.
And with some code optimization also 19 kHz. (or 10 kHz with a 10 MHz XTAL).

with best regards

Andreas
 

Online imo

  • Super Contributor
  • ***
  • Posts: 2289
  • Country: 00
Re: LM399 based 10 V reference
« Reply #831 on: January 27, 2019, 08:53:54 am »
I do not want to mess into your experiments, but my gut feeling is that this kind of pwm divider for your extreme precise low noise needs could work in following setup only:

Discrete Xtal oscillator (ie transistors) or a quality canned oscillator (low phase noise/ampl noise) powered by a low noise stable source ---> MCU or FPGA as the PWM generator -----> PWM signal buffer (ie. a single standalone CMOS gate powered by a low noise source with certain current capability) ------> RC filters -----> analog buffer.

Also mind the "jitter of the edges" is not only source of errors in your case - the overshoots/ringing of at the pwm edges may contribute to the output voltage levels (in case of certain unsymmetrical volume of charges in the pwm pulses).
« Last Edit: January 27, 2019, 08:59:39 am by imo »
 

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 6672
  • Country: de
Re: LM399 based 10 V reference
« Reply #832 on: January 27, 2019, 09:13:54 am »
I don't think the oscillator is that critical. There is some nose from clock jitter, but the large noise source should be the lm399 reference. Much of the jitter is often low frequency and thus not effecting a 10 kHz PWM very much.  One may want some shielding so that mains hum does not modulate the oscillator very much.

The idea of the PWM gain setting in not so much a bout low noise, but more about a long time stable gain. So ringing / settling of the PWM steps and charge injection would not matter that much.

A possible effect could be from supply spikes origination from the CMOS switch (DG419) effecting the oscillator. The DG419 is expected to give quite some current spikes when switching and thus need good decoupling. Still the supply ripple would be constant in first approximation.
 

Offline branadic

  • Super Contributor
  • ***
  • Posts: 1511
  • Country: de
Re: LM399 based 10 V reference
« Reply #833 on: January 27, 2019, 10:24:51 am »
Quote
It is more the short term fluctuations of the combination of XTAL and Oscillator cirquit at certain temperatures.

I don't get the reason for this short term fluctuations over temperature yet. Is it because the filter is not optimized for lower pwm frequency (2.4kHz) that comes with lower clock frequency (4.9152MHz)?
A simple test could be using the 20MHz crystal and the internal prescaler to check for that as an issue and compare 20MHz clock frequency vs. 20MHz/8 = 2.5 MHz to identify the problem.

-branadic-
Fluke 8050A | Prema 5000 | Prema 5017 SC | Advantest R6581D | GenRad 1434-G | Datron 4000A | Tek 2465A | VNWA2.x with TCXO upgrade and access to: Keysight 3458A, Keithley 2002, Prema 5017 SC, 34401A, 34410A, Keithley 2182A, HDO6054, Keysight 53230A and other goodies at work
 

Offline 2N3055

  • Super Contributor
  • ***
  • Posts: 2152
  • Country: hr
Re: LM399 based 10 V reference
« Reply #834 on: January 27, 2019, 11:59:14 am »
My 2 c...

If I'm correct, a Fast PWM mode is used, and PWM value is modulated to achieve more resolution.

Every time you change PWM register in Fast PWM mode, it will glitch. Unless you use Phase correct PWM mode on timers.

On 20 MHz clock, glitches are smaller, because of shorter time slices, but are same relative to clock...

I don't know if this is the reason but it might be worth looking into.

Regards,

Siniša
 

Offline Echo88

  • Frequent Contributor
  • **
  • Posts: 590
  • Country: de
Re: LM399 based 10 V reference
« Reply #835 on: January 27, 2019, 12:17:35 pm »
Interesting discussion!  :-+
But i dont understand the need for low current consumption, since the PWM-part isnt needed at all during transportation. Or do you aim for generally low current consumption Andreas? 
The Datron 49xx reference had a transit-mode which disabled all switching-circuits during transportation, to ensure a lasting supply during long shipping times.
 
The following users thanked this post: e61_phil

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 6672
  • Country: de
Re: LM399 based 10 V reference
« Reply #836 on: January 27, 2019, 01:23:47 pm »
Is there really an glitch every time the fast PWM setting is changed ?
According to the DS there is a glitch with a PWM setting of 0 and the other PWM values are double buffered. The double buffering suggests there should be not glitches.

The linked software seems to use a higher order sigma delta modulation, at least it is a relatively complicated calculation, and with C codes it seems to be too slow to operate the timer at full speed and thus needs the 1/8 clock speed. I have not looked in detail at the calculations needed and how fast ASM code for the type of modulation could be. One could at least save quite some time from the IRQ overhead and by keeping the data in registers - so there is a chance it might fit inside the 256 clock window. With the half speed phase correct PWM mode one might have enough time to use the full timer clock and thus 4 times the PWM frequency or at 1/4 the clock speed.

Another option to consider would be using a µC with 16 bit timer (e.g. Tiny13A,Ttiny261).  The hardware PWM could use something like 11 bit resolution so that there is enough time to do the calculations even with the timer running at full speed. This would reduce the lowest frequency component by possibly a factor of 8.

With the LM399 it would be less about transport / storage in active mode. AFAIK the LM399 shows very little hysteresis on power on/off - so one could transport and store in cold state. It is more about using the reference in a floating application.
 

Online chekhov

  • Contributor
  • Posts: 33
  • Country: by
Re: LM399 based 10 V reference
« Reply #837 on: January 27, 2019, 08:01:54 pm »
Hi,

I'm not sure how far your compiler is able to go, but I think it is possible to reduce the job of microprocessor a bit.
  • At least, instead of `% DIVISOR`, `& (DIVISOR - 1)` might be used since DIVISOR is just 2^n value. Otherwise this is going to be a very expensive operation.
  • Instead of `for (int i=0; i<3; i++) q = d;` just assign each value individually.
  • Where OCR0A is calculated, maybe try to group values you want to subtract in separate group, so that X = (a+b+c) - (d+e+f).
  • 'ValInt' might be 'unsigned char' as well If I'm not mistaken, no need to convert types back and forth.

Also, what about ARM (Cortex M0 for example) ? Personally I haven't used them before, but I believe this may be much more efficient with integer arithmetic and will definitely have several 16-bit PWM. For me these Tiny family looks attractive because they are small but easy to solder, but probably there might be a different power-effective solution.

Maybe something from my 2 cents is helpful.
 

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 6672
  • Country: de
Re: LM399 based 10 V reference
« Reply #838 on: January 28, 2019, 05:50:55 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

If the code needs 300 Cycles wit C code, chances are that ASM could bring this down to less than 250 cycles, so that it could work within the 256 cycle window for 8 Bit PWM at full clock speed. It would already fit the 512 cycle window for phase correct PWM - though it might need some extra code to update only every 2nd time. Still this would mean a higher PWM frequency and thus more effect of charge injection or similar. So a µC with HW für 16 Bit PWM would be my preferred way. Starting with 10 Bit PWM at full clock would reduce the filter requirements as the lowest frequency components would be higher by a factor of 8. There area few AVRs (e.g. Tiny13A) with 16 bit PWM even in the small 8 Pin case - possibly even pin compatible. Part of advantage of starting without a divider could be used to use a lower clock.

I don't think the LM399 needs to run 24-7 and also during transport. One might still want battery operation for having a floating reference in some cases.  With a total consumption of some 50 mA with would still be practical with rechargeable cells.
 

Online Andreas

  • Super Contributor
  • ***
  • Posts: 2452
  • Country: de
Re: LM399 based 10 V reference
« Reply #839 on: January 28, 2019, 08:10:51 pm »
Hello,

very interesting discussions.
I have obviously a hardware problem (with the stability of the oscillator) and every body is discussing about software or "better 16-32 bit processor (at best with PLL)" or making wild assumptions on transportation modes which I never intended.

I think the next step is to check the oscillator itself e.g. according to following application note:
https://www.st.com/content/ccc/resource/technical/document/application_note/c6/eb/5e/11/e3/69/43/eb/CD00221665.pdf/files/CD00221665.pdf/jcr:content/translations/en.CD00221665.pdf
(dont know if there is a better one around).

to the software:

according to data sheet there are no glitches on timer0 unit since all is double buffered and transfer to the registers is at "top" value.
And even on timer1 there would be only glitches if the update would take place "in between" the old and the new value.
Since we are doing only small changes around 70% whereas the calculation takes only 300/2048 cycles = 15% there can be no glitches anyway.

I have analyzed the software: if you are doing it right (by using the carry bit from the status register and correct alignment of the fractional part)
you can do the whole calculation within less than 100 cycles. The "C" implementation is rather long winded solely to calculate the carry bits.
I have made the check for a PIC implementation which generates exactly the same output with around 70 cycles.

with best regards

Andreas

 
The following users thanked this post: 2N3055

Online imo

  • Super Contributor
  • ***
  • Posts: 2289
  • Country: 00
Re: LM399 based 10 V reference
« Reply #840 on: January 28, 2019, 08:36:05 pm »
Also, what about ARM (Cortex M0 for example) ? Personally I haven't used them before, but I believe this may be much more efficient with integer arithmetic and will definitely have several 16-bit PWM.
FYI - these are the 16bit HW PWM module capabilities with STM32F103 @72MHz clock (PLL). That PWM performance is typical for all 16bit HW PWM you may find in those 32bitters.
Not all PWM freqs listed.

For example: 5000Hz PWM freq ---> 14400 max duty  (~13.5bits)

PS:  Try to avoid MCU PLL in your app.
« Last Edit: January 28, 2019, 09:03:44 pm by imo »
 

Online chekhov

  • Contributor
  • Posts: 33
  • Country: by
Re: LM399 based 10 V reference
« Reply #841 on: January 28, 2019, 08:38:52 pm »
I have obviously a hardware problem (with the stability of the oscillator) and every body is discussing about software or "better 16-32 bit processor (at best with PLL)" or making wild assumptions on transportation modes which I never intended.

Hello,

Sorry for that, my point was to reduce MCU load and as result try to minimize power consumption. Also, in this case external oscillator might be used (with divider if possible), providing better frequency stability rather then internal one,  :blah:
 

Online Andreas

  • Super Contributor
  • ***
  • Posts: 2452
  • Country: de
Re: LM399 based 10 V reference
« Reply #842 on: January 28, 2019, 09:45:16 pm »
Hello,

no need to apologize. Only wanted to say that software optimizations will come later...

a collegue at work told me that I also should keep an eye on the processor supply.
So I will try to improve the ripple by larger capacitors.

with best regards

Andreas
 

Online Andreas

  • Super Contributor
  • ***
  • Posts: 2452
  • Country: de
Re: LM399 based 10 V reference
« Reply #843 on: January 30, 2019, 08:47:51 pm »
Hello,

tried to improve VCC ripple on 5V supply of the processor on branadics 7->10V transfer board.
All measurements done with 4.9152 MHz Xtal.
The active phase and the sleep phase during PWM period time are clearly visible.
Measurements are done on the programming connector Pin 1+Pin 6.
(so the filter cap is on one side and the connector on the other side of the processor.)

Initially I used 100nF X7R + 4,7uF Tantal  -> 4.16mV RMS ripple
I stacked 2,2uF X7R over the 100nF -> 100nF + 2,2uF + 4.7uF -> 3.65mV RMS ripple
Checked 47uF Aluminium electrolytic instead of Tantal ->  3.7 mV RMS ripple
and finally 10uF Tantal -> 100nF + 2,2uF + 10uF -> 3.58 mV RMS

Not too much improvement but it shows that the 100nF+4,7uF is too small for a effective filtering of the ATTINY85.

I think its time to do some stability measurements with the new filter caps.

with best regards

Andreas
 

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 6672
  • Country: de
Re: LM399 based 10 V reference
« Reply #844 on: January 30, 2019, 09:02:44 pm »
If there is a slightly improved software used to get the ISR to less than 250 cycles, one could use a divider of 1 at the timer and a lower CPU clock (e.g. 4 MHz instead of 20 MHz, and maybe a divider at the oscillator - not sure the tiny85 supports this) . In this case there would be not much time left for the sleep mode and one might just skip it to avoid the power supply problems. So a improved software could be an alternative to more supply filtering.
 

Online chekhov

  • Contributor
  • Posts: 33
  • Country: by
Re: LM399 based 10 V reference
« Reply #845 on: January 30, 2019, 09:06:23 pm »
But what is the real problem with this ripple ?
Does it just influence other circuitry and adds noise through opamps even having second LT1763 ?
Or because of that frequency changes somehow ?
 

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 6672
  • Country: de
Re: LM399 based 10 V reference
« Reply #846 on: January 30, 2019, 09:18:40 pm »
With the RC oscillator the supply ripple can effect the frequency and this way add to nonlinearity and drift (as the effect can depend on temperature too). To a smaller extend this also applies to a crystal oscillator.

The ripple could also indirectly cause some charge injection.
 

Online chekhov

  • Contributor
  • Posts: 33
  • Country: by
Re: LM399 based 10 V reference
« Reply #847 on: January 30, 2019, 09:22:51 pm »
Thanks,
I was more interested in influence on crystal-based solution.
I wonder will that end up with opto-coupling of switch input from MCU and powering it from different source (separate 3.7V cell ?).
 

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 6672
  • Country: de
Re: LM399 based 10 V reference
« Reply #848 on: January 30, 2019, 09:34:25 pm »
An opto-coupler would add extra delays (especially different turn on / of delays). So I don't think this would be a good idea. To get an accurate PWM across it would be  raw PWM plus an extra clock for synchronization.

The crystal based solution should not be that sensitive to supply ripply. If power is not critical not using a sleep mode and thus a near constant current consumption would be an option.
« Last Edit: February 01, 2019, 09:39:36 am by Kleinstein »
 

Online chekhov

  • Contributor
  • Posts: 33
  • Country: by
Re: LM399 based 10 V reference
« Reply #849 on: February 01, 2019, 09:27:51 am »
I think its time to do some stability measurements with the new filter caps.

with best regards

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).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf