IOT Power Supply Design

[EEEnthusiast]

Friends,

I am starting work on a new design for an  IOT power supply which would have similar features as the ZS2102A, with added isolation and extended measurement range.
The current measurement shall be extended from 100nA to 2A with 1%+/- 10nA error. Sampling rate may be increased to 2Msps.
The output voltage shall be programmable from 0.8V to 6V in 10mV steps, with programmable current limits.

It is under design and simulation now and plan to release by mid 2020. If you have any inputs for the design, I would be highly pleased to add them now.

Some inputs which received are listed below.
1. Add a LCD / OLED display to indicate the set voltage and current measured.
 Most likely I will add a 1.3" matrix OLED display so that it can plot some graphics as well.

2. Have USB 3.0 bus interface with fallback on USB 2.0
Use the FTDI FT601 chip.

3. Load voltage sensing
Add another port with Sense+ and Sense- for both Supply and Ground Sensing.

4. Battery simulation

[windsmurf]

How about ability to stream the data over wifi 802.11ax, no physical USB cable needed.

[mariush]

What's the point of usb 3.0 ?  It's a silly IOT psu, doesn't need 5  gbps of throughput.

usb 2.0 is enough, and there's plenty cheap serial/spi to usb chips that aren't made by FTDI (which is controversial due to blacklisting drivers)

But I'd go even further.. screw usb, put an ethernet chip like ENC424 on board and you can use UDP to stream the samples to anything. optionally have a wireless module/bluetooth module. It's a psu for IOT so it's only natural someone that wants this will already have wireless or ethernet around to connect these internet of things devices

See pdf below, you can easily get 8-10mbps even with a cheap microcontroller.  You will probably not need that much... you say 2m sample rate, but it will compress very well (run length encoding, some super fast lzo, zlib etc, could probably get it working on 11mbps wireless just fine)

Ethernet is isolated by default, wireless is isolated, usb isn't by default ... your box is isolated 100% without usb.

Could power it from internal batteries... think 2-3 18650 batteries in parallel ... gives you a few hours of operation before they need to be recharged.
You could use a simple QI charging mat under the box to enable charging wirelessly at 5v 0.5..1A : https://www.ebay.com/itm/Universal-Qi-Wireless-Charger-Charging-Pad-Mat-Receiver-For-Apple-iPhone-6S-Plus/371711661941
and/or you could add a barrel jack for 5v..12v and enable faster charging of internal batteries (like 2-3A charge rate)...


802.11ax is overkill... everyone with a wireless router will support 2.4ghz so plain 802.11 g/n would be sufficient. Ideally something that does 5ghz would be great but not needed.

[thm_w]

What's the point of usb 3.0 ?  It's a silly IOT psu, doesn't need 5  gbps of throughput.

No point in the data-rate yeah, but there is a purpose to having USB-C and higher power delivery, so some extra chips are required for that.

This is similar to the idea of the µsupply, so some premium features compared to that design would be useful: LCD as you suggested, possibly batteries as above, sounds like resolution and sample rate is higher which is good.

Local datalogging to SD card?

[EEEnthusiast]

How about ability to stream the data over wifi 802.11ax, no physical USB cable needed.

The un-compressed data stream is about 64Mbit/sec on the ZS2102A. If the sampling rate were increased for the power supply, this would almost double. This is beyond what 802.11ax can support as the entire WiFi spectrum is shared with multiple radios. It may be possible to do this if the data was compressed within the box and sent over the air. But that needs a high performing processor to be put on board. That adds to the cost, space and noise , not to mention writing the firmware for the compression routine. The compression takes about 15% of CPU on a core i3 @ 2.3GHz. So adding this number crunching to the tool may be overkill.

[EEEnthusiast]

What's the point of usb 3.0 ?  It's a silly IOT psu, doesn't need 5  gbps of throughput.

usb 2.0 is enough, and there's plenty cheap serial/spi to usb chips that aren't made by FTDI (which is controversial due to blacklisting drivers)

But I'd go even further.. screw usb, put an ethernet chip like ENC424 on board and you can use UDP to stream the samples to anything. optionally have a wireless module/bluetooth module. It's a psu for IOT so it's only natural someone that wants this will already have wireless or ethernet around to connect these internet of things devices

See pdf below, you can easily get 8-10mbps even with a cheap microcontroller.  You will probably not need that much... you say 2m sample rate, but it will compress very well (run length encoding, some super fast lzo, zlib etc, could probably get it working on 11mbps wireless just fine)

Ethernet is isolated by default, wireless is isolated, usb isn't by default ... your box is isolated 100% without usb.

Could power it from internal batteries... think 2-3 18650 batteries in parallel ... gives you a few hours of operation before they need to be recharged.
You could use a simple QI charging mat under the box to enable charging wirelessly at 5v 0.5..1A : https://www.ebay.com/itm/Universal-Qi-Wireless-Charger-Charging-Pad-Mat-Receiver-For-Apple-iPhone-6S-Plus/371711661941
and/or you could add a barrel jack for 5v..12v and enable faster charging of internal batteries (like 2-3A charge rate)...


802.11ax is overkill... everyone with a wireless router will support 2.4ghz so plain 802.11 g/n would be sufficient. Ideally something that does 5ghz would be great but not needed.

The purpose of USB 3.0 is to capture the current and voltage waveform sampled at 1 or 2MSPS at 32bits. That needs a fat pipe. USB 2.0 may be just about sufficient, but using the 3.0 interface allows for better headroom and lower CPU usage.

Running the compression on the hardware could enable use of ethernet or wiFi for the data transmission. As I posted earlier, the compression of the IOT current data is quite performance intensive and it would mean adding a high performance processor on the board with increase space, cost, complexity, noise and power consumption. I think, using a fat pipe to stream the data to the PC and using the PC's massive processing power is the optimal cost effective solution.

[EEEnthusiast]

What's the point of usb 3.0 ?  It's a silly IOT psu, doesn't need 5  gbps of throughput.

No point in the data-rate yeah, but there is a purpose to having USB-C and higher power delivery, so some extra chips are required for that.

This is similar to the idea of the µsupply, so some premium features compared to that design would be useful: LCD as you suggested, possibly batteries as above, sounds like resolution and sample rate is higher which is good.

Local datalogging to SD card?

Yes, adding USB 3.0 allows for extra power as well. On the PC side, having the USB 3.0 interface would mean lower CPU interruptions as the USB 3.0 interface can pack more data into one packet, compared to the USB 2.0. So there is some CPU cycles saved which improves the software stability.

[mariush]

The purpose of USB 3.0 is to capture the current and voltage waveform sampled at 1 or 2MSPS at 32bits. That needs a fat pipe. USB 2.0 may be just about sufficient, but using the 3.0 interface allows for better headroom and lower CPU usage.

Running the compression on the hardware could enable use of ethernet or wiFi for the data transmission. As I posted earlier, the compression of the IOT current data is quite performance intensive and it would mean adding a high performance processor on the board with increase space, cost, complexity, noise and power consumption. I think, using a fat pipe to stream the data to the PC and using the PC's massive processing power is the optimal cost effective solution.

You say you want 0.8v .. 6v and 100nA .. 2A   ... 2A is 2,000,000,000 nA  ... 24 bits unsigned is 16,777,216 so you could have two ranges :
100nA .. 400mA  : 400,000,000 nA ... 25nA steps will give you 0 .. 16.000.000  so it can fit in 24 bits unsigned
400mA .. 2A :1,600,000,000 nA ... 100nA steps will give you 0 .. 16.000.000 again, fits in 24 bits unsigned

Do you think you're really need more than 25nA or 100nA steps on a IoT psu?

For voltage, 6v is 6000mV or 6.000.000 uV ... you can get 1uV precision up to 16v with 24 bits

Unless you get some super fancy current shunts and expensive ADCs you're not gonna get 32 bit conversion where the last 8 bits will actually make a difference. Are you gonna pack 20$+  ADC chips and 10$+ voltage references into a IoT power supply?

Also, 1-2 million samples per second ... that's 1-2000 samples per ms ... the current and voltage won't change so much within a ms ... probably most of the time only the last 8-10 bits will change.
So you can do some basic RLE encoding ... get up to 255 samples, then group together the first byte or first 12 bits of the 24 bits for the voltage, then the next byte and so on..  for example 4 bits for repeat count + 12 bits of data will allow you up to 16 consecutive 12 bit parts to be saved as a single 16 bit value, saving 24 bytes in 2 bytes .

example packet:
[one byte : number of samples that follow : 0..255 ]
[one byte : number of rle groupings for 1st 12bits of voltage ]
[one byte : number of rle groupings for 2nd 12bits of voltage ]
[one byte : number of rle groupings for 1st 12bits of current ]
[one byte : number of rle groupings for 2nd 12bits of current ]
[0..3 bytes : optional padding to keep it multiple of 4 or 6 bytes? maybe add a CRC16 in two bytes? maybe one byte for V and A range ( range won't change within a data packet)]

[ 2 bytes : 4 bits count of samples, 12 bits of data - first 12 bits of voltage/current, last 12 bits of voltage/current ]
... repeat for each 12 bits  of voltage/current

ex for 3 voltages and currents:   0xF11940 ,  0xF11900 ,  0xF10540  , 0x312D00 ,  0x312550 , 0x310000

1 bytes : 3 samples
1 bytes + 2 bytes : 2 groupings for voltage first 12 bits :  0x02 0xF11  0x01 0xF10
1 bytes + 3 bytes : 3 groupings for voltage last 12 bits : 0x01 0x940 0x01 0x900 0x01 0x540
1 bytes + 2 bytes : 2 groupings for current first 12 bits :  0x02 0x312  0x01 0x310
1 bytes + 3 bytes : 3 groupings for current last 12 bits : 0x01 0x540 0x01 0x550 0x01 0x000

0x03 0x02 0x03 0x02 0x03 0x00 [ data 2 bytes x groupings]

total packet size : 15-18 bytes depending on padding bytes (18 bytes without RLE) .... with more than 3 samples, you'll likely to get more compression.

Worst case scenario if every byte is unique, you'd get 255 x 4 bits x 4 ... 512 bytes extra to a 3 x 255 byte packet ... so still fits into a 2 KB "packet" of data.

[EEEnthusiast]

The purpose of USB 3.0 is to capture the current and voltage waveform sampled at 1 or 2MSPS at 32bits. That needs a fat pipe. USB 2.0 may be just about sufficient, but using the 3.0 interface allows for better headroom and lower CPU usage.

Running the compression on the hardware could enable use of ethernet or wiFi for the data transmission. As I posted earlier, the compression of the IOT current data is quite performance intensive and it would mean adding a high performance processor on the board with increase space, cost, complexity, noise and power consumption. I think, using a fat pipe to stream the data to the PC and using the PC's massive processing power is the optimal cost effective solution.

You say you want 0.8v .. 6v and 100nA .. 2A   ... 2A is 2,000,000,000 nA  ... 24 bits unsigned is 16,777,216 so you could have two ranges :
100nA .. 400mA  : 400,000,000 nA ... 25nA steps will give you 0 .. 16.000.000  so it can fit in 24 bits unsigned
400mA .. 2A :1,600,000,000 nA ... 100nA steps will give you 0 .. 16.000.000 again, fits in 24 bits unsigned

Do you think you're really need more than 25nA or 100nA steps on a IoT psu?

For voltage, 6v is 6000mV or 6.000.000 uV ... you can get 1uV precision up to 16v with 24 bits

Unless you get some super fancy current shunts and expensive ADCs you're not gonna get 32 bit conversion where the last 8 bits will actually make a difference. Are you gonna pack 20$+  ADC chips and 10$+ voltage references into a IoT power supply?

Also, 1-2 million samples per second ... that's 1-2000 samples per ms ... the current and voltage won't change so much within a ms ... probably most of the time only the last 8-10 bits will change.

For accurately measuring the IOT currents, we need to sample it at about 1Msps. In case of WiFi devices, some transmit packets can be few tens of micro seconds wide. If we sample any slower, these pulses would be missed out and the battery life estimation would be inaccurate.
The voltage would not change much I agree, but when there is a sampling clock, it is much easier to sample all signals with that. It makes the software work much more simpler as there is no interpolation required later on.

To get the required dynamic range and accuracy, the current is sampled with multiple 16bit precision ADCs working at 1 or 2 Msps. That adds to the overall information bit-rate from the hardware.

Regarding the compression running on the hardware. Even if I chose to compress it using RLE, I would still need a processor which is capable of taking in 64Mbits+ of data per second and process it in real time. I don't think any small Atmega or MSP430s can do this job reliably. Possibly a DSP processor can do the trick, but it is just adding cost to the system when we can use the PCs massive processors.

[LogicEthos]

I'm interested in this.  Part of a project I am working on to secure IOT devices.  We need to measure power usage.

  for usb 3.0. Must be isolated.

Or build the whole thing around a Raspberry Pi.  Options then for WiFi. Ethernet PoE.  Data logging.

[windsmurf]

How about ability to stream the data over wifi 802.11ax, no physical USB cable needed.

The un-compressed data stream is about 64Mbit/sec on the ZS2102A. If the sampling rate were increased for the power supply, this would almost double. This is beyond what 802.11ax can support as the entire WiFi spectrum is shared with multiple radios. It may be possible to do this if the data was compressed within the box and sent over the air. But that needs a high performing processor to be put on board. That adds to the cost, space and noise , not to mention writing the firmware for the compression routine. The compression takes about 15% of CPU on a core i3 @ 2.3GHz. So adding this number crunching to the tool may be overkill.

How about limiting the sampling rate output for WIFI?  Local storage/capture option?   iPhone/Android monitoring and control app?

[EEEnthusiast]

I'm interested in this.  Part of a project I am working on to secure IOT devices.  We need to measure power usage.

  for usb 3.0. Must be isolated.

Or build the whole thing around a Raspberry Pi.  Options then for WiFi. Ethernet PoE.  Data logging.

Using a RPi is a good option. Just need to design an interface card which has all the precision analog blocks. The RPi can do the compression and can even host the GUI as a web server. So I dont need to have different apps on PC , MAC and Linux. Let me run it through my mind to see if there are any bottlenecks.

[mariush]

Eh, a STM32H7 that costs less than 14$ can run at up to 480 Mhz, has build in lcd tft controller, quad spi capable of accessing up to 256MB of flash ram directly, has memory controller (up to 32 bit wide SDRAM for example, so you could buffer in ram then dump into an eMMC or flash memory or whatever)
example link : https://www.digikey.com/product-detail/en/stmicroelectronics/STM32H753IIT6/497-18565-ND/8257853
 

Even a NXP LPC4337JBD144E  would be a great alternative: https://www.digikey.com/product-detail/en/nxp-usa-inc/LPC4337JBD144E/568-10159-ND/3868775

dual core, up to 200 mhz, ethernet , memory controller, loads of features... under 10$ in volume...

[LogicEthos]

Raspberry Pi's are cheap, and make a great platform for developing stuff like this on top of.  It's not necessary the best solution for an end product, but it can speed up the time and cost to get something running.  Depends who your target audience is, Closed/Open Hardware and what your willing to spend in R&D.

From the recent Amp Hour podcast, Dave said it's taking far longer to develop his PSU solution, than he expected.

[EEEnthusiast]

Raspberry Pi's are cheap, and make a great platform for developing stuff like this on top of.  It's not necessary the best solution for an end product, but it can speed up the time and cost to get something running.  Depends who your target audience is, Closed/Open Hardware and what your willing to spend in R&D.

From the recent Amp Hour podcast, Dave said it's taking far longer to develop his PSU solution, than he expected.

Was not aware that Dave is working on a PSU design. Where can I find more information on this?

[LogicEthos]

uSupply.  He has talked about aspects of it in the Amp Hour podcasts, including the most recent one where be mentions USB Isolation.  He also did a video about custom heatsinks in #1196.  And during the Joulescope video, he said he was working on a competing device.

[EEEnthusiast]

I looked at the uSupply. It looks like a regular digitally programmable power supply and does not have a high speed current measurement option. The one I am proposing will have high dynamic range and high speed current measurement at the same time. So this could be a niche one and may be useful for thousands of IOT developers who may not have an easy way to profile the current and estimate the battery life.

[EEEnthusiast]

After going through the system noise calculations, it looks like the output connectors for the power supply would need to be shielded, in order to measure 100nA currents accurately. This calls for some fancy connector at the output. The banana jacks would not be enough for this purpose. Does any one have experience with using the XLR connectors for power supply.
http://ioaudiotech.com/datasheet/IO-XLR3-X-JL.pdf

They are usually used for audio, but they can take couple of amps without issues. The cables come with shield with a twisted pair for the current carrying conductors. That makes it very good for interference rejection.

The main worry in measuring low current, is the connecting wires picking up RF interfernce and the non linearity in the signal chaining making them to appear as a DC offset. This places restrictions on the output connector. I have EMI filters on the signal path, but it is better to avoid pick-up rather than try to attenuate it.

What is your opinion on the XLR3 connectors for power supply?
The other option is BNC but the cables used with BNC are not meant to carry high current. So I decide not to use them.

[nctnico]

XLR is also commonly used for power connections. I've seen that in many cases. N Connectors can also carry quite a bit of current but for a PSU I think XLR would be a better solution.

[EEEnthusiast]

Fellow Geeks,

I'm looking for a reliable I2C OLED display for the power supply. It has to be alpha numeric. I know a lot of graphic OLED displays (the famous 0.96" and 1.3" ones). But these require quite a bit of data transfer on the I2C bus which blocks other critical things on the bus.

The size should be within 50mm x 30mm. Prefer smaller. Configuration of 4x2 lines or 6x2 lines is good enough.
All i need to display is the output voltage, average current and some error message.

[JxR]

Fellow Geeks,

I'm looking for a reliable I2C OLED display for the power supply. It has to be alpha numeric. I know a lot of graphic OLED displays (the famous 0.96" and 1.3" ones). But these require quite a bit of data transfer on the I2C bus which blocks other critical things on the bus.

The size should be within 50mm x 30mm. Prefer smaller. Configuration of 4x2 lines or 6x2 lines is good enough.
All i need to display is the output voltage, average current and some error message.

What about a separate micro as an IC2 slave that drives the display?  You can send small commands to the slave micro, and it can do the heavy lifting of driving the display.  Separate bus between the display and slave of course if still using I2C.

[EEEnthusiast]

Using a slave micro is a good idea. May be I can have the master - slave communication over I2C and the slave MCU->Display over SPI.
Thanks for the input. That should work. All I need to implement is a command parser for the slave MCU.

[Kean]

Not sure what micro you are using, but does it support more than one I2C bus?

Or could you use an SPI connected display?  SPI is faster and less CPU intensive.
e.g. https://www.aliexpress.com/item/4000016800528.html

If neither of those are a good option, then using a slave mcu to offload the processing works well.  It can potentially be quite low spec, just need enough flash for the fonts.

[EEEnthusiast]

I do not have any micro on the board. The display is currently driven by the FTDI from the PC over the USB bus. I think it is best to add a simple Arduino based MCU on the board to make the software much easier. Yes, the SPI based displays look cool .

[nctnico]

Using a slave micro is a good idea. May be I can have the master - slave communication over I2C and the slave MCU->Display over SPI.
Thanks for the input. That should work. All I need to implement is a command parser for the slave MCU.

No it is not. Using two MCUs is a recipy for dissaster. Use one MCU and be clever about how the tasks are divided. A simple way to make sure a process gets enough time is to run it from a timer interrupt.