Open Source Multimeter

[mrflibble]

Why do you need a FPGA?

Because it's cool?

And more seriously ... It's Stoney's design, and I was remarking on the choice of fpga in there. He wants to use the fpga to process the comparator output of the dual slope ADC as per the block diagram. All I'm saying is that I'm glad he uses spartan-6, because I am familiar with that and those are affordable in single units and you can get them in hobby friendly packages.

And as for branadic's ADC list, yeah those are some nice ones. In fact, the ADS1256 is a better choice for this sort of thing than my suggestion of ADS1258. Whatever ADC you might want to use ... just use one that for which an affordable (~ $50) dev board exists. That lowers the bar for people to join in.

[crispus]

I quoted you because only you used the word 'FPGA' in topic

For me, it seems to be too complicated, at least for a hobby project. I will follow this, and maybe I'll took only the blocks I'm interested in.

I'm a software guy. If is anything I can help, I'll be glad to.

[mrflibble]

For me, it seems to be too complicated, at least for a hobby project. I will follow this, and maybe I'll took only the blocks I'm interested in.

Well, for the chosen architecture I can see why Stoney put the fpga in there. It's a cost effective way to get good timing resolution for your dual-slope adc. With as added bonus that when the hard work is done, and you decide you want more channels, that is reasonably straight forward.

That said, personally when I would do this I think I would go for using a ready made 24-bit ADC dev board and integrate that into the design for iteration numero uno. That get's you going faster. But, it's not my design, it's Stoney's design. And use of dual slope adc is perfectly reasonable, so if that has his interest (and as such will get built) then I'm all for it.

I'm a software guy. If is anything I can help, I'll be glad to.

Well, a good working (stm32f4) port of an scpi parser would be damn handy IMO. Both for this project and for the other OSHW thread going on. It's not as sexy as a pretty gui, but pretty gui's are a dime a dozen. A good scpi parser running on mcu is something that can really make the difference in usability IMO. As in, being able to script your measurements is damn handy!

I love being able to set up my scope over gpib, and would love to setup a DIY bench DMM with a few commands and then receive measurement results. To me for a DMM that is worth a lot more than some gui with pretty pixels.

[Stoney]

@flibble: Nice, I've never looked at verilog...but maybe it's time to learn something new It would be nice if we could fit the design in an LX9, so we don't need that nasty BGA-Chip on the board... For the PSU: Jap, I intended to make it external...it just doesn't make sense to put it directly onto the AFE if the design should be modular. Also, it would increase the PCB size significantly, so it's kind of a no-brainer. I already have some nice and tiny switching psu building blocks in altium from my previous designs, but I'll use linear regulators for the AFE (with beefy filtering) of course! In terms of Software & Ethernet: 100MBit is the way to go here, so we get decent speed....I'm not sure if we should use 1588 here, but it would make the thing more compatible to LXI, if someone is willing to implement such a large interface (I'm not  ).

@Delta-Sigma ADC:
Puhh, long story short: I won't use one.
After couple of hours diggin through lots and lots of datasheets from linear and analog, i found the resolution is just not enough. Most of them offer only 21.5 to 22 noise free bits in its best configuration. In addition, running on 7-15SPS is a bit low... To really achieve the full resolution of those devices, one needs a ultra low noise buffer in front of it, with variable gain (x10 for the smallest range). Designing a x10 buffer amp with noise <50nV over a decent temp-range with low drift is a very difficult task, if not impossible in some regards (its really always a trade off, one design is a bit noisier, but with better tempco, etc. etc. ). With an integrating ADC, noise isn't that much of a problem (well, of course you want to minimize it, but it's not that critical for 6 1/2, for 7-8 digits it certainly becomes deadly  ) if it is properly designed. We'll see how it turns out.

I haven't had much time this weekend, but I'll try and start with the detailed blocks for each module the next days. After some thoughts, the biggest problem right now for me is the range switching and the input switch in front of the integrator (for the multi-slope thing). It has to be really fast (the faster, the better...less error when the Vmes is switched out and the +-Vref is switched in) and it must not inject too much charge into the integrator. As far as range-switching is concerned, I would like to use JFETs. But this would certainly require a part with a very low leakage current (very very low). Any Ideas on this one??? One other problem is the "master switching" just after the decade resistance. If one would apply 1kV and the device is in it's lowest range, the relay has to switch the full Voltage....in other words,it has to withstand the full voltage after it has been switched of (>=1kV in this case). So a JFET is not working here. Most designs use 2-3 quality relais for the inital switch and later on route the signal with JFETs.

@FPGA: The only way to get >50Mhz counter+switchting speed for the ADC is an FPGA. I can't think of another solution, and a LX9 TQFP-1000 only costs you ~$30-$40 (28€ for me). If we're able to fit the design into 9k macrocells, it's not that expensive after all, and allows for a great deal of flexibility

[mrflibble]

@FPGA: The only way to get >50Mhz counter+switchting speed for the ADC is an FPGA. I can't think of another solution, and a LX9 TQFP-1000 only costs you ~$30-$40 (28€ for me). If we're able to fit the design into 9k macrocells, it's not that expensive after all, and allows for a great deal of flexibility

Well, if all you need is say 10 ns time resolution at a relatively low repetition count then you can probably get away without an fpga. That said, you can get pretty damn good time resolution (way better than the 10 ns example) with the fpga. And as you said, you do get a lot of flexibility. As in: I can think of something that will get you 10 ns with less expensive parts, but it's not going to do much more than counting. Plus it won't get you to say 1 ns or below that.

Anyways, what kind of timing resolution + repetion count do you need for your dual slope adc?

[branadic]

Most of them offer only 21.5 to 22 noise free bits in its best configuration. In addition, running on 7-15SPS is a bit low...

You wanted to realize a DMM not a scope, right? And you have an idea about what "only 21.5 to 22 noise free bits" means? If not you better take a look at AN82 or the accuracy translator attached. I'm not sure if you realy understood the challenge of what you are going to do.

Normally those types of ADCs are ASICs and not consumer parts you can buy everywhere. Refer also to:

http://www.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=snoa597a&fileType=pdf

[Stoney]

Oh sorry, seems like I forgot a simple word in my previous posts...so far, I only wrote about resolution, not absolute/relative accuracy. One of the requirements is 2000000 counts (ops, think there is still an error in the req. doc) which will require at least 21 noise free bits of resolution. Given the fact that the delta-sigmas in the other post only offer one slightly above that, and, lets say, the buffer in front of it kills another bit of resolution, the integrating adc is the way to go.

Yap, your right, I dont want to build a scope. But 50SPS (which might be a good point to start with) isn't 2GSPS. In order to do statistical mesurements, recording, stuff like that, it's the lowest minimum i can life with (ok, 100SPS on 2000000cnts would be nice, followed by 1kSPS for 200000cnts and 10kSPS for 20000cnts).

I've built a nice CAL-System for sensors used to test the structural lifetime. These sensors are currently in use for the A400M, the A380, A320. Back then (my bachelor thesis) I used a PXI-System with a 7-1/2 digit meter which was capable of 100SPS in high-res mode together with some motion controllers, precision voltage sources and so on.... The DMM had even more SPS than the max. I wrote above in 5-1/2 digit mode. Of course, the NI gear is awesome and insanely expensive, but we really used all its capabilities, which were almost the minimum required for the task (analog position sensors, really expensive and quiet precise for their underlying principle, you need good gear for that and a nice cal lab).

If you think I'm on the wrong track, show me the right one I'm always glad to hear different opinions and other, better and easier solutions!

[mrflibble]

Oh sorry, seems like I forgot a simple word in my previous posts...so far, I only wrote about resolution, not absolute/relative accuracy. One of the requirements is 2000000 counts (ops, think there is still an error in the req. doc) which will require at least 21 noise free bits of resolution. Given the fact that the delta-sigmas in the other post only offer one slightly above that, and, lets say, the buffer in front of it kills another bit of resolution, the integrating adc is the way to go.

That right there!
For ease of discussion, assume for a moment that as you say the analog stuff in in front of the adc "kill another bit of resolution". As in there's a certain voltage noise source of whatever it is uV rms. You don't magically change the characteristics of the front end by swapping out the adc. So if that "kills 1 bit at 21-bits" voltage noise source is lets say 1 uV rms, then this very same 1 uV noise source is present even if you follow it with an awesome 32 bit adc.

So if you want to go and argue "but the stuff in front kills 1 bit" , then by the exact same argument this noise will kill a whole lot more of your 32 bit adc.

Anyways, if you know a good way to get those 2E6 counts at a reasonable cost go for it. But I still maintain that for a first iteration it makes a lot of sense to ease up on the requirements a bit. If only because that way THE REST of the system also can be built with components that are somewhat affordable.

If you think I'm on the wrong track, show me the right one I'm always glad to hear different opinions and other, better and easier solutions!

Depends on what the goal is. If the goal is a learning exercise that you and you alone are going to be doing the next year or so go for it! If you want something that is a bit more accessible to more people then you may want to ease up on the requirements. After all, if things are so super easy as maybe you hope they are ... then you will be done in no time. And hardly any effort "lost" since you made it modular, so you can upgrade parts of the design for your higher spec next iteration. That, and you can incorporate lessons learned from iteration #1.

But as said, it's your design so have at it. I'm just giving some perspective on how I'd do it.

PS: now that I mentioned it ... what is the design goal? Buildable by people of <fill in> level of skill? Build cost ..., etc... A lot of those often unwritten assumptions dictate what is reasonable and what is not...

PPS: Oh yeah, you didn't answer this one from previous post:  "Anyways, what kind of timing resolution + repetion count do you need for your dual slope adc?" The answer to that will determine the sense vs non-sense of using an fpga. Definitely since you say you are new to verilog (and presumably new to vhdl as well).

[branadic]

I've built a nice CAL-System for sensors used to test the structural lifetime...

Listen, it's not my goal to doubt your skills or stop you from what ever you want to develope and present in here, just go for it!

As an engineer I develope for example in the field of high resolution capacitive sensors together with my colleague. We're always at the limit of available circuits measuring down to Attofarad with tendency to Zeptofarad and also in here we are confronted with the same problems that occur in voltage references such as humidity in packages and pcbs, stress, temperature dependency etc. Having all that knowledge in my mind voltage references are a new challenge to me to get them under control. And the reference for sure is one of the major devices besides adc and the other stuff. You might know that every additional bit doubles the efforts. And I'm sure that the integrated gain stages in a modern 24bit ADC are much better as you would expect. The only way to reduce noise in here is to decrease bandwidth and cool down the stuff.

My suggestion is, keep the "stage win" as small as possible otherwise this project will change into some kind of pyrrhic victory.

[Stoney]

No offense taken I just wanted to make some sort of statement that I'm not one of those "hey lets build a 10kSPS 8-1/2 digit meter for $10 and make it open source" type of guys 

Well, I don't question the work of the fabulous engineers over at linear or analog, their ADCs are pretty nice. The only thing that struck me was the sampling rate...I wanted to do some sort of software-filtering after the adc to get rid of some noise and and errors and increase the resolution by some degree. I did some calculations the other day for the input buffer....and oh boy....your "decrease the bandwidth" and "double the effort for every bit" statements hold
Let's just assume for a moment, one were to consider a 24-bit ADC (linear) with a decent front end. Would it be ok, if the sample rate is "only" 7-15SPS (indeed, the bandwidth of the VDC front-end itself will be very low, otherwise its very hard to keep the noise low enough)? One could of course increase the sampling rate while lowering the resolution in "streaming mode", to offer a high sample rate, for example over the (planned) ethernet interface. In terms of the update rate of a potential display connected to the µC, I'm no longer sure if a sampling rate >10SPS is really that useful for the human eye and brain. Maybe, my requirements were/are a bit optimistic and over the top right now...and the very limited bandwidth of the input stages (to achieve a high resolution) wouldn't allow for a very high sampling rate, even if resolution is sacrificed (well, we don't want to make the damn thing too complicated and expensive, right)....
The integrating adc (in the current drawing) would allow for a great deal of flexibility, in terms of sampling rate/resolution and input ranges. If we find some nice solutions, the sampling rate would also clearly be higher....but with an input stage so limited in bandwidth,  this advantage isn't that relevant anymore, at least for the "streaming mode". Oversampling on the other hand could be of advantage here...

P.S: Jap, the reference will definitely be one of the major contributors to the actual accuracy of the frontend. Would you like to do one, as a "stand-alone" modular type? Would be really great, because my knowledge about references is very, very limited and certainly not good enough to build one

[mrflibble]

No offense taken I just wanted to make some sort of statement that I'm not one of those "hey lets build a 10kSPS 8-1/2 digit meter for $10 and make it open source" type of guys 

Hopefully you're one of those "hey lets build a 10 SPS 5-1/2 digit meter for $100+ and make it open source" type of guys. XD

Let's just assume for a moment, one were to consider a 24-bit ADC (linear) with a decent front end. Would it be ok, if the sample rate is "only" 7-15SPS (indeed, the bandwidth of the VDC front-end itself will be very low, otherwise its very hard to keep the noise low enough)?

Absolutely. If your target audience is "hobbyist that like to build some of their own test gear and are able to make reasonable tradeoffs" then I'd say a bench DMM with 5 1/2 digits that does 10 SPS would be quite nice. It would have many many uses on the bench. Sure it doesn't compete with the state of the art professional meters, but I suspect (and hope) that is not the intention.

[free_electron]

before you start arguing about what fpga to use... : go write the code for the dual slope system.
it's no much more than a few counters. you don't need a 9000 macrocell fpga. you can put it in a CPLd if you want.

the key to the slope system is the integrator / comparator. you will need to pick a REALLY good opamp and comparator. and you will need ultrastable caps and resistors around it. if you want the integrator to run fast you can get away with a small cap. try to find a silver/mica C0G/NP0 type.
use resistors with the lowest tempco you can find ( Caddock for example)

the switching balance for the current can be done using a good analog switch like a DG444, no need to muck around with jfets.
and you need an ultrastable reference.

absolute accuracy is irrelevant in this system. you don't want any drift.
i wrote multiple posts on the forum here how this system works and is implemented in HP34401 as well as how it is calibrated.
i know people that have built a 5 1/2 digit dual slope in a 64 macrocell cpld.

the number crunching is done by a cpu. yuo only need the gate array to get the runup and rundown counters since the cpu can't bitbang that fast.

[mrflibble]

Regarding the fpga my point so far has been that you probably can get away without one. If all you need is ~ 100 MHz counting frequency there's simpler ways. CPLD could be one, but since there's already a STM32F4 on the BOM you can use that. Again, it depends on the (as of yet unspecified) required timing resolution.

There, fpga relegated to being a non-issue. Onward to the analog stuff.

[mrflibble]

Also ...

i wrote multiple posts on the forum here how this system works and is implemented in HP34401 as well as how it is calibrated.

do you have a link to which one you mean? Right now I'm reading https://www.eevblog.com/forum/reviews/hp34401-teardown/ but maybe you mean another thread.

edit: probably this one. reading ...

[Marco]

Silly question ... why can't you just use dithered oversampling with a fast ADC to get high resolution? (Potentially with sine or triangle wave dither, theoretically gets resolution far faster than white noise.)

[chickenHeadKnob]

Regarding the fpga my point so far has been that you probably can get away without one. If all you need is ~ 100 MHz counting frequency there's simpler ways. CPLD could be one, but since there's already a STM32F4 on the BOM you can use that. Again, it depends on the (as of yet unspecified) required timing resolution.

There, fpga relegated to being a non-issue. Onward to the analog stuff.

May be I just don't understand but I don't think you can get 100Mhz timing resolution from STM32F4 on chip counter/timers, its more like 1 or 2 Mhz. I have been itching to find an excuse to play with those small cool-Runner PLDs. I thought of making a ballistic (bullet) chronograph but stm32 timers have enough resolution for that. Something I haven't discovered yet: what quality and stability does the dual slope clock need - Ovenised  or TCO?

[ve7xen]

May be I just don't understand but I don't think you can get 100Mhz timing resolution from STM32F4 on chip counter/timers, its more like 1 or 2 Mhz. I have been itching to find an excuse to play with those small cool-Runner PLDs. I thought of making a ballistic (bullet) chronograph but stm32 timers have enough resolution for that. Something I haven't discovered yet: what quality and stability does the dual slope clock need - Ovenised  or TCO?

They may only accept a clock input at relatively low frequency (though probably at least 10s of MHz), but for an integrating DAC you need input capture mode, where the clock for the timer can be derived from the system clock, and the capture input is asynchronous. In that modes I believe the STM32F4 series can run at around 150MHz, giving you ~7ns timing resolution.

Can't comment too certainly on the clock stability, but I'd guess you want it to be as good as the measurements you intend to make. For absolute accuracy and long-term stability you probably want at least a TCXO.

[chickenHeadKnob]

@Ve7xen and mrflibble :

My apologies    you appear to be correct, I seem  to be conflating F4 series with some other micro's spec sheet from my faulty memory. sigh -gettin old.

The advance timer at least can run at system clock rate 168Mhz. as I dimly understand it you need to drive an analog switch with hardware logic (software would be to slow) when the comparator trips, so you will still need a little off chip logic. I'll shut-up now and leave you guys to it! Still might build a basic dual slope on my own just for amusement and learn-dina'tin.

[Stoney]

@chickenHead:
Absolutely right. I first thought I could do the switching with the Capture/Compare peripherals (they are quite good actually) but it just doesn't make sense if one can buy a TQFP-FPGA for 30 bucks. No BGA (woohoo), and its not that expensive.

As far as the CPLD is concerned: No, you really dont need 9k cells for a integrating ADC But, I really want the unit to be expandable, so people can add other front-ends, for example for L, C, F, and other stuff. So it's just a nice and versatile solution

For the clock, I would use a FOX +-1,5ppm inital accuracy with +-2,5ppm drift TCO. They're cheap ($3-4), SMD, small and reliable (used them on quiet a number of boards, never head problems and well within specs).

The DG444 is cool, after i looked it up, i also found the ISL43681. Do you think it'll be possible to make the reference +-2,5V (with a precision divider + inverter, aka. LT1043) so we could use this one? It's much faster, with equally low leakage and charge injection but its a low voltage type (+-5VDC supply and therefore input range max.)....and I guess we'll have to switch reasonably fast to reduce the errors in the integrator.

But back to the input buffer stuff:
I found that the LTC6240 would be a good candidate here, because of its extremely low input bias/offset current and the even lower current noise. Because the input divider/protection devices will have a very high source impedance, the current noise (together with the high source impedance) plays a role in the noise performance. The main noise contributor is indeed the input divider and not the op-amp itself (if it has a low input referred voltage noise, of course). The LTC6240 has a great performance in terms of input current and noise but has one major disadvantage. The input offset voltage drifts around 0,6-1,0µV/°C. So one has to compensate that thing, for example by chopping, which leads to a hole other set of problems.
So, I've chosen the LTC1052. Equally low current noise, but higher input bias current (30pA, times 15) but significantly lower drift, noise, and offset (drift ~10-50nV/°C). The challenge here is to balance the junctions (the datasheet is quiet nice on this one, they write a lot about it). Since we basically only need need unity gain and a gain of x10 for the lowest input range (200mV, otherwise the integration time becomes too long for small signals, in other words, the error increases), a switch will bypass the divider and I'll choose a non-inverting configuration. In the unity gain feedback path, the switch will add the needed material junction so we always stick with the same number in each configuration. It's quiet critical to keep the temperature of all parts in the buffer equal, and it would be nice if the resistor values are close to each other on all paths, so cancellation occurs for the thermal/junction noises. Later on the PCB, I'll add the possibility to solder in a air-protection cap, just to make sure that no airflow can build up thermal gradients on the resistors and introduce offset drift. By default, the switching frequency of the 1052 is 330Hz, so a first order low-pass in front of the op amp will ensure that we're not running into aliasing for low frequencies, with a ~200Hz -3db point. Afterwards, the integrator will take care of it. I'll do some drawings tomorrow for the input switch, overrange limit and the input buffer and add them to the repo ^^ (nah, these modules are so closely connected, you really can't treat them seperatly  ).

[branadic]

P.S: Jap, the reference will definitely be one of the major contributors to the actual accuracy of the frontend. Would you like to do one, as a "stand-alone" modular type? Would be really great, because my knowledge about references is very, very limited and certainly not good enough to build one

Why not resort to something like this, the SVR-T should be a good choice at the beginning:

http://www.gellerlabs.com/Voltage%20References.htm

[ve7xen]

@chickenHead:
Absolutely right. I first thought I could do the switching with the Capture/Compare peripherals (they are quite good actually) but it just doesn't make sense if one can buy a TQFP-FPGA for 30 bucks. No BGA (woohoo), and its not that expensive.

As far as the CPLD is concerned: No, you really dont need 9k cells for a integrating ADC But, I really want the unit to be expandable, so people can add other front-ends, for example for L, C, F, and other stuff. So it's just a nice and versatile solution

A $30 BOM item you don't even have a use-case for? o.O

[mrflibble]

A $30 BOM item you don't even have a use-case for? o.O

Maybe he just want a moderately justifiable excuse to plonk in an fpga. At least that is how I interpret the "have to learn verilog" + "lack of any hard specs regarding interval timer resolution".

The only number I've seen timing wise was the "> 50 MHz counter frequency". Well, 20 ns is done easy enough with the stm32f4 as mentioned. So is 10 ns. Now with say 1 ns resolution we get into territory that it might make more sense to use an fpga. You can do all sorts of tricks to get the 1 ns with the stm32f4 again with an external prescaler yadda yadda, but in that case I think I'd choose fpga. And if you are after the 500 ps - 100 ps ballpark then suddenly fpga becomes quite effective in BOM cost + design effort, compared to other solutions I can think of.

But as said, since the only mention is of "something that counts at 50 MHz"... pffffrt, STM32F4. Problem solved.

Why not resort to something like this, the SVR-T should be a good choice at the beginning:

That's actually no bad idea at all. Sure, you might do better. But ... you might also do worse. And at least this is a design that has been out there for a while and should there be any quirks, you can be fairly sure there's some info out there. Info like that also has value ... something that the hobby posse sometimes forgets in their haste to add +1 to the Not Invented Here Syndrome Count.

[mrflibble]

Alright, in the meantime I've been reading some more of free_electron's (great ) posts about the multislope stuff + the HP Journal of april 1989. Damn, that multislope approach as done by HP is quite elegant.

[Stoney]

@FPGA stuff: lol guys, let's just wait until we have timing requirements from the integrator. Then we decide what we actually need

VDC input buffer doc online (in 03_ folder). Its a very dirty dave cad, hope u can read my handwriting  ....I'll do a clean one in software once it's close to final

Gimme some negative feedback 

[branadic]

...it just doesn't make sense if one can buy a TQFP-FPGA for 30 bucks...

I wonder why Agilent and Co still use their expensive hybrids in modern devices instead of a low cost fpga or cpld, if it was that easy to get a high precision integrating adc. There must be something overlocked, such as temperature dependent latency or similar effects that decrease the real resolution.

For the clock, I would use a FOX +-1,5ppm inital accuracy with +-2,5ppm drift TCO. They're cheap ($3-4), SMD, small and reliable (used them on quiet a number of boards, never head problems and well within specs).

Attached you find the specifications for a TCXO series of actcrystals. They have made me a bunch of TCXOs with customer specific frequency in another project. It's not an OCXO but very good for that price.

There are some other ADCs that are interesting:

CS5534 24-Bit A/D Converters with Ultra-Low-Noise PGIA
http://www.cirrus.com/en/products/cs5531-32-33-34.html

PRI5610 Präzisions - 26 Bit - ADC
http://www.ohh.de/5610.htm

ER-ADC150 programmable 24-bit integrating A/D converter
ER-ADC180 programmable 26-bit integrating A/D converter
http://elbertresearch.com/users/editorialdisp.php?mn=110669&fn=standardProducts

Particularly the last link matches the requirements for such a project and is a "ready to use" device.