Pax Instruments MultiLogger

[charlespax]

Now that the T400 is rolling along, I've been kicking around the idea of making an open source multimeter. I'm a bit reluctant to do this because there are already a number good quality and affordable multimeters out there. If I were to do this, it would have to be something very unique and not just another standard multimeter.

When I think of the term "multimeter" I think of a device that can measure the instantaneous value of one of several possible value types. Multimeters generally measure voltage, current, and resistance. Some multimeters can also measure frequency, temperature, duty cycle, and other parameters. There are some multimeters that can log data, but most only show you the instantaneous value you are measuring.

There are many situations where measuring a parameter over time is indispensable. Doing this by hand is often laborious or impractical. The difficulty increases in cases where multiple parameters must be measured over time. Maybe I'm thinking of something that should be called a "multilogger." This is the area I'm most interested in.

I'd love to have some input about what your use cases are and hat problems you have been trying to solve and been fumbling around with multiple multimeters and writing down data.

I'd appreciate it if you would provide a short description of the project you're working on and describe the parameters you would like to measure.

(original post)

[stmdude]

What I could really need is a DMM that works more in the time-domain.

My problem:
I make devices that uses a very small amount of power (operates years on a coin-cell).
This means that the device spends most of its time sleeping at ~1uA, with periodic wakeups that last <10uS
Now, to get an idea of how long the device would last on a battery, I usually hook it up to a 6.5 digit bench DMM, and log the crap out of it. However, since the update-rate on even expensive DMMs (34410A being used) is quite low at these currents (~10Hz), it will miss a lot of the wakeups.
Right now, I compensate with statistics, I.e, I run it for 1+ hours to make sure I get a proper average..
This takes time out of the development cycle, and would make automated power-measurements quite expensive (racks of 34410As or 34450As aren't cheap).

If I could get a DMM that measures faster (20Hz for instance) at these currents, it would cut my test-time in half..

An Oscilloscope would be a solution, but their dynamic resolution (voltage wise) aren't nearly good enough  (~1uA in sleep, ~10mA when RFing).

One could go about this in the regular multimeter way, but another way could be to charge a cap, drive the "load" off of that for a time-period, and then measure the remaining charge in the cap. Kind of a reverse sample-and-hold situation.

Apart from that, having a multimeter that can log over BLE (for example) would be nice for testing in temperature-chambers, acoustic chambers and the like.

[danadak]

On several occasions I have wanted a capable data logger, like when I repair
instruments and having power supply issues, like startup for example. By
having a logger that could capture startup kinds of speeds, 1 mS or better
sampling rate, over several days to find an intermittent in a cap, device.....

Modern DSO could have been used but they are limited on data capture over
long periods.

Another attribute that would be nice is a V source (low current, mA) and a
current source. Modern power supplies can function like this, but they have
low resolution in their settings.

A differential mode for measurements......

Regards, Dana.

[charlespax]

What I could really need is a DMM that works more in the time-domain.

My problem:
I make devices that uses a very small amount of power (operates years on a coin-cell).
This means that the device spends most of its time sleeping at ~1uA, with periodic wakeups that last <10uS
Now, to get an idea of how long the device would last on a battery, I usually hook it up to a 6.5 digit bench DMM, and log the crap out of it. However, since the update-rate on even expensive DMMs (34410A being used) is quite low at these currents (~10Hz), it will miss a lot of the wakeups.
Right now, I compensate with statistics, I.e, I run it for 1+ hours to make sure I get a proper average..
This takes time out of the development cycle, and would make automated power-measurements quite expensive (racks of 34410As or 34450As aren't cheap).

If I could get a DMM that measures faster (20Hz for instance) at these currents, it would cut my test-time in half..

An Oscilloscope would be a solution, but their dynamic resolution (voltage wise) aren't nearly good enough  (~1uA in sleep, ~10mA when RFing).

One could go about this in the regular multimeter way, but another way could be to charge a cap, drive the "load" off of that for a time-period, and then measure the remaining charge in the cap. Kind of a reverse sample-and-hold situation.

Apart from that, having a multimeter that can log over BLE (for example) would be nice for testing in temperature-chambers, acoustic chambers and the like.

(Just me thinking...) Okay, so characterizing the power consumption of devices that draw low power and have power spikes. I can see how high frequency measurement would be important. A 20 Hz rate is certainly doable. I wonder how a coulomb counter feature would compare against measuring voltage and current individually. SparkFun has a nice coulomb counter post.

[Jeroen3]

One that can measure power or phase would be nice. Those are rare.

[prasimix]

Don't know if that is count as standard feature but I'd like to measure L, C and eventually ESR.

Another thing: MCU that has enough flash (min. 512K) and SRAM (64K or more) that e.g. SCPI remote control can be added in one moment.

[charlespax]

On several occasions I have wanted a capable data logger, like when I repair
instruments and having power supply issues, like startup for example. By
having a logger that could capture startup kinds of speeds, 1 mS or better
sampling rate, over several days to find an intermittent in a cap, device.....

What sorts of things are you measuring during startup?

[stmdude]

Another thing: MCU that has enough flash (min. 512K) and SRAM (64K or more) that e.g. SCPI remote control can be added in one moment.

Holy crap. What are you planning on putting in there?  I can fit an RF stack, an RTOS, a CLI, SPI-code, and a crapload of logic into a 64/16 MCU, with more than half of the flash and RAM free for expansion.

But, different people want different things and tools. I don't know if Charles has a favourite MCU in mind?  Maybe they have pin&code compatible variants, so people could upgrade their MCU ?

[charlespax]

But, different people want different things and tools. I don't know if Charles has a favourite MCU in mind?  Maybe they have pin&code compatible variants, so people could upgrade their MCU ?

Right now I'm digging the STM32F103Rx series. In that family and package ST has a wide range of flash sizes from 16k up to 1024k. My experience with the ATmega32U4 taught me that when you need a little more programming space it's better to spend money on a high capacity chip than spend money on developers. It really sucks to spend heaps of time and money optimizing code just because your code compiles to 33k insteadk of 32k.


GigaDevice is a Chinese company that makes a series of ARM chips that are pin-compatible with ST chips. They don't cover ST's entire catalog, but do cover some important families. I understand GigaDevice licenses the ARM core and peripherals and just makes their chips register and pin compatible. They even have the same naming scheme (e.g. GD32F103). This allow me to effective have two manufacturers for the same chip. Second sourcing is wonderful    Additionally, GigaDevice carries the GD32F103Rx in 2048k and 3072k versions. Talk about headroom! It's like the chip-level version of Arduino and Freeduino etc..

I can see a device running FreeRTOS for the core software and having MicroPython or Espruino run as a low priority task. The core system would be nice and snappy while the interpreter could run user code without affecting core functions.

[bitseeker]

Hi Charles,

Here are some logging issues I've run into:

1. Testing power supplies. Simultaneously measuring voltage and current stability over time with and without a load. Currently using two bench DMMs (one for V, one for I). I have a multichannel logger, but it's V-only. I also use a scope for checking transient response during turn-on/off. It'd be nice to be able to consolidate these disparate data sources and even do it for multi-channel power supplies.

2. Testing/adjusting oscillators, function generators. Measuring frequency and phase between two sources for alignment and stability over time. For example, adjusting an OCXO to a GPSDO source or verifying phase stability of a mutli-channel function generator.

3. I don't current have need for this, but I could see factoring in ambient and/or enclosure/component temperature data along with the data in #1 and #2.

[bitseeker]

Oh, as a side note, having to log via a blend of GPIB, Ethernet, USB, and serial interfaces is...challenging.

[stmdude]

But, different people want different things and tools. I don't know if Charles has a favourite MCU in mind?  Maybe they have pin&code compatible variants, so people could upgrade their MCU ?

Right now I'm digging the STM32F103Rx series.

They're good mid-range devices for sure. Pin-compatible to a large extent, except that you only get (for example) DAC functionality on the high-density devices.
But, it will allow you to start with a 512KB flash device for development, and then cost-optimize down to 384 or 256 depending on how big your code ends up. Only manufacturer that does that afaik.

Done know about which peripherals the GigaDevices MCUs have though. As in, are they compatible with a low, medium or high-density STM32F103 ?

I can see a device running FreeRTOS for the core software and having MicroPython or Espruino run as a low priority task. The core system would be nice and snappy while the interpreter could run user code without affecting core functions.

That would work. Don't know which language would be the most compatible with EE guys though. There are tiny JavaScript interpreters as well as LUA to consider.

[Marco]

Now, to get an idea of how long the device would last on a battery, I usually hook it up to a 6.5 digit bench DMM, and log the crap out of it. However, since the update-rate on even expensive DMMs (34410A being used) is quite low at these currents (~10Hz), it will miss a lot of the wakeups.=

Doesn't it do 1 ks/s at 6.5 digits?

PS. you of course need to low pass the current somehow to make sure you don't miss short events, a large enough (super-)capacitor in parallel with the load so that together with the shunt resistance it low passes the current to 500 Hz should do it.

[ataradov]

I make devices that uses a very small amount of power (operates years on a coin-cell).

I came here to type basically  the same thing, so major +1. A tool for low-power profiling would be awesome.

[charlespax]

Done know about which peripherals the GigaDevices MCUs have though. As in, are they compatible with a low, medium or high-density STM32F103 ?

Datasheet is attached with relevant GD32F103 peripheral tables.

[trevwhite]

What I could really need is a DMM that works more in the time-domain.

My problem:
I make devices that uses a very small amount of power (operates years on a coin-cell).
This means that the device spends most of its time sleeping at ~1uA, with periodic wakeups that last <10uS
Now, to get an idea of how long the device would last on a battery, I usually hook it up to a 6.5 digit bench DMM, and log the crap out of it. However, since the update-rate on even expensive DMMs (34410A being used) is quite low at these currents (~10Hz), it will miss a lot of the wakeups.
Right now, I compensate with statistics, I.e, I run it for 1+ hours to make sure I get a proper average..
This takes time out of the development cycle, and would make automated power-measurements quite expensive (racks of 34410As or 34450As aren't cheap).

If I could get a DMM that measures faster (20Hz for instance) at these currents, it would cut my test-time in half..

An Oscilloscope would be a solution, but their dynamic resolution (voltage wise) aren't nearly good enough  (~1uA in sleep, ~10mA when RFing).

One could go about this in the regular multimeter way, but another way could be to charge a cap, drive the "load" off of that for a time-period, and then measure the remaining charge in the cap. Kind of a reverse sample-and-hold situation.

Apart from that, having a multimeter that can log over BLE (for example) would be nice for testing in temperature-chambers, acoustic chambers and the like.

Some meters have an integral based current measurement. They use a PLC setting. So say you set it to 1 second it will integrate total current over that second. This might help with average current measurements. It works well on my Keithley 2110. I tested it with a 1ms current pulse over 1 second and it measured average current nicely

[charlespax]

I came here to type basically  the same thing, so major +1. A tool for low-power profiling would be awesome.

What kind of resolution do you need in terms of time and voltage? Would it be sufficient to use a coulomb counter that gives resolution of 0.1707mAh?

[stmdude]

Done know about which peripherals the GigaDevices MCUs have though. As in, are they compatible with a low, medium or high-density STM32F103 ?

Datasheet is attached with relevant GD32F103 peripheral tables.

Seems like the GD32F103 Tx, Cx, R4->B, V8, VB would correspond to the STM32 Medium-density devices.
GD32F103 RC->RK, VC->VK would correspond to the high/xl-density devices.

As for STM32F103: 
STM32F103x4/x6 are low-density devices.
STM32F103x8/xB are medium-density devices.
STM32F103xD are high-density devices.
STM32F103xF/xG are XL-density devices.

[stmdude]

Some meters have an integral based current measurement. They use a PLC setting. So say you set it to 1 second it will integrate total current over that second. This might help with average current measurements. It works well on my Keithley 2110. I tested it with a 1ms current pulse over 1 second and it measured average current nicely

Oh, nice. How does it deal with dynamic range?  As in, my device sleeps at ~1uA, and then "every now and then" transmits RF, and jumps to ~13mA (for <10uS). The 6.5 digit range on the 34410 doesn't like that, and wants to switch ranges on me (unless I shove a big old cap in parallel to take the edge off).

I've been eyeing a 8.5 digit DMM, but I can't really justify the cost..

[trevwhite]

Some meters have an integral based current measurement. They use a PLC setting. So say you set it to 1 second it will integrate total current over that second. This might help with average current measurements. It works well on my Keithley 2110. I tested it with a 1ms current pulse over 1 second and it measured average current nicely

Oh, nice. How does it deal with dynamic range?  As in, my device sleeps at ~1uA, and then "every now and then" transmits RF, and jumps to ~13mA (for <10uS). The 6.5 digit range on the 34410 doesn't like that, and wants to switch ranges on me (unless I shove a big old cap in parallel to take the edge off).

I've been eyeing a 8.5 digit DMM, but I can't really justify the cost..

I set my 5.5 digit meter to 100ma range and it did the rest. Its an analogue measurement technique so I have a feeling it will handle things. Possibly if signals are extremely quick it might struggle but seriously I do wake up and sleep stuff and before I found the integral feature average current was a nightmare. Now it is easy

[charlespax]

For hardware, I'd like to reuse the T400 enclosure if possible since I already have the tooling. The top panel is interchangeable and can be replaced with a 1.6 mm PCB. There are six buttons, a MicroUSB connector, MicroSD card connector, and a 132x64 pixel LCD.

I'm wondering what everyone thinks of the landscape layout versus a traditional portrait style hand-held meter. Personally, almost always use my DMMs when they're sitting on my bench rather than held in my hand. It can be frustrating to shuffle things around on a bench and knock over or nearly knock over a multimeter. I made my temperature data logger in a landscape format to keep it nice and stable. Pulling on a cable just drags it along a bench instead of tipping it over. I wonder how suitable this format would be for a multimeter. If you want to take a closer look at the enclosure, check out the github repo https://github.com/PaxInstruments/t400-enclosure. How do you feel about this form factor?



Since the front is mostly screen it doesn't really fit a traditional range switch. Function selection could be done with software buttons or maybe slider switch.

Would a landscape design be crazy, awesome, or something in between?

[ajb]

Some way to synchronize and time-correlate multiple units would be nice.  Could be as simple as a trigger in/out, or something more sophisticated to facilitate easy master/slave configurations when you need to log across multiple channels.  The latter is less compelling if you're intending this to be automated via PC, but for standalone use being able to pull logs from multiple units through one interface would be nice.

[ataradov]

What kind of resolution do you need in terms of time and voltage? Would it be sufficient to use a coulomb counter that gives resolution of 0.1707mAh?

I don't know what technical implementation would be the best. So let me describe how I do it right now. Typical things I work with will sleep and consume ~2.5 uA, at wake up power consumption is very dynamic and goes up to ~20 mA, but with very variable profile. Wake up duration is 5-20 ms. I'll attach some pictures later.

Right now I do high resolution (in the time domain) captures of a voltage drop over 10 Ohm resistor. This gives me a representation of the active current consumption that I can integrate. I identify all possible wake up scenarios, capture a representative sample of all of them and do my battery estimations based on the sleep current (measured with a DMM) and number of events and expected power consumption during that event.

This is a time-consuming process, but I found the accuracy good enough.

Resolution of 0.1707mAh will be more than sufficient, but what about the accuracy?

[stmdude]

Would a landscape design be crazy, awesome, or something in between?

Landscape works fine on bench DMMs. Should work fine, I'd guess. No need to plan a new tooling before trying what you have already.

As for the rest of the form-factor, I'm a little worried about the tippy-overness of it when connecting some decent banana-jack cables. They're not _super_ heavy, but the T400 doesn't look very hefty either.. 

I'm looking at https://github.com/PaxInstruments/t400-electronics/blob/master/eagle/T400%20Rev%200.14/PaxInstrument-T400.pdf ..
Seems like I could whip up an STM32 board that would fit in it quite quickly.  Won't do any multimetering, but enough to test the interaction.
Where does the battery connect?  Can't find it..
Would you mind sharing the part-numbers for the buttons and LCD connector?

[charlespax]

I'm looking at https://github.com/PaxInstruments/t400-electronics/blob/master/eagle/T400%20Rev%200.14/PaxInstrument-T400.pdf ..
Seems like I could whip up an STM32 board that would fit in it quite quickly.  Won't do any multimetering, but enough to test the interaction.
Where does the battery connect?  Can't find it..
Would you mind sharing the part-numbers for the buttons and LCD connector?

The battery connects on the back side of the PCB. You can see it in the attached image circled in red.


I've been planning on making a developer PCB with the processor, power, and all external interfaces populated on the PCB. Then there would be an empty area where a submodule could be soldered on. See the yellow area in the image below.



The LCD connector is a 12 pin 1 mm pitch FPC connector. It's a fairly standard footprint with many parts that fit it. The part number I use is FH12-12S-1SH(55). You can find a more detail conversation here.


The T400 tactile switches are generic ones, I don't have a specific part number. My PCBA house has suggested using more common square footprints that are more available. These can happily change.