DIY high resolution multi-slope converter

[ali_asadzadeh]

increasing the time resolution does only help if the clock stability is maintained.
Usually those parts have PLLs which are much less stable than a XTAL clock or Oscillator.

As I have seen with my 10V LM399 experiments the clock stability
has a large influence on stability of the analog part.

Si5340 From can be used as a very low jitter clock gen to feed MCU timer/counter external pin, maybe with this baby we could solve it too

[Kleinstein]

Even with only a little help (e.g. using some 8 bits) from the µC internal ADC the numerical resolution is sufficient at 20 ms integration. The slight point to improve may be the speed of the ADC: the AVR needs some 10 µs for sampling and this time could be reduces a little for the rundown phase. Having the full conversion ready helps with the latency and data format. A faster µC may make a small difference in the maximum speed.  I expect the quantization noise to become only below some 1 ms integration time. There a little more resolution from the ADC may help a little. Because of mains hum it would be rare to need more than 22 Bits at 1 kSPS.

I even consider to extend it intentionally to some 200 µs, so that for averaging over 100 conversions one would get one extra power line cycle. This should give an slight extra boost to the 50 / 100 Hz hum suppression. To get a stable clock I decided not to use a PLL for the clock and thus no perfect synchronization with the mains frequency. With a slightly variable mains frequency there is possibly a small part of the mains period missing or too much and thus non perfect suppression. With 100 conversions spaced by some 200 µs extra shift one would have these short extra times quite evenly spaced over a mains phase. So those tiny bits would to a large part cancel out. So at least for the average over the right number of consecutive reading one could get an improved hum suppression (e.g. an extra 40 dB if the frequency is not off by too much).

If changing the µC it would be more because of an integrated DAC, hardware buffered UART and better EMI / clock stability. The current code is quite compact (some 2.2 KB with maybe 1.5 K actually used) , but it is still quite tricky to port to a different µC. It is ASM code with well defined run times for the critical part.  It may be simpler with something like the STM32, if the event system can take over the direct reactions or at least measurements.  There is nothing really wrong with the AVR mega48 or mega88 - the IDE has a really nice simulator, that really helps with time critical code. Clock wise I am more considering to go from 16 MHz to maybe 8 MHz to reduce the power consumption and maybe EMI issues.

[magic]

In the last few years Microchip introduced new "1-series" and "0-series" AVRs such as ATtiny1614 and friends and some ATmegas.

They have the same 8 bit CPU architecture (some instruction timings are different), new but more generous and logically organized peripherals, faster ADCs, 8 bit DACs, synchronous/asynchronous event system and a small bit of asynchronous programmable logic. No buffered UART, I'm afraid.

The parts are programmed and debugged using 1-pin interface based on half-duplex UART, use less power and are 5V capable.

I haven't used them yet although I have a few in my parts stash. Are they worth it for you,

[dietert1]

To work in assembler with timing by cycle counting may be some thrill, but not very productive.

Let me mention the MSP430. In 2004 we selected it for a mixed signal application (pulse oximetry) and it became a big success. The oximetry application is somewhat "high end", where you need to measure a modulation of 0.1 % with 1 % accuracy (100 dB noise free). Not easy on a small OEM board. The MSP430 has a 16-bit single cycle CPU without cache. Its complex timer peripherals made it possible to implement everything by interrupts. For example it can play a waveform on the DAC using DMA. The main loop is "sleep" and it sleeps a lot. We are using its 12 Bit on chip ADC and one of its 12 Bit on chip DACs, at 6 MHz. MSP430 is not 5 V compatible, but low power and very quiet. It includes a "marginal flash read" method to detect pending flash failure, so you can refresh the flash before it fails, and it will live forever.

Two or three years after introduction of the product we separated system from application code and even 16 years after introduction the firmware is still flexible with normal effort. Sometimes after firmware work we have to verify interrupt latencies, but we can do that with a scope - no more cycle counting.

Regards, Dieter

[coppice]

To work in assembler with timing by cycle counting may be some thrill, but not very productive.

If you are inspecting code in great detail to ensure it will unconditionally meet a deadline, allowing for all the caching, and collision resolutions, you may well be doing something productive. If you are trying to get the code to unconditionally make an event happen on an exact machine cycle, you really should look at getting the peripherals to do that timing instead.

[Kleinstein]

I know that cycle counting is not very effective and can be quite time consuming for programming. So the programming was relatively slow, but that part is done for the AVR code. For the AVR, there is no caching or wait states that complicate the timing, so it is doable and the simulator in the IDE is really great support for this. The part that may be additional needed for faster conversions or controlling a DMM front-end is to a large part not so time critical. There are windows for some 50 µs or so (most of a µC internal ADC conversion) where the code does not have to be cycle accurate. The still open parts are also the more simple code, like check for command and if found do something simple.

If the hardware provides enough support on a more powerful µC one could use the hardware for the critical parts. In a simple version, just have input capture channels to measure the control outputs. The actual control does not have to be absolutely the same - the main part is that the actual times are measured accurately. There can still be minor effects if the timing varies: very short (e.g. < 1 µs) pulses  can behave a little different from the simple theory as the integrator may not be fully settled. So a fixed length there is desirable.
Using the periphery function to do the critical job can also be quite tricky. Chances are one could get away with PWM control for the run-up part (so the short pulses are well defined). The rundown has variable length parts anyway and simple software control and only HW measurement should be good enough. There can be ways to us the comparator to automatically stop a PWM signal - this is kind of advanced use of the periphery functions which can be just as tricky as ASM programming. One may still be fixed to a certain µC, as the periphery functions can vary. 

Chances are good many different  µCs could be used, with little difference in the result. I selected the AVR, because it is the µC I know best. Someone who knows the MSP430 well could probably get a similar solution with that µC too. On more advanced µCs the cycle accurate run time may not be a practical option. For the AVR hardware I found no way that hardware could directly control the run-down.

Only running at 3.3 V would not be a problem - there is a LVT4053 variant of the switch to work with 3 V control signals. A separate regulator for the switch chip may not be so bad - the HP34401 uses this. The measured effect of supply voltage variations is not so bad, so I think I can get away without it.

[dietert1]

That's what i meant. If you run code only in interrupt handlers, it can't do cycle precise input/output and that needs to be done by hardware instead. Our MSP430s work like this. For example the hardware will sample waveforms on various ADC inputs and save them to RAM without CPU action. If you want to sample at irregular intervals, you change the timer interval in an interrupt procedure. Can do that once every 10 usec. Wakeup from sleep mode is about 5 usec.

Regards, Dieter

PS: The MSP430 is quiet due to it's simplicity and the low power process. A working solution starts at about 1 mA. That would include a UART running at 57.6 KBd, voltage reference on, ADC sampling continuously and DAC output, plus some CPU activity.

[ogden]

Our MSP430s work like this. For example the hardware will sample waveforms on various ADC inputs and save them to RAM without CPU action.

Most ARM MCUs are doing ADC /w DMA ouf of the box today. Usually for lower price compared to msp430.

[dietert1]

Meanwhile we also have an implementation of our OEM module based on Arm technology.
For somebody coming from AVR an Arm SOC may be a tremendous hurdle, though. I think a typical STM32 datasheet is ten times the size of a MSP430 datasheet. That's why i wanted to mention MSP430 - still a nice product. Its existence has been the foundation of 16 years of production with very little rework. The only major step was the introduction of the extended architecture with 20 bit address registers.
After a module shrink with BGA / LLC two years ago i hope it will sell another 10 years or so. With respect to product life cycle the market for clinical medical equipment is very special.

Regards, Dieter

[ogden]

I think a typical STM32 datasheet is ten times the size of a MSP430 datasheet.

Complex does not necessarily mean "inferior". Usually it is "more capable".

That's why i wanted to mention MSP430 - still a nice product.

Well, yes. Nice, old 16bit MCU indeed. I has had many excellent engineering "features" like constant register to mention just one. Unfortunately low power, low cost ARM happened

[dietert1]

Can't understand your comments in this context. Using MSP430 may be a path for Kleinstein, who is currently stuck with AVR, while using Arm technology may be unrealistic for him. Of course it's up to him.

Regards, Dieter

[ogden]

Can't understand your comments in this context.

I do not understand what you do not understand. You think all ARM MCU's have complex peripherals as stm32 of your choice? - You are mistaken. There's MSP432 - ARM MCU with peripherals of msp430 and documentation of comparable size/weigth.

Using MSP430 may be a path for Kleinstein, who is currently stuck with AVR, while using Arm technology may be unrealistic for him. Of course it's up to him.

Exactly. You will not be one deciding which MCU is too complex for Kleinstein and which is not.

[Kleinstein]

I am not really stuck with the AVR - it is working. I doubt the INL comes from the µC type - more like a layout question and maybe the clock.

I am thinking to make the ADC work together with the BB3 unit and this would prefer to have an SPI slave interface. Here the AVR can be rather tricky and an STM32 µC would be the obvious choice, as other cards use it.  I already did the step of reading the relevant part of the rather long data-sheet and find a way to couple the timers in a way to do most of the control in hardware.  Chances are good it would work as planed.  The main difference to the outside is an SPI (slave) interface instead of UART.

I want to learn about the STM32 anyway - I even already have a cheap Nucleo board there. The question is a little wether to test the ADC first, or get a board ready before the Chinese new year. with a slight chance that  the SW will not work as planed.

The way I plan to to make the comparator control the PWM outputs synchronously it to link the comparator to an output_compare_CLR signal and than use the output_compare signal internally to trigger another timer that actually does the output and have a 3rd timer use input capture to measure the time when the 2nd timer changes. It still need the program to set up the next step. So the control may add short stop phases and take a few µs longer than the pure software solution with the AVR. The few µs lost would not really matter as the ADC is a little faster and can make up for it. 

More complex periphery makes the change a little slow, but much of the complex part can be just ignored if not used.

[dietert1]

Can't understand your comments in this context.

I do not understand what you do not understand. You think all ARM MCU's have complex peripherals as stm32 of your choice? - You are mistaken. There's MSP432 - ARM MCU with peripherals of msp430 and documentation of comparable size/weigth.

Using MSP430 may be a path for Kleinstein, who is currently stuck with AVR, while using Arm technology may be unrealistic for him. Of course it's up to him.

Exactly. You will not be one deciding which MCU is too complex for Kleinstein and which is not.

Wish you a happy new year and please calm down a little. You can't contribute anything useful in that mood.

Regards, Dieter

[Kleinstein]

My quick INL ist to compare 2 run-up variants, that differ in the exsact timing delays. This should ideally give the same result, but some of the more lokal linearity errors will show up as a difference. It is not a full INL test, but needs littel hardware and can be very sensitive and relatively fast.  The tests do still show an error of a few µV - so something to improve about.

I was trying to find the reason behind the errors by appliing small changes to the circuit (e.g. extra decoupling cap, extra resistors, ...). For a long time the changes had no effect and the curve is hardly changing at all (it changes with a different runup timing of cause, but not that a reasonable slow mode would be perfect). Finally I found a change that does make a difference  -  adding 68 Ohms in the clock line to the µC, but sending the clock from the oscillator still directly to the flipflops for synchronization.  It did not improve things but makes things worse - but at least some change  .  The curce show the difference before the change at the bottom and two runs with the resistor (the blue one with an additional ground link). Much of the differnce betwenn the upper 2 curves may be a thermal effect - there is a little drift in this type of measurements.   

So it looks like the clock part is somehow responsible for the stabbrun errors.

Now comes the question: how to improve one the clock circuit. I have a old style DIP14 size) canned oscillator with a local 100 nF cap and 39 ohms + a ferrite bead isolation from the 5 V supply.  Adding an extra electrolytic cap to the oscillator supply did not change anything. The clock goes to the µC with short (~10 mm trace) and some 30 mm bodge wire to 2  74HC74 Flipflops. Does one need an extra buffer or added load capacitance ? 
For the next PCB version the oscillator would likely be 3.3 V and smaller and closer to the flipflops and maybe a little longer to the µC.

[ogden]

I am not really stuck with the AVR - it is working. I doubt the INL comes from the µC type - more like a layout question and maybe the clock.

INL could come from software-induced jitter. I am not familiar with what and how you are doing things on AVR, but to say obvious - running timing-critical stuff in software is challenging. I would suggest to add some GPIO "logical debug trace" outputs to look at the timing of ADC code using multichannel scope, see if there is any unwanted jitter.

I want to learn about the STM32 anyway - I even already have a cheap Nucleo board there. The question is a little wether to test the ADC first, or get a board ready before the Chinese new year. with a slight chance that  the SW will not work as planed.

I would suggest to test everyting about timer setup and routing first, only then route board. You can easily run into need to change timer/event routing from inernal to external - using connections between MCU pins, thus need PCB redesing. Stm32 is fine choice BTW mainly because it is diy & maker-popular. Never ever consider MSP432 I mentioned as an "easy peripherals" argument. It was dead before release.

[Kleinstein]

I am not really stuck with the AVR - it is working. I doubt the INL comes from the µC type - more like a layout question and maybe the clock.

INL could come from software-induced jitter. I am not familiar with what and how you are doing things on AVR, but to say obvious - running timing-critical stuff in software is challenging. I would suggest to add some GPIO "logical debug trace" outputs to look at the timing of ADC code using multichannel scope, see if there is any unwanted jitter.

The jitter type error is way smaller than a clock cycle. 1 cycle wrong would result in some 50-100 µV error. That would be very visible.  The simulator is really nice to check the run time in the code.
It takes some time, but one gets used to program with a fixed time. The skip instructions are very handy here. 
 
The problem is more subtile - I have seen the running ADC clock (something like CPU clock / 256) to have an effect on jitter, though the effect only gets visible when repeatedly getting in coincidence with reference switching. To reduce the chance for repeated conincidence the loop leght is chosen to be an not so simple number like 102 or 174 cycles, especially not a multiple of 16 and 13.  The external flipflops solved this problem. The current problem is something like a one time 1 ns shift, possible split over some 100 transitons, or some 1 ppm range modulation of the frequency.

[Andreas]

The problem is more subtile

Just a (silly) idea: perhaps you should introduce "symmetrically" switching on the port pins.
So when one pin does a rising edge another compensates this by creating a falling edge (on the same port of the controller).

with best regards

Andreas

[Kleinstein]

The problem is more subtile

Just a (silly) idea: perhaps you should introduce "symmetrically" switching on the port pins.
So when one pin does a rising edge another compensates this by creating a falling edge (on the same port of the controller).

with best regards

Andreas

For most of the part (the run-up phase and the fast part of the run-down) the switching is already this way. Both the positive and negative reference are switched active with a positive signal and during run-up it is always either positive or negative. The 3 control bits are on the same port and written together.

1 of the 2 boards has extra flipflops - so the exact timing at the µC does not matter, it is synchronized externally. It is only one stage flipflop, but the setup time looks good: the µC port changes about 3/4 of the clock period before the flipflop switches. So some 45 ns setup time and 15 ns hold time after the edge. So the exact timing at the µC does not matter any more. The flip-flop is bodged on dead bug - so maybe not the best wiring there.

[ogden]

The jitter type error is way smaller than a clock cycle. 1 cycle wrong would result in some 50-100 µV error. That would be very visible.

Oh, I see. Then back to your 68 Ohms experiment. - You shall check output waveform of "canned" oscillator you use. It could be source of jitter if clipped sine or just slow dv/dt.

[Kleinstein]

On my scope the output from the oscillator looks OK - however not much difference to expect with a 16 MHz clock and 20 MHz scope  .

I agree that the waveform and slope can make a difference. I still wonder how much buffer is inside the cans. If it is just an inverter and crystal, the output may also reactor to capacitive loading.  So maybe I'll try some kind of buffer for the reference - probably 74HC14 now, and some  ..AC14 or similar for the PCB later.

[Rerouter]

It kind of sounds like AC coupling / EMI to me, the resistor would increase how much signal can get picked up by the really sensitive integrator inputs,

I'll clean up my layout to support the current public KiCad release, as prasimix was interested, If you could note any significant changes you have made to the design since, I'll update it.

[jbb]

Probably not it, but I wonder if there might be problems with setup/hold times on the flip flops. If the uC output toggles too close to the clock edge the flip-flop may do odd stuff

[ali_asadzadeh]

IF you put the project in Github, I can help you with the PCB design in Altium

[RoGeorge]

Now comes the question: how to improve one the clock circuit. I have a old style DIP14 size) canned oscillator with a local 100 nF cap and 39 ohms + a ferrite bead isolation from the 5 V supply.  Adding an extra electrolytic cap to the oscillator supply did not change anything. The clock goes to the µC with short (~10 mm trace) and some 30 mm bodge wire to 2  74HC74 Flipflops. Does one need an extra buffer or added load capacitance ? 
For the next PCB version the oscillator would likely be 3.3 V and smaller and closer to the flipflops and maybe a little longer to the µC.

When I was learning about about how the phase noise, in time, adds up as a bigger and bigger time jitter, I also compared a few oscillators I had around.  You can estimate the phase noise of the oscillator by looking at the time jitter with an oscilloscope (observe the edge position of the studied clock many, many periods later after the trigger event - I was looking 1..10 seconds later after triggering).

The best in terms of phase noise (so smallest time jitter) of all I had on hand was the Rigol DG4102 DDS/Generator, followed by the internal Quartz+PLL of the DS1054Z (oscilloscope).  Then, it was a SMD canned oscillator from a very old GSM mobile phone, and on the last place out of all Quartz based oscillator were some old canned oscillators from the TTL era (the ones in a 4 pins metal can, about the size of a 14 pins DIL).

Another thing about oscillators, I was "calibrating" an PlutoSDR by generating a 39 MHz square wave with the DDS generator, and looking at the 25th harmonic received with the SDR radio, a waterflow chart centered on 975 MHz.  The SMD canned oscillator from the PlutoSDR was so sensitive that the 975 MHz line was visibly wiggling by simply waving my hand about 30 cm nearby the SDR.  When blowing air on the ascillator, the 975 MHz line was going crazy.

Same with some nRF24L01+ unshielded 2.4GHz modules, a wave of hand nearby the module will show a frequency wiggle in the signal waterfall view.

My point is:
- all Quartz oscillators (including the canned ones) are sensitive to the surroundings.  Always shield them against external fields and against surrounding (variable) capacitive couplings.
- the few square wave canned oscillators I tested from the TTL era were performing the worst in terms of jitter, when compared with more recent SMD canned oscillators, or with good (specified phase noise) canned Quartz oscillators.
- good frequency stability does not necessarily imply good phase noise performance (and thus low time jitter).

Search for low phase noise (or low jitter) Quartz oscillator part models.  They are more expensive than normal ones.

Look in the datasheet for the phase noise of the Quartz canned oscillator you want to use.  The low jitter ones _must_ have the phase noise specified in the datasheet.  If it has no phase noise (or time jitter) guaranteed by the datasheet, then it be very bad at it.