EEZ Bench Box 3 (BB3)

[prasimix]

I've started to test a first prototype of "aux" power module based on LT3763 as announced in #86. I've managed to put two channels that could deliver 0-20 V up to 4 A each, and has output voltage and current control. It also comes with on-board MCU for few reasons:

• It will help us to define DIB protocol between master MCU and peripheral module with its own MCU
• The selected STM32F373 comes with multichannel 16-bit ADC for very attractive price that is below "standalone" 4-ch ADCs with the same resolution
• It should be cost attractive alternative to DCP405 module, when more power outputs are required on the bench: up to six channels with BB3 chassis.

The module name is DCM220, built on a 2-layer PCB. All selected components, as usual, are with exposed pins that I can solder it without need for stencil and reflow oven. OK, such requirement narrows the list of possible components, and perhaps more attractive controller then LT3763 exists on the market. Anyway, so far I'm satisfied with preliminary results made by testing only first channel. The first PCB prototype (r1B1) asked for some improvements, and it now doesn't look so nice (see below) but it will do the job.



The schematics follows below and your comments are welcomed.

Bias power supply and DIB interface



DC power input is +48 V that comes from Mean Well AC/DC module (max. 155 W), the same one used to powering the DCP405 module. TPS54060DGQ (IC2) is used as step-down converter which power inductor is replaced with coupled inductor that provide both positive and negative voltage. The negative one is used solely for diff. op-amp used for set output current. Since it cannot provide (RRO) rail-to-rail output, it is not possible to goes down to zero without slightly negative power rail. Firstly, I was thinking about deploying LM7705 but it's unnecessary expensive (with all that needed capacitors around it). Buck positive output is step-down once again with LDO (IC5) to provide +3.3 V for MCU, DAC and digital isolators.
Although power channels on this modules are not isolated (i.e. share the same Vout-), I've decide to isolate it from the MCU GND, to provide more flexibility to combine its outputs with other modules. Therefore DIB interface used for communication with the MCU board has to be isolated. A low speed variant (1 Mbit/s instead of 150Mbit/s) of IC1 and IC3 is selected that I believe will be sufficient for responsive communication. Module parameters are stored into I2C EEPROM (IC4).

DAC, temp. sensors and MCU



I have (and still have) some doubts what is the most efficient way of controlling power buck controllers voltage and current: dedicated 4-ch DAC, MCU's built-in DAC and PWM output or combination of both (e.g. 2-ch external DAC, and 2-ch MCU DAC or PWM outputs). In the first prototype MAX5715 is used, a 4-ch, 12-bit I2C DAC with pretty good price. The good thing about selected DAC is that 8- and 10-bit variants are also available that give us possibility to scale it down reducing the cost further.
It is already mention what was the idea behind selecting STM32F373 as on-board MCU: its 16-bit (SAR) ADCs. ADC inputs are used to monitor output voltage and current on both channel. To keep cost low, I've marked xtal as an option, since MCU could use internal resonator, which is not so accurate as external xtal but should do the job. We have to test that in practice. MCU flash programming is intended to be accomplish over JTAG/SWD connector, but afterward I decide to add possibility to use UART. That will require control of BOOT0 input and UART lines are also added into the latest revision of BP3C backplane (r3B1).

Power channel #1



Design of the power channel is based on the typical application of the selected LT3763 which is high voltage sync buck controller that features current monitoring and control among many other things. It is powered from bias power supply to reduce its dissipation as in case that it is supplied directly from DC power input (+48 V). The +8 V that comes from bias supply is slightly above min. Vin that is +6 V. In fact, I didn't test that yet due to inconvenient tracing on the existing PCB but that is now included in the r1B2 revision.
As current control CTRL1 input is used that accept 0 to 1.5 V for current limit programming. Since DAC output goes up to 2.5 V its output is attenuated using the diff. op-amp IC9B that full DAC scale can be used. Max. output current is defined with Rsense (R27) that generate 50 mV drop for max. output current. With selected 12 mOhm that is about 4 A. Selected switching MOSFETs are IRFR7546TRPBF with low R(ds, on) and V(ds, max) of 60 V. The lo-side MOSFET could be assisted with diode (D4) that is marked as optional but I'm using SK55 on the prototype and have to test if it will stay or not. To further reduce output ripple and noise an additional LC filtering is added (L3, C52+C56) and I have to test how it affect transient response.
Voltage is programmed by bringing another DAC channel output to the FB voltage divider (R33, R39) via R41 that are calculated to give 0 to about 20 V on the output. Output voltage is monitored by bringing it to the MCU's ADC input using the separate voltage divider (R34, R40) that gives +2.5 V for max. output voltage.
The main obstacle with LT3763 is that no CC mode of operation indication is available. Therefore I tried to derived it from CV mode of operation when voltage on the FB input pin is constant and should be about 1.2 V. Op-amp IC11B works as comparator that compares ref. voltage that divider R43, R44 set to 1.119 V just a little bit bellow mentioned CV mode voltage. First I forgot to isolate FB from the op-amp but IC11C is added later that FB pin is not affected with connected comparator. No resistor is needed on the input of IC11C since selected MC33274ADR2G has not input diodes.
Comparator's output is used as CC indicator that goes to MCU and that can indirectly set on and off CC_LED. CV mode indication does not exist per se and OE (output enable) is used instead. To avoid simultaneous activation of CC and OE LEDs, Q4 disable OE_LED (green) when CC_LED is active. Ok, other possibility is to drive OE_LED as in case of CC_LED directly from MCU, a change that I'll probably add, since four pins remain unassigned on the MCU.
Finally, the power Vout- is exposed that can be coupled under firmware control with other module's grounds using only the half of DIB power sourcing connector (X4).

Power channel #2



Nothing more can be said about second power channel that is identical to the first one.
Module's latest design files are now available on the GitHub as part of the BB3 project, and PDF schematic of the presented r1B2 is also attached here for the download.

[AlanS]

Well the Crowd Supply news is out. I must say I'm looking forward to this as I did with the H24005.

I wonder what the priority of additional plug-in modules is? Higher voltages, Electronic Load.

Will there be a minimum configuration? Blanking panels?

Keep up the good work - and the outstanding documentation!

[prasimix]

I'd like to supplement BB3 over the time in a way that it became a useful "benchtop station" for testing low power (up to 400-500 W) AC/DC and DC/DC converters. Therefore, a high voltage DC power source module with all protections is needed (For DC/DC converters, 40 V / 10 A or 80 V / 5 A should be sufficient for a time being).

Other one is power analyzer that could simultaneously measure DUT (i.e. DC/DC converter) input and output power and calculate all power related figures in real time. The electronic load looks like another important module for such purposes but, as time pass, I'm thinking more about 2-quadrant (bidirectional) power source that can return power back to AC mains. In that way "sinking" few hundreds of W shouldn't be an issue.
Another interesting function is a Bode plotter, entry level network analyzer, that should help to finding out in practice what is a stability of the DUT. That functionality perhaps could be included on the power analyzer module.

That type of applications probably will require introduction of FPGA, and I've started to follow ULX3S project, and hopefully with help of some other good-willing people we'll succeed.

Finally, we have to see what time will brings to us, and perhaps some other people will find this "form factor" and accompanied (I believe not non-sense) software/firmware suite attractive for their needs, that we can work together to brings new modules to general public.

[timgiles]

Great  job Prasimix. Ive been following along and not had much chance to comment but its really exciting to see the move from a single product to a modular platform :-)

[jbb]

Great to see you're gearing up for a release! I'm going to keep an eye out.

I have a question on the dual output module... just to clarify, will the two outputs share a common ground?

[prasimix]

Great to see you're gearing up for a release! I'm going to keep an eye out.

I have a question on the dual output module... just to clarify, will the two outputs share a common ground?

That's right, since they also share the same power input (48 Vdc). For more details you can check the latest version of the DCM220 module on the GitHub here (where is also PDF version or in #100). I believe that is not a great obstacle. And yes, it's floating in regards to other power modules, but if needed, its ground can be connected to other grounds under firmware control (e.g. that you don't have to do that with extra wires from the outside what I found myself to do so many times with H24005 ).

[AlanS]

I wonder if having a module to control an environmental factor (like temperature) would be attractive to others as well to as me? For example, one module could be measuring performance of a DUT, while another is ramping temperature up and down.

[prasimix]

What kind of functionalities you have in mind? Perhaps we can combine more then one thing on the single module: e.g. if we are concern about temperature, we could have one or more temp sensor inputs with ADC, PID, also few digital inputs/outputs for triggering, control of heaters (AC or DC relays, triac/dimmer)?

[AlanS]

What I had in mind was the ability to combine a series of environmental tests with a DUT's parametric tests.

Example:
   Whilst stepping up and down supply voltage on a DUT, measure supply current for say x hours, or y cycles
   Once x or y have completed, step say temperature over a range z
   Complete all cycles until you get back to the original values for x,y,z and see if the DUT performs the same

Another example could be monitoring the same data as above - but the environmental changes are the frequency and magnitude of physical vibration. The issue is one of tying the DUT's performance to the environmental condition and having a common timestamp supplied by your CPU and fed to the memory card.

I suppose it's a crude data acquisition system - but the basics will all be there. A common time stamp for stored data, parametric measurement and environmental control in cycles. It reduces the effort made for field testing of devices likely to be subjected to harsh environments.

I'm keen on your Bode plotter too.

[prasimix]

Good, described "testing automation" is already in place to the great extent if we are talking strictly about DC power source (PSU) functionality: we can continuously measuring all output params (voltage, current and power, energy counter will be also added), and have a great flexibility to program (change) output parameters via SCPI commands (e.g. you can also execute LIST of parameters, initiate data logging into internal SDcard and conveniently transfer it to the PC thanks to EEZ Studio). Currently, output params changes could be synchronized with external processes via two buffered digital inputs and two outputs.
But, we have all freedom to build a new module where we can "integrate" some of external devices functionalities (to clean up benchtop a little bit ). Especially because we can include its management to the existing "SCPI engine" on the BB3 chasis side, that could simplify user interactions locally (via TFT touchscreen+encoder) or remotely (via PC).
I presume that making an general purpose multi-channel data acquisition module should make sense. Perhaps with few outputs (for signaling, but also for power control). The module front panel is big enough that reasonable number of I/O terminals can be exposed on it.

[AlanS]

I can see your creative juices flowing. Thank you for enabling the input.

[prasimix]

Yes, and I do believe that existing H24005 and especially new BB3 project has a real potential to be used in testing automation processes saving time and money at least for various entry level tasks. Thanks for initiate such discussion and looking forward also for more inputs from you and other forum members.

[mrpackethead]

Looking forward to this.

[prasimix]

Yes, and first thing first. I have to make BB3 happen (initiated with crowdfunding): to organize everything that its production can started and can be delivered smoothly that more people could get it for development and evaluation purposes, too (apart from use its existing modules for daily power delivering requirements on our benchtops ).

[Rerouter]

I'm definatly on the hope for an SMU type plugin, And I'm trying to consolidate how it could could be approached, even If it ended up being a 3rd slot module of my own design (As long as the price is not too insane, I should be a first hand backer this time around)

[prasimix]

(As long as the price is not too insane, I should be a first hand backer this time around)

A good thing this time is that, thanks to real modular approach (something that also existed in H24005 project but not executed properly), the "entry-level" solution starts to makes sense, too. It will include BB3 chassis, AUX-PS (+5 V, 10 or 20 W, and +12 V/10W, softstart, fan speed control), MCU board (STM32F7, 4.3" TFT touchscreen, encoder, Ethernet, USB, etc.) and three slot backplane (with power coupling). Any you can start adding new modules, that are not necessarily just single quadrant DC sources.

But, the two-channel kit, comparable with H24005, should be in the same price range with H24005. I'm working on that, and hopefully that will become reality (even that BB3 is more capable).

[jbb]

I wonder if having a module to control an environmental factor (like temperature) would be attractive to others as well to as me?

I'm definatly on the hope for an SMU type plugin...

I think there are a lot of opportunities for modules - that was Prasimixes whole concept  .

For example, I have been doing some battery evaluation stuff at work, and there is a massive gap in the market between the <$500 hobby battery charger (they're quite good but not precision) and the >$10,000 professional battery analysers.  Maybe a BB3 with an SMU card, a Peltier control card, and an external thermal chamber (which could be bolted to the side of the BB3 to make a 19" rack payload) would do the trick?

Possibilities (and idea source):

• Precision power meters (Prasimix)
• Temperature controller (AlanS). A cut-down version could also function as precision RTD thermometer or strain gauge receiver
• SMU (Rerouter)
• Multi-channel data acquisition card (HP, Keithley et al)
• Precision battery cycler (me)
• Bidirectional DC supplies (me) for loop-back power testing
• Tiny thermal chamber inside a card (me) for component and small battery characterisation
• Battery backup module (behind LCD) for reliability or in-field usage (me).  This would make power supplies and shipping very complicated.

There are heaps of things people could build...

[neslekkim]

It is important to mention that most manufacturers offers the same TFT displays with both resistive and capacitive touchscreen. Currently we are using resistive that is only supported by selected TSC2007 controller.

Capacitive would be nice I would guess, resistive touch seems to stop working/malfunctioning after some time.

[mrpackethead]

I'm guessing it would be possible to create custom modules if you so desired given its modular form factor.

Something i'd like to do, would be a POE PSE port, as i do a lot of Powered devices.  It would be handy to be able to measure/control the PSE end.

[LapTop006]

Something i'd like to do, would be a POE PSE port, as i do a lot of Powered devices.  It would be handy to be able to measure/control the PSE end.

Oh that's a cute idea, I love that. Ability to source 30-55v (to simulate cable drops), reporting of what class the device asks for.

[prasimix]

For example, I have been doing some battery evaluation stuff at work, and there is a massive gap in the market between the <$500 hobby battery charger (they're quite good but not precision) and the >$10,000 professional battery analysers.  Maybe a BB3 with an SMU card, a Peltier control card, and an external thermal chamber (which could be bolted to the side of the BB3 to make a 19" rack payload) would do the trick?

Could you please elaborate this a little bit more. What thermal chamber and Peltier elements are used for? To test battery behavior under different temperature? I presume then that Peltier control card should include multiple thermocouple sensor inputs that will be used to set output for powering Peltiers?

Possibilities (and idea source):

• Precision power meters (Prasimix)
• Temperature controller (AlanS). A cut-down version could also function as precision RTD thermometer or strain gauge receiver
• SMU (Rerouter)
• Multi-channel data acquisition card (HP, Keithley et al)
• Precision battery cycler (me)
• Bidirectional DC supplies (me) for loop-back power testing
• Tiny thermal chamber inside a card (me) for component and small battery characterisation
• Battery backup module (behind LCD) for reliability or in-field usage (me).  This would make power supplies and shipping very complicated.

There are heaps of things people could build...

Yes, and all that is mentioned could be integrated and benefit from the "software suite" that is already in place: to manage modules locally (TFT touchscreen + encoder) or remotely (via SCPI commands to EEZ Studio or similar application).

[prasimix]

I'm guessing it would be possible to create custom modules if you so desired given its modular form factor.

Something i'd like to do, would be a POE PSE port, as i do a lot of Powered devices.  It would be handy to be able to measure/control the PSE end.

Ok, but I don't known anything about PSE port. Do you have any useful links to some intro/beginners content?

[ogden]

I'm guessing it would be possible to create custom modules if you so desired given its modular form factor.

Something i'd like to do, would be a POE PSE port, as i do a lot of Powered devices.  It would be handy to be able to measure/control the PSE end.

Ok, but I don't known anything about PSE port. Do you have any useful links to some intro/beginners content?

I am not sure why PoE needs to be integrated into power supply because there are different kinds of power PoE sourcing (standards) and to cover them all, provide all features needed for testing of PoE devices, module needs to be quite complex thus expensive. Those who are ready pay significant money most likely will buy something from SiFos (or similar) anyway.

If you are going to implement PoE module, more or less it shall contain main components of this board:
http://www.ti.com/tool/tps2372-4evm-006

[edit] If it is about popular < 30W Type2 PoE, then this much simpler board a module: http://www.ti.com/tool/tida-00465

[jbb]

Could you please elaborate this a little bit more. What thermal chamber and Peltier elements are used for? To test battery behavior under different temperature? I presume then that Peltier control card should include multiple thermocouple sensor inputs that will be used to set output for powering Peltiers?

Yes, for precision work it’s common for people to test at different temperatures, eg 0C, 20C and 40C. This is because cell Open Circuit Voltage is a bit temperature sensitive and cell resistance is very sensitive to temperature and state of charge.

(I’ve also found that stable control of the cell voltage and current is important. A bit of voltage ripple can make quite a big difference to when exactly the cell is “fully charged,” which leads to a random spread of capacity measurements. To get around that you then need to average more test cycles and everything takes longer...)

For a small cell, a small thermal chamber could probably be done with Peltier elements. Both heating and cooling modes would be required, which suits a Peltier well. I guess that a ‘proper’ setup would have 2 basic sensors on the Peltier elements for protection and coarse control, and at least one more precise (eg RTD) sensor for the chamber temperature. Ideally I would tape 1 more sensor to the cell itself for a grand total of 4. (But what if I want to test several cells at a time ?)

My idea of a tiny thermal chamber which bolts on the side of a BB3 is cute but probably impractical.

[AlanS]

I like this idea (jbb) of being able to control a peltier based chamber from within the BB3.

When not being used for important stuff we could use it to keep our wine in good condition (I'm joking).