EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: EEEnthusiast on July 23, 2019, 05:30:08 am
-
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
-
How about ability to stream the data over wifi 802.11ax, no physical USB cable needed.
-
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 (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.
-
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?
-
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.
-
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 (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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
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 (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 (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...
-
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.
-
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?
-
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.
-
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.
-
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 (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.
-
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.
-
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.
-
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.
-
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.
-
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 (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.
-
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 .
-
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.
-
and be clever
"Clever" programmers drive me nuts! I'm sure we all have a story... |O
So if someone is asking/discussing in general terms how to do something, then it is usually best to give a simple option. At least until more details come out... like "I do not have any micro on the board."
If they have enough experience to implement a more complex solution then they're unlikely to be asking. In this case, handling I2C in timer interrupts won't help with I2C's limited bandwidth.
-
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.
Better not open any test equipment if you don't want to see disaster in production. Having a separate micro run the display section is a fairly common.
-
I'm not saying it can't be done but it adds more complexity like needing a protocol and dealing with the situation the communication is lost (or impaired).
A more simpler solution would be to have two I2C busses and use interrupts and/or DMA to transfer the data so the CPU doesn't have to wait for the transfers to finish. Yes, this can also be done using bit-banging and timer interrupts.
-
I'm not saying it can't be done but it adds more complexity (like needing a protocol).
Defining that protocol layer also allows a clean point to split the product development time between people/teams - much like modern application development splits UI vs application logic.
This can* also make a better product - e.g. more flexibility, easier repair/upgrades, common UX across product range, longer product life.
*can, but doesn't always...
-
What's your budget?
10$ 40mm x 35mm 8x2 parallel
https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-FL-GBW/NHD-0208AZ-FL-GBW-ND/1701134 (https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-FL-GBW/NHD-0208AZ-FL-GBW-ND/1701134)
https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-FSW-GBW-33V3/NHD-0208AZ-FSW-GBW-33V3-ND/2773587 (https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-FSW-GBW-33V3/NHD-0208AZ-FSW-GBW-33V3-ND/2773587)
https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-RN-YBW/NHD-0208AZ-RN-YBW-ND/1701132 (https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-RN-YBW/NHD-0208AZ-RN-YBW-ND/1701132)
https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-FL-YBW/NHD-0208AZ-FL-YBW-ND/1701133 (https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-FL-YBW/NHD-0208AZ-FL-YBW-ND/1701133)
https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-RN-GBW/NHD-0208AZ-RN-GBW-ND/2165845 (https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-RN-GBW/NHD-0208AZ-RN-GBW-ND/2165845)
https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-RN-YBW-33V/NHD-0208AZ-RN-YBW-33V-ND/2773586 (https://www.digikey.com/product-detail/en/newhaven-display-intl/NHD-0208AZ-RN-YBW-33V/NHD-0208AZ-RN-YBW-33V-ND/2773586)
If you use these in 4bit mode, you need 6..7 wires to "talk" to one. IF you make it one way only (if you don't have to poll to see if it's busy or you don't need to read data from it), a simple shift register would solve your problem. Shift 8 bits, send them to display (4 data, rs, rw, enable), repeat.
You can solder the lcd contrast resistor(s)/potentiometer directly on the lcd display board.
If you can stretch that to ~ 53 mm width , you could use 8x1 14 segment LCDs :
~4.3$ each on Digikey, 2.5$ if you get 100, but you could probably source them from lcdc or other places, it's probably standard format.
reflective, 3.3v : https://www.digikey.com/product-detail/en/varitronix/VIM-878-DP-RC-S-LV/153-1115-ND/1118605 (https://www.digikey.com/product-detail/en/varitronix/VIM-878-DP-RC-S-LV/153-1115-ND/1118605)
transflective 3.3v .. 4.6v : https://www.digikey.com/product-detail/en/varitronix/VIM-878-DP-FC-S-LV/153-1113-ND/1118603 (https://www.digikey.com/product-detail/en/varitronix/VIM-878-DP-FC-S-LV/153-1113-ND/1118603)
reflective, hv version (up to 7.7v) : https://www.digikey.com/product-detail/en/varitronix/VIM-878-DP-RC-S-HV/153-1114-ND/1118604 (https://www.digikey.com/product-detail/en/varitronix/VIM-878-DP-RC-S-HV/153-1114-ND/1118604)
Cheap in volume, super low power, if you absolutely need backlight a simple led can be added on the sides.
Use a microcontroller with built in lcd controller, or just use an actual lcd controller, there are some which have i2c or spi
Yes, it's only 8 digits, but you can print voltage (and being 14segment you can also print a v), wait a couple seconds, print current, blink a short error message ex err. 100 , or statuses like "uSb Conn" etc
The above are 36 segments, 4 commons...
Example of lcd driver that I think would work just fine:
36segment / 4common, ~ 1$ each at Digikey.
i2c PCF8551ATT: https://www.digikey.com/product-detail/en/nxp-usa-inc/PCF8551ATT-AJ/568-13181-1-ND/6576096 (https://www.digikey.com/product-detail/en/nxp-usa-inc/PCF8551ATT-AJ/568-13181-1-ND/6576096)
spi PCF8551BTT-AJ https://www.digikey.com/product-detail/en/nxp-usa-inc/PCF8551BTT-AJ/568-13772-1-ND/8041379 (https://www.digikey.com/product-detail/en/nxp-usa-inc/PCF8551BTT-AJ/568-13772-1-ND/8041379)
40segment / 4 common (can just leave 4 unused)
i2c/spi PCF8553DTT-AJ https://www.digikey.com/product-detail/en/nxp-usa-inc/PCF8553DTT-AJ/568-14373-1-ND/9449822 (https://www.digikey.com/product-detail/en/nxp-usa-inc/PCF8553DTT-AJ/568-14373-1-ND/9449822)
i2c PCF8576DT-2118 https://www.digikey.com/product-detail/en/nxp-usa-inc/PCF8576DT-2118/568-3558-1-ND/1144586 (https://www.digikey.com/product-detail/en/nxp-usa-inc/PCF8576DT-2118/568-3558-1-ND/1144586)
You can order some custom PCBs from jlpcb or whatever, place the chip and the 4..6 pin header on one side, and leave the other side matte (so you can glue an aluminum foil or some reflective sticker.
Optionally, add some right angle surface mount leds under the lcd digits for backlight purposes
You can probably find lcd drivers at lcsc for half a dollar or less, that would work just well.
-
Thanks for all the valuable inputs.
More than the budget, I have a size limitation with the current case. My display size is restricted to 40x25mm or smaller. Budget can be flexible, but $10 for a display is overkill. I would like anything < 5$ .
But Digikey prices are overrated. I may be able to get those at 1/2 the price from some other distributors.
I am wondering if they make LCD screens like this with I2C interface.
https://jingshimei.en.alibaba.com/product/62019597651-810314584/Custom_LCD_screen_minimum_size_segment_code_Positive_FSTN_LCD_screen.html?spm=a2700.icbuShop.41413.23.6dc164f0Cm72P1
Those should be very easy to use and run off really low power.
-
4.8$ @ 1 , 3.5$ @ 25 : 30mm x 11.5m 128 x 32 px OLED white text: https://www.tme.eu/en/details/rex012832dwpp3n0/graphical-oled-displays/raystar-optronics/rex012832dwpp3n00000/ (https://www.tme.eu/en/details/rex012832dwpp3n0/graphical-oled-displays/raystar-optronics/rex012832dwpp3n00000/)
same series in
yellow : https://www.tme.eu/en/details/rex012832dypp3n0/graphical-oled-displays/raystar-optronics/rex012832dypp3n00000/ (https://www.tme.eu/en/details/rex012832dypp3n0/graphical-oled-displays/raystar-optronics/rex012832dypp3n00000/)
sky blue : https://www.tme.eu/en/details/rex012832dspp3n0/graphical-oled-displays/raystar-optronics/rex012832dspp3n00000/ (https://www.tme.eu/en/details/rex012832dspp3n0/graphical-oled-displays/raystar-optronics/rex012832dspp3n00000/)
A variation of the above series , (F instead of D), and the ribbon cable is slightly different, but several colors available each in lower stock amount:
yellow https://www.tme.eu/en/details/rex012832fypp3n0/graphical-oled-displays/raystar-optronics/rex012832fypp3n00000/ (https://www.tme.eu/en/details/rex012832fypp3n0/graphical-oled-displays/raystar-optronics/rex012832fypp3n00000/)
sky blue https://www.tme.eu/en/details/rex012832fspp3n0/graphical-oled-displays/raystar-optronics/rex012832fspp3n00000/ (https://www.tme.eu/en/details/rex012832fspp3n0/graphical-oled-displays/raystar-optronics/rex012832fspp3n00000/)
white https://www.tme.eu/en/details/rex012832fwpp3n0/graphical-oled-displays/raystar-optronics/rex012832fwpp3n00000/ (https://www.tme.eu/en/details/rex012832fwpp3n0/graphical-oled-displays/raystar-optronics/rex012832fwpp3n00000/)
Both use same controller, and serial communication
lcd (no controller, plain glass)
3.1$ @ 1 , 2.6$ @ 10, 2.12@42: https://www.tme.eu/en/details/de124-rs-20_7.5-3/lcd-digital-displays/display-elektronik/de-124-rs-20-7-5-3-volt/ (https://www.tme.eu/en/details/de124-rs-20_7.5-3/lcd-digital-displays/display-elektronik/de-124-rs-20-7-5-3-volt/)
seven segment 8 digits
Dimensions 37.99x20.29x1.1mm
Window dimensions (H x W) 34.1x11.63mm
$ 3.60 @ 10 , $ 2.80 @ 10 : https://www.tme.eu/en/details/de188-ru-30_7.5-3/lcd-digital-displays/display-elektronik/de-188-ru-30-7-5-v-3-volt/ (https://www.tme.eu/en/details/de188-ru-30_7.5-3/lcd-digital-displays/display-elektronik/de-188-ru-30-7-5-v-3-volt/)
seven segment 8 digits
Dimensions 34.9x13x1.1mm
Window dimensions (H x W) 31.9x6mm
-
Thanks for all the inputs. I was able to get the I2C based OLED display to work with the FTDI with the whole refresh of the screen taking well below 100ms. That's good enough to refresh once every 1 second.
Some more updates on the design. Got my first prototype built and the performance looks within expectations. Will post some results soon. If anyone volunteers to test an initial build, I would be happy to send it across at shipping costs. Please message me. Limited to just 2 units now.
To summarize what it is.
It is a USB based power supply, power profiler and energy meter to test IOT products (For developers). Similar to Otii Arc but with enhanced performance.
> It can provide a programmable output voltage between 0 to 6V to the product under test. Programmable in 5mV steps.
> Output current limited to 2A. Output short circuit protection.
> The current measurement range extends from 100nA to 1A in both directions. The expected accuracy is better than 1% +/- 100nA across the range.
> Sampling rate for the current is 1Msps with a rise time of < 2uS (10-90%).
> Recording length of few hours. Tested for at least 24 hours without any errors.
> OLED display to indicate output voltage, average current and other status information.
> Digital logic capture in sync with the current.(within 1us)
> USB 2.0 B type jack.
> Powered by external adapter 15V, 3A.
-
Hi EEEnthusiast
This is propably a bit late reply, but have you considered using a two dollar ESP32 Wroom module?
It has built in WiFi and BLE including the antenna.
It's got two 12 bit ADC's with 18 analog input channels.
Regarding processing power I don't know your algorithm, but it's got three 32bit cores:
- One is a slow low power core for simple house keeping including ADC sampling and simple I/O.
- The two others are 240MHz cores with individual floating point units and zero overhead looping & subroutine preserve/restore (rotating register window).
One of them could be used for WiFi and other communication while the other could do the compression?
I don't know if it has the power to do your compression algorithm?, but it does pack a serious punch compared to other two dollar micros and it would provide isolation.
I'm interested in purchasing a product like this.
Best regards
Soren
-
Soren
Thanks for the inputs..
I did not consider a Wireless link as it does not guarantee a sustained throughput.
Writing embedded code is much more difficult than writing it on a desktop, with its large computing power. So I just stick with the signal processing on the PC for now.
The hardware will just do the data capture and stream it in raw format to the PC.
I am planning to launch it on CrowdSupply
https://www.crowdsupply.com/zscircuits/zs1100a-power-meter (https://www.crowdsupply.com/zscircuits/zs1100a-power-meter)
The campaign is not yet launched. Should be live in a couple of days...
-
Fellow Geeks,
The CrowdSupply campaign is live now.
https://www.crowdsupply.com/zscircuits/zs1100a-power-meter (https://www.crowdsupply.com/zscircuits/zs1100a-power-meter)
-
Just an update....
The IOT Power meter is in production now and meets most of the design goals.
I thank you for all your inputs and feedback.
The hardware is open source and the design files are available in the link below
https://github.com/zscircuits/zs1100a
Any review or criticism is most welcome..
-
meets most of the design goals
Can you clarify this statement a little?
I'm not too concerned by it not being perfect, as it would never get finished - but it is important to know of any major shortcomings compared to the published specs.
I already have a Joulescope, so I expect there will be pros/cons to each.
Looking forward to getting my unit once Crowd Supply get their act together. Thanks for publishing the docs etc on github, I will take a detailed look later.
-
The deviations are from the specs I had posted on EEVBlog. The ones on the CrowdSupply page are being met
The few deviations are
1. Output voltage is programmable in 10mV steps and not 5mV steps.
2. Current measurement accuracy is now 1% +/- 0.2uA as against my original target of 1% +/- 0.1uA
Some enhancements added are
1. Programmable current limiting
2. Programmable output resistance
3. Over voltage protection and reverse current limiting