Arduino Shield for programmable DIY bench power supply with SCPI support

[prasimix]

Hi everyone,

This is my first post in which I'd like to present an Arduino Shield designed for controlling dual channel DIY bench power supply.
My colleague and I are working on it for some time to provide all hardware and software functionality that we hope could be beneficial to anyone who'd like to follow our power supply design or use it with their own.

History
A whole thing starts as just an another attempt to build bench power supply, an essential tool for experimenting and prototyping.
Idea was to build something in between commercial "heavy weights" that comes from brands such as Keysight (ex. Agilent, ex. HP) or Keithley and many others (that recently starts to got Chinese counterparts like Rigol or Siglent) and DIY projects based frequently about small MCU that indeed include some of Arduino boards and designs. The gap between mentioned solutions is huge both in hardware and software sense. When we talk about hardware then commercial solutions leads in e.g. power capacity, long term precision and reliability. On the software side at least one feature is distinctive and comes almost without exception with commercial powers supplies: that is remote control/programming and monitoring based on SCPI command set that use IEEE488, Ethernet or USB as communication layer.
DIY projects that uses MCU for digital control is mostly based around low-end MCU what sounds logical since there is no big deal in setting voltage and current and read it back. 4x4 keypad or incremental encoder as an input and two line LCD display on the output and that’s all you need especially when there is readily available code when one decide to use Arduino sketches.
Following that logic our first attempt was to use Atmel ATmega32U4 that is in the core of the now retired Leonardo board. We enrich it with few things that lacking such as external EEPROM for more capacity, RTC and Ethernet controller. We started building power supply firmware and relalize very soon that 32K (-4K) of flash memory is far too low. Just adding Ethernet library was enough to exceed mentioned limit. Yes, most of DIY power supply do not utilize Ethernet since USB is on the disposal and therefore why to use it? But USB cable length cannot be compared with Ethernet one.

Arduino Shield
That was a moment for redesigning everything. Instead of adding more capable MCU to a new digital control PCB we made decision to build an Arduino Shield. In that time only two boards fit in our requirement for (much) more memory: Mega2560 and Due. Their form-factor dictated the size of the new board, together with enclosure that was chosen previously that we found affordable and of nice quality that comes from Hi-fi 2000/Modushop.biz.
Hopefully Arduino will continue to offer mentioned and new boards using the same form factor (even newcomers such as Zero or MKR1000 does not support that claim).
When decision about form factor was made, another was about supporting architecture because Mega and Due comes from different clans: 8-bit AVR and 32-bit ARM that is programming-wise made transparent thanks to the Arduino IDE but on the hardware levels require different supply and logical level voltages: 5V and 3.3V. That decision simplify existence of really versatile Texas Instruments bus transceiver: SN74LVCC3245. Now we could continue with development taking into account some already used features that such digital control board should have.

Feature overview

• Outputs and remote sense inputs protection using TVSs, MOVs and SAR
• LED indications for output enable, remote sense and Stand-by mode
• Power relays for making serial or parallel connection of two outputs
• Signal relays for remote or local voltage sense
• Connectors for hosting Arduino Mega/Due board
• On-board 3.3V/1A LDO powering all peripherals
• Analog input for temperature sensor
• Soft-start/Stand-by control for the Auxiliary power supply module
• Level shifters for 3.3V ↔ 5V (3.3V ↔ 3.3V is also supported)
• Digital isolators for two SPI-bus/port for output channels control (power supply’s post-regulator module)
• Buzzer
• External EEPROM
• Real-time clock (RTC) with supercap back-up
• Ethernet controller
• TFT color display with touch-screen
• LED CV/CC mode indicators
• Optional V/F (Voltage-to-Frequency) converters for isolated temperature sensors (NTCs) that can be used for battery temperature monitoring

Few pictures

Rear side without Arduino board

Read side with Arduino board plugged in

Front side with binding posts mounted

In the few posts that follows I’ll present in more details hardware and software aspects of this shield and some plans for the future changes and improvements.

[prasimix]

Let’s continue with schematic. It is organized in five sheets and I’ll describe it as it appears in Eagle files that could be found on the GitHub.

Binding posts section
This section is added to simplify wiring of power outputs, remote sense inputs and serial and parallel connection of two channels without external wires. The is another maybe not so obvious advantage of such wiring: it does not leave a room for erroneous wiring and programming, e.g. that polarity are mismatched or that channels connected in parallel are programmed with different output voltages.
Output terminals and remote sense input terminals are protected against reverse polarity and over-voltage spikes using TVS (ZD1 – ZD4), MOV (VR1 – VR8) and SAR (SAR1, SAR2) components.

Serial connection is established through power relay K_SER while for parallel connection the K_PAR power relay is used. Both relays is rated for 8A and should withstand 50VDC switching without load connected. When driving serial or parallel relay the following things has to be taken into consideration:
Voltage and current has to be set to zero before channels are connected or disconnected. The easiest way to do that is to disable output (OE is off) but it's also recommended to also program output values to zero.
Parallel connection could follows only if programmed output voltages are the same on both channels
Optionally down-programmer circuit could be disconnected on one of the channels that are connected in parallel
Mentioned recommendations should be taken seriously otherwise it is possible to damage either the PSU and/or connected load. For example when we tested outputs connection in serial with connected load and OE was switched on when total voltage became higher then 60V, the K_SER relay was irreparably damaged during disconnection! Contacts were simply melted down and left shorted.
Since separate power relays is used for outputs connection is serial and in parallel it is possible to activate it simultaneously by software. If that case the outputs of the both channels will become shorted that could be dangerous if e.g. over-current protections was not set. To avoid such situation a hardwired blockage is added (the Q4 mosfet) to inhibit parallel power relay (K_PAR) when serial power relay (K_SER) is activated.
Two tiny signal relays (K_S1, K_S2) are used to control voltage sense that could be local or remote. By default (when relay is not polarized) sense inputs are connected locally – to the power outputs. When load is remote and voltage accuracy is critical for the connected load, sense inputs become connected to a separate pair of binding posts.
All relays are controlled by TLC5925 that is a 16-channel constant current LED driver that is intentionally selected because we wants to add a LED indications of biding posts states and makes them in that way more obvious to the user. Therefore one LED is added above each of eight binding posts. When channel’s outputs are enabled a pair of green LEDs are illuminated. Remote sensing is backed with illumination of yellow LEDs. Connection of output channels in serial or parallel is also indicated thanks to bi-color LEDs used above channel one power outputs. In that case LEDs are illuminated in red.
All allowable binding posts connections with LED indications and programming codes that can be used for controlling TLC5926 are listed below.

Arduino board interface
Arduino Mega and Due have seven female headers used for interfacing with I/O pins, power, reset, etc. They are located at the three board sides and we learned that such arrangement is quite impractical when board has to be removed. A close attention is required to not bend one or more pins on the Arduino Sketch side. Interfacing with the Arduino board is done using SN74LVCC3245A as a level shifter. Five (IC2, IC3, IC4, IC5, IC7) are used for pins that will be programmed as digital outputs and an another one (IC8) is used for digital inputs. IC3 and IC5 are handling LCD 16-bit data bus and rest of the outputs controls various “chip selects”, SPI bus output signals (SCLK and MOSI) and similar signals.
Input level shifter (IC8) is passing SPI bus input (MISO) and interrupt requests from the installed peripherals. Pin mapping of all used pins is described in the attached document (PSU Arduino pin mapping r1B12b.pdf).
Main power comes to the pin 5V (MCU_POWER header) that is also applicable in the case of Due since it has on-board LDO to step down to the working 3.3V.

SPI ports isolators
The Arduino Shield has to control two PSU channels that are electrically isolated by default and they have to stay isolated when are connected to the shield. That means that digital control signals cannot share the common ground. If such connection exists it could be even dangerous when e.g. channel outputs are connected in serial or when the PSU is used as a symmetrical source (positive output from one channel is connected to the another channel negative output). Digital channel isolation is accomplished using Silabs high speed digital isolators.

The SPI bus port pin mapping is compatible with the ICSP 10-pin header:

Eight lines in total has to be isolated for each channel and both input and output directions is needed. Six line isolators (IC9, IC12) are used for outputs and two line isolators (IC10, IC11) for input signals. MISO input require special attention. Used isolators are not 3-state what is a requirement for the MISO signal since only one device could send data to the MCU at the time. Lack of 3-state outputs on the isolators is fixed with additional buffer gate (IC10C, IC10D) that can provide 3-state output.

On-board peripherals
The SPI bus used for isolated communication with peripherals that resides on two PSU channels is also used for making connection with few other SPI peripherals located on the shield itself. They are added to “equalize” features on both Arduino board variants. EEPROM (IC15) and RTC (14) are added because Due is lacking former and Mega is lacking later. The RTC is also powered with a 1F Supercap that should be enough for running for a couple of weeks when the main power is not present.
On top of that SPI Ethernet controller (IC16) is added and socket (LCD1) for hosting TFT display. Display controller use parallel 16-bit data bus, but touch screen controller also need SPI.
Few other things that are directly connected to the MCU pins are also included:

• Buzzer driven with digital output (via Q8)
• Temperature sensor connected directly to an ADC input and
• Display back light adjustment driven with PWM output (via Q9)

PSU Arduino pin mapping r1B12b.pdf (460 KB)

[prasimix]

CC/CV indicators and optional temperature sensing
Channel output mode of operation is indicated using two LEDs: Yellow for constant voltage or CV (LED_CV1, LED_CV2) and red for constant current or CC mode (LED_CC1, LED_CC2). Most of the time the channel output will be in one of that two modes. But there is also the third mode that is called unregulated or UR when output is possibly under influence of both CV and CC control loops. This mode is indicated by switching off both LEDs.

Finally the shield contains one optional circuit that could be used for isolated measurement of the outside temperature. That could be a battery NTC sensor used for monitoring battery during fast charging or discharging cycles. Temperature sensor connector (X10, X12) is located near the channel’s binding posts. Its output is analog, a variable resistance that depends of the temperature. It has to be isolated for the same reason that is mentioned for SPI buses: to avoid connection of their grounds to the same potential. Analog isolator circuit is not used here because it’s in general more complex or expensive for the same precision. Therefore the sensor output is first converted to a digital signal by mean of V/F (voltage-to-frequency) conversion using popular 555 timer. For better linearity NTC is not connected directly to the timer but a current mirror circuit is used (IC17, IC19). Timer output signal could be now digitally manipulated. We had two possibility here to forward it to the available Arduino digital pin programmed as input or to connect it to the I/O expander that is located on the post-regulator module and which has few unused digital pins. Advantage of the later over the former is that it does not require additional isolation if the whole V/F converter is also powered from the post-regulator module. We decide to use such type of connection.
Complete idea about monitoring temperature of the connected load is still in the early phase. It remains to be seen how it will works in practice. Eventually it could be replaced with an analog isolator when the analog signal will be forwared to the one of Arduino ADC (analog) inputs.

[prasimix]

A two layer PCB (200 x 105 mm) is used with clearly separated analog (output protections, relays and V/F converters) and digital section. Binding posts (nine of them) can be directly mounted on the PCB from the PCB rear side (that is enclosure front side). The same is valid for all LED indicators (12 mm spacers are used to simplify montage).
The Ethernet RJ-45 jack is also hosted on the PCB. Therefore additional short (30 cm) adapter cable is required to make it reachable from the enclosure rear panel.
The Arduino is positioned in the way that neither part on the shield or Arduino board touch each other.

Arduino Shield for bench power supply PCB layout (both side)

Arduino Shield for bench power supply PCB layout (top layer)

Arduino Shield for bench power supply PCB layout (bottom layer)

[prasimix]

This shield could be further developed in various ways. Here is some ideas that should be feasible within existing PCB dimensions:

• Add support for more output channels; at least one to have under control some kind of “aux” low voltage/high current output e.g. 0-8V/0-5A
• Add automatic recognition of board using Arduino IOREF pin (jumper JP2 could stay on the PCB if one don’t want to solder components required for IOREF monitoring)
• Replace or complement the Ethernet with wireless (e.g. module such as Microchip's MRF24WG0M)
• Add two more signal relays to cover remote sensing case when two channels are connected in serial
• Rearrange binding posts to have in one row power outputs and in another remote sense inputs that uses much smaller connectors
• Somehow combine LED indicators from the BP section with CC/CV indicators
• Dedicate more inputs for NTC temperature sensors
• Add digitally isolated inputs for external triggering
• Add digitally isolated outputs for e.g. relays control
• Add isolated and clamped analog input (i.e. 0-2.5V) for direct control of output voltage or current. That can be used in scenario when e.g. the channel output acts as an pre-regulator that track output voltage of the connected D.U.T.

The shield could be sized down both physically and “logically/electrically” when budget is tighter. If smaller PCB is required a complete BP section that contains output protections and convenient connection between two channels without extra wires could be removed and cut PCB size in half. “Electrical” reduction will decrease circuit complexity and parts count. That can be done by removing support for the Mega board when all level shifting logic (IC2, IC3, IC4, IC5, IC7 and IC8) are not needed anymore.

Finally, such shield could host complete power part i.e. pre-regulator and post-regulator. One idea is to use SMPS pre-regulator based on TI's TPS54560 that in theory (or with massive air flow) could deliver up to 5A and withstand up to 60V on the input. It requires minimum additional parts for functional solution. As an post-regulator we are thinking about power operational amplifier OPA548 (TI again, actually ex. Burr-Brown) that can provide continuously 3A and withstand up to 60V and requires few parts for functional solution. I think that is reasonable to expect 0-30V/0-3A range with mentioned combination.
Also, with such approach and if precision/resolution is not critical it's possible to deploy ADC and DAC/PWM built in MCU on the Arduino board.

[prasimix]

Please find below few pictures of the shield mounted in the power supply enclosure that is almost finished (only acrylic front panel mask is missing that I'm going to order from the service such as formulor.de) ...

[prasimix]

Firmware for this shield is an Arduino sketch that can be without limitation run on both Mega and Due boards. In addition to that we also made a software simulator and thanks to that one can test all currently implemented functionality on e.g. Windows, Linux or OS X. Precompiled version for Windows and instruction how to compile it on Linux and OS X are available here, but I'd like to suggest to read this post to the end before doing it.

The firmware is still under development and the first milestone is reached recently. That release is called M1 (from Milestone one) and is also available on the GitHub. It comes with SCPI commands that allows remote control of most power supply functionality (a whole list is presented in Section 12 of the SCPI reference guide). Communication is possible using USB port that resides on Arduino board or over Ethernet that is included on the shield. Actually, currently is possible to simultaneously use both of them but in the future when local user interface is enabled it will be possible to switch between local or one remote interface at the time.
The good thing about SCPI commands is when you become familiar with them you can used it with almost any high-class instruments that comes from names such as Keysight, Keithley, Rohde & Schwarz, etc. Also SCPI controllers

Set basic power supply's parameters
Supported SCPI commands are listed and described in more details in SCPI reference guide which exists in PDF/ODT and online form. SCPI commands are text-based and it can be send using serial terminal or telnet session. For example, if we want to set voltage to 10V and max. current to 150mA on the currently selected channel one has to type in the following commands:

VOLTage 10
CURRent 150ma

SCPI commands are not case sensitive, and mix of upper and lower cases is intentional and it's regularly used to make distinction between allowed shorter and longer command format. Therefore the following commands will have the same effects:

volt 10
curr 150ma

When voltage and current are programmed it remains only to enable output what can be done using any of the following command on the first channel:

OUTPut, CH1 ON
outp on
outp 1

If we want to do something on the second channel we have to use INSTrument command to select it, since according to SCPI nomenclature each power supply channel represent one instrument. The following example sets 40V, 2A and enable output of the second channel:

inst ch2
volt 40
curr 2
outp 1

VOLTage and CURRent actually belongs to SOURce command subset but since the power supply is by default sourcing device that command is not mandatory but it could be useful since it allows selection of instrument. Therefore if we want to program channel two voltage to 3.3V without changing selected channel we can use the following:

sour2:volt 3.3

Both VOLTage and CURRent could be also use for query currently programmed values. For that question mark (?) is used:

volt?
10.00

Command that is not (yet) included in the SCPI standard but is widely available is APPLy. It can be used for quick programming of both voltage and current on the channel of choice. If we want to programm 12V and 600mA on the first channel we can simply type:

appl ch1, 12, 0.6

The same command is also query command, therefore it can be used to find out currently programmed values, but also allowed ranges. For example:

appl? ch1

could return:

CH1:40.00 V/5.00 A, 12.00, 0.60

Where 40V is max. voltage and 5A max. current that can be programmed on the channel. In this post I'd like to mention just one (two) functionality that is already supported in M1 firmware that can be useful: over-voltage (OVP) and over-current protection (OCP).

The current PSU design do not include dedicated OVP and OCP circuits. Therefore voltage and current protection is implemented by monitoring programmed output values (VOLTage and CURRent) and mode of operation (CV or CC) combined with delay time required for "tripping". For example if we'd like to activate over-current protection what has to trip after 50ms we'll monitor the moment when channel changes from CV to CC mode of operation. If channel stays in that mode for more then mentioned 50ms the output will be turned off (OUTPut OFF) and we'll have indication that OCP was tripped.

Over-voltage protection (OVP)
the following SCPI commands for over-voltage protections is now supported:

[SOURce[<n>]]:VOLTage:PROTection:STATe
[SOURce[<n>]]:VOLTage:PROTection:DELay
[SOURce[<n>]]:VOLTage:PROTection:TRIPped?

The first one is used for enabling OVP, the second one for defining required time delay before OVP will "tripped" and the last one can be used to check if OVP is tripped. Again, since we don't have dedicated OVP circuit we cannot define level higher then that is programmed with VOLTage command. I don't know if make any sense to eventualy provide OVP voltage level setting that is below programmed voltage. If such case exists please let me know and we can add appropriate command that is [SOURce[]]:VOLTage:PROTection:LEVel .
Activating such protection before connecting load does not make sense because it will trip immediately after programmed DELay expire. For example we will set output voltage to 25V and current to 1A that is low enough that with connected load channel will immediately enters CC mode of operation. If load resistance is increased or loaf is disconnected that voltage reach programmed 25V for more then 50ms, the OVP will trip:

volt 25
volt:prot:stat on
volt:prot:del 50ms
outp on

The channel output will looks like this:

We can check output and OVP function state using the following sequence:

outp?
0
volt:prot:trip?
1

If OVP or any other protection was activated (tripped), it is not possible to turn on channel output before clearing "trip" state. We can see that in the following example when OUTPut ON attempts will generate an error that is queried with the SYSTem:ERRor[:NEXT]? command:

outp on
outp?
0
syst:err?
201,"Cannot execute before clearing protection"

Trip reset of OVP but also OCP and OPP (over-power protection) require execution of the following command:

OUTPut:PROTection:CLEar

The following sequence shows that channel output successfully is activated again when it is executed:

outp:prot:cle
outp on
outp?
1

Over-current protection (OCP)
Command set for over-current protection is similar to that for OVP and the working principle is the similar:

[SOURce[<n>]]:CURRent:PROTection:STATe
[SOURce[<n>]]:CURRent:PROTection:DELay
[SOURce[<n>]]:CURRent:PROTection:TRIPped?

In this case the output current programmed by the CURRent command and change of operation mode to the CV mode is used as a trigger. If such condition exists on the channel for more then a programmed delay the OCP will "trip". During OCP initialization it is not necessary to have load connected, and if it's connected it has to be low enough that channel remain in the CV mode of operation. Here is an example how to initiate OCP on 1A with 5ms delay:

curr 1
curr:prot:stat on
curr:prot:del 5ms
outp on

OCP trip will cause the following changes on the channel output:

The following command sequence can be used to check OCP activation, clear/reset protection and make output active once again:

curr:prot:trip?
1
outp?
0
outp:prot:cle
outp on
outp?
1

Software simulator
All above mentioned actions require live harware: Ardino shield and other modules. But you don't need to build a whole system to test how SCPI is working thanks to software simulator. It is currently a command line application that when started looks like this:

It can be used directly to enter SCPI commands and get query results or you can also test remote access with telnet session on the port 5025:

[polymorph]

Very impressive! Thanks for posting this.

[prasimix]

I want to thanks to everyone who were already downloaded the M1 firmware and invite all other to try it and post here comments and suggestions.

Firmware in version M1 still do not allows that some of the PSU parameters can be set and read using the SCPI commands nor using the local console that is not supported at all in this version. That issue is addressed to some extent by using few configuration files with parameters that could be altered during the compilation time. This post describe the content of the following configuration files:

• conf.h
• conf_advanced.h
• conf_channel.h
• conf_user.h
  We would not like to recommend changing any of the parameters defined in the first three of above mentioned files. Instead of that conf_user.h should be used to override existing values with a new one.
  conf.h
  Basic firmware parameters are defined in conf.h. That includes definition of SPI peripherals installed on Arduino shield board but also used channel’s types defined with their programmable voltage and current ranges. The over-temperature protection (OTP) default values for the MAIN sensor are also defined here.
  The SERIAL_SPEED is the only parameter that is used for serial communication configuration. Default is 9600 baud and it can be changed to any of the following speed: 300, 1200, 2400, 4800, 19200, 38400, 57600, 74880, 115200, 230400 or 250000.

conf_advanced.h
This header file contains most of the parameters that are used for firmware configuration. That also includes the power supply’s identification used in *IDN? query (PSU_SERIAL, MANUFACTURER and FIRMWARE), DAC and ADC parameters, calibration parameters and over-temperature protection (OTP) values.
SCPI parser input buffer length (SCPI_PARSER_INPUT_BUFFER_LENGTH) is by default set to 48 and it can be increased to e.g. up to 255 but please note that will consume twice as much SRAM memory with each increment because two buffers was implemented: one for serial and one for Ethernet communication. That can generate problem during compilation on Arduino Mega in first place because it has only 8 Kb of SRAM.
The following three constants requires additional attention:

• CONF_WAIT_SERIAL – defines does serial communication is required to start firmware execution. It’s disabled by default. Keep in mind that if you enable it then nothing will happened when power is switched on without USB cable connected and a serial console (e.g. Arduino Serial Monitor) is up and running.
• CONF_DEBUG – determines if additional debug messages will be send to the serial console as an assistance in the development process since no real-time debugger is available in Arduino IDE. All debug messages started with ** and some examples are shown on picture below. This constant that is currently enabled by default could be disabled to decrease compiled sketch size.
• CONF_DEBUG_LATEST – represents additional condition for generating debug messages and it’s usually used as an assistance in debugging code that is recently added when additional reporting is required.

conf_channel.h
Channel specific information such as pin mapping used for each channel is defined in conf_channel.h. Additionaly all possible variations of channel’s capabilities are listed here. Original file contain three voltage ranges (up to 30, 40 and 50 V) and two current ranges (up to 3.12 and 5 A) that has to match capabilities of the post-regulator board for proper operation. If one wants different voltage and current ranges e.g 0 – 25 V or 0 – 2 A it can be done here simply by adding new channel profile following the defined structure.
Together with mentioned voltage and current ranges that are represents with three values (MINimum, DEFault and MAXimum), channel profile contains information about voltage and current STEP change (see [SOURce[]]:VOLTage:STEP](http://"bench-power-supply/psu-scpi-reference-manual/psu-scpi-subsystem-command-reference/psu-scpi-source.html#sour_volt_step") and [SOURce[]]:CURRent:STEP), calibration LEVels (see CALibration:VOLTage:LEVel and CALibration:CURRent:LEVel), OVP and OCP parameters.
Finnaly over-power protection (OPP) profiles are also defined here as a mix of above mentioned voltage and current profiles.

conf_user.h
An example how to override channel’s profiles defined in conf.h is added into conf_user.h:

	#pragma once
	// Example: redefine channels
	/*
	#undef CHANNELS
	#define CHANNELS \
	    CHANNEL(1, CH_PINS_1, CH_PARAMS_50V_3A), \
	    CHANNEL(2, CH_PINS_2, CH_PARAMS_30V_3A)
	*/

Procedure is simple: parameter that we want to change first needs to be undefined (#undef) when a new definition follows using the #define operator.
Above mentioned change can be checked with *IDN? or APPL? query:

*IDN?
EEZ,PSU 1/50/03-1/30/03 (Simulator),123456789,M1

APPL? CH1
CH1:50.00 V/3.12 A, 0.00, 0.00

APPL? CH2
CH1:30.00 V/3.12 A, 0.00, 0.00

[TonyD]

As polymorth, very impressive project +1.

Is this the same project as seen on eevblog?

[prasimix]

Yes, I started it concurrently on EEVblog and diyaudio before and didn't want to bother members of this forum with past mistakes, misunderstandings, death ends, etc. But I'd like to post information about current progress and get your opinions about ideas that we are currently digesting.
I hope that many interesting thing will be ready soon on the software side. On the hardware side it's currently battle in progress how to make a whole thing more modular and simpler and still be capable of running serious chunk of software that we already started to develop using the Arduino IDE. Eventually we will end up with one board that can provide "no-nonsense" power supply functionality and capability that is already achieved. There is many obstacles and here are some of them:

• Which MCU board to use? Here we have to think about availability, price and capacity (e.g. Due looks like a perfect fit but it's now obsolete, or will be soon).
• "Open form" design as many Arduino shields are or enclosured one? Enclosure looks mandatory for stand alone units especially if one wants to go with 50VDC range that is proclaimed dangerous and require safe operation
• What's about connectivity: USB and Ethernet is here but what's about "wireless"? In that case what platform to use and what protocol? Wifi, Bluetooth, ...? What's e.g. about ESP8266 that already got decent support for Arduino IDE?
• Local presentation: we are working on adding support for TFT with touch screen, but do we really need it? Maybe everything could be simply forward to smartphone or PC screen? Does it make sense to have a programmable power supply module that by default require remote console?
• main(s) supply: shall we proceed with using mains transformer or maybe we should add at least as an option DC input from external AC/DC adapter regardless of the type (open/closed frame for internal mounting or as stand alone unit regularly used with notebooks)
  Your input is appreciated.

[prasimix]

We are working on adding support for local console that is in our case 3.2" TFT color display with touch screen. The touch screen functionality is provided using XPT2046 controller and UTouch library is used to communicate with it via Arduino IDE. And it works ... and after next power up is stops to work,... etc.
We spent two days before we finally realized that initiation function UTouch::InitTouch(byte orientation) missing an important first time control byte setup!

So if anyone else currently experience similar erratic behavior it has to add the following code at the end of above mentioned function:

    cbi(P_CS, B_CS);
    // command for reading X position, but only bit 0 and bit 1 are relevant
    // and have to be set to zero (see table 8. in datasheet)!
    touch_WriteData(0x90); 
    sbi(P_CS, B_CS);

The XPT2046 datasheet seems to have also some minor errors so I'm sending a version with my correction in the attachment.

Xptek_XPT2046_datasheet (corrected).pdf (828 KB)

[prasimix]

I spent some time to summarize observations and obstacles found in the latest revision of the hardware part and see to which extent is possible to include it into the next revision. The following things asks for some attention and improvement:

• The power supply (or just PSU) has two channels and their PCBs are mounted on two level using eight 50 mm spacers. Such construction does not allow access to the lower section (channel #2) when everything is assembled and e.g. we are willing to conduct some measurements on that channel.
• Each channel is connected with digital control module (Arduino shield) using 10-wire flat cable (SPI-bus) and 2 x 2-wire cables (power output and remote sense input).
• Each channel (indeed) require dedicated heatsink (two separate or one shared by both channel)
• Both Arduino Mega2560 and Due boards are supported, but Mega’s price/performance looks pathetic in comparison to the Due. Support for Mega costs us 6 level shifters.
• Two different type of digital isolators is used: 2- (input) and 6-channel (output). Such “careless” selection require additional two ‘125 logic buffers (one extra IC)
• Using 4 mm binding posts for remote sense inputs looks attractive and robust but that’s “too bold” and many professional models use much smaller connectors. Additional obstacle is their location in between power output. Therefore no standard 750 mil (19.05 mm) distance between positive and negative posts was provided (that is recommended when e.g. BNC to 4 mm adapter has to be used).
• Software triggering will be added into one of the following firmware releases, but it could be also interesting that some functions are triggered with external signal.
• Similar to the previous one: there is no possibility to perform tracking functionality based on external signal. That is called “remote programming” and it could be helpful to use the PSU as a “smart” pre-regulator during development and testing with all additional features such as current limitation, OVP, OCP and OPP managed by the MCU.
• The enclosure is fully packed: six PCB’s (+ piggybacked Arduino board), big main transformer and two heatsink are mounted outside the box. But still, is it possible to make it smaller with smarter organization and still without using mains voltage “pre-regulation” that can remove huge transformer from the scene?

The quest for the better solution was initiated with rearranging of the PCBs. Once again it’s started with selecting of suitable enclosure that has enough room for not less then two channels. This time an enclosure from the different line of the same manufacturer comes to mind (Galaxy Maggiorato) that comes with 1, 2, 3 or 4U (40 to 165 mm) height. The current enclosure is 115 mm high therefore 3U (120 mm) looks as good replacement. But such dimension is mainly dictated with the size of the Arduino shield PCB (200 x 105 mm) and that is result of vertical placement of the TFT display. Existing PCB is pretty crowded, but with smaller remote sense inputs, removing of 6 level shifters (Mega is out of game, but will be still supported by the firmware for a while), no ‘125 logic IC (better digital isolator’s selection) and minimizing output protection to only TVS (MOV and SAR are going out) we can rotate TFT and lower the PCB’s height below 80 mm. In that way even 2U (80 mm) enclosure starts to be a real candidate for the next revision!
Such reduction in volume (about one third) require new location of channel’s power modules (pre- and post-regulator PCBs). They could be eventually merged into single board but more importantly is to change their form factor that is suitable for mounting them not any more near the rear panel but on the side supports (one channel per each side). Above mentioned enclosure comes with 10 mm aluminium profile that possibly could safely dissipate up to 15 W (per side).
Moving channel’s PCB to the new position remove additional cabling from the picture (10-wire digital, 2 x 2-wire analog). Now we can plug power modules directly to headers located on the opposite ends of the redesigned Arduino Shield (of course here we must take care about rotation of pins because PCB’s are turned “face to face” and we don’t want to end up with “left” and “right” channel PCB variants!). 20-pin connector should be enough to carry all required signal and power lines.
It’s obvious that next revision is not a trivial one. In that case adding more stuff like what is mentioned in the last two bullets (digital trigger and remote programming) makes sense. An open question is where to locate input terminals for them: on the rear panel (that is quite usual for many professional models) or at the front panel? I think that for the bench power supply that is not mounted and forgotten somewhere in huge laboratory rack, front panel sounds more handy.
I tried to draw a new proposal using the FreeCAD:

You can see that AUX power supply is now moved on the rear panel. There is also enough place to add 60 x 60 mm fan. The AUX power supply PCB with minor changes could be now used for mounting (vertical) USB and Ethernet connectors. One important thing that should not be skipped are limited ability of enclosure to dissipate a heat. That calls for more efficient solution and with currently used pre-regulator that is not a case.

In the following post I'll present new schematic and PCB designed in line with above mentioned ideas.

[prasimix]

A new PCB is created in accordance with issues mentioned in the previous post. I'd like to highlight few more details:

• LED indications for Stand-by, CV, CC and remote sense are still there because I found that very useful and informative. But THT LEDs are now replaced with SMD and small lightpipes will be used (e.g. Bivar PLP2-500). Additionally two more LEDs are added as indication that remote programming is in use.
• Fan control output (PWM) and fan sense input are added
• Battery NTC is now available only on the channel one but it's isolated on-board (OK1) instead of doing that over post-regulator I/O expander input (that comes isolated to the shield).
• Digital (external) trigger is available only on ch#1 and it comes with input protection and level shifter/buffer
• "Power switch" is added that will be become accessible from the front panel for people who don't believe that firmware could do that safely. It will disconnect +5V shield supply but still has no effect if USB cable is connected to the PC (to avoid that USB supply on the Arduino board should be modified by removing few components).
• Ethernet RJ-45 jack is moved to the new AUX power supply board
• Touch screen controller can be now programmed using software SPI (like UTouch library does) but also with hardware SPI (defined with JP3, JP4 and JP5).

The schematic can be split into four sheet with the following circuits:

• Sheet 1: two channels power outputs serial and parallel relays, remote sense input relays, reverse polarity protection, LED and relay driver
• Sheet 2: Digital isolators, Arduino board breakout, on board 3.3V regulator
• Sheet 3: SPI peripherals – EEPROM, RTC, Ethernet and TFT LCD with touch screen. Driver for buzzer and NTCs (temperature sensors) analog inputs
• Sheet 4: CV and CC LED drivers, remote programming inputs, V/F converter for load NTC (isolated), digital trigger protection and level shifter

Dimensions of the new PCB are now 204 x 76 mm and it occupy most of the back side of the front panel:

[prasimix]

Here is the latest revision (r2B6) of the Arduino shield (digital control) board. It includes the following modifications:

• Existing ENC28J60 Ethernet controller is replaced with W5500
• One instead of two LED indicators is using for indicating power output status
• Existing TLC5925 LED driver is now using for driving CC and CV LED indicators on both channels[/li

New schematic and PCB are shown below (only Sheet 1 and 3 were changed). Also please find attached new pin mappings.
With this modification this revision is completed. I'm going to order a new PCB panel in coming days and if any other soul is courageous enough to follow me in this stage and want to order PCB panel please let me know, that will help me decrease the cost of this round.

EEZ Arduino shield+BP r2B6.pdf (113 KB)

PSU Arduino pin mapping r2B6.pdf (306 KB)

[prasimix]

The touch screen really has a central place in this project. Therefore predictable behavior with high level of precision is of paramount importance.

We spent (or wasted) considerable amount of time guessing what going wrong with touch screen control. Possibly we just discover hot water by finding that working with touch screen is not straight forward. Maybe the problem laying in unfortunate match of resistive sensor and touch controller (XPT2046). At the beginning a Utouch library is taken for granted as "the solution" for small displays and comes with Arduino support that we need.
But, after some time my colleague realized that Utouch missed many things and that simply blaming hardware is not fair. Actually it's possible to completely change situation from frustrating and completely unusable to precise and predicable solution. He started with tweaking existing utouch, and finally gave up completely from it and in addition deploy tactics that David Beer presented here (thank you very much David!).
I prepared two short demos, first one with simple filtering and second one with new approach:

Touch screen demo (simple sample filtering)

Touch screen demo (advanced sample filtering)

[prasimix]

All required coding, testing and tweaking required for programming output parameters are finished and I made a short video about that. This first video covers all 3 input modes: Slider, Step and Keypad. The first two also have interactive/non-interactive option that gives us 5 possible input modes. They together represents a solid equivalent for the one (or combination) of standard input devices such as multi-turn potentiometer, incremental encoder or numeric keypad.

As you can see many options are still missing but the biggest obstacle - having usable screen-touch control is resolved. I didn't use stylus during the whole presentation just my finger (that is maturely thick). Now we can continue more comfortably to add everything that is already available over remote console (using SCPI commands) to the local interface and I'll try to cover progress with more videos.
Your comments are highly welcomed.

Output settings first preview

[Ton_O]

Indeed, solution has been designed thoroughly and complete; my compliments!
Any information on the cost of the total project?
And do you sell parts (notably the PCB's)?

[prasimix]

Hi Ton_O, the solution is almost completed. Hardware part more then firmware, but we are progressing very well. On hardware side I'd like to test existing solution (let's call it Revision 4) how SMPS pre-regulator based on LTC3864 will works and as you can see in few previous posts idea is to make a whole solution more compact. That will be Revision 5.
Firmware in version M2 (Milestone Two) should offer complete control over local TFT display with touch-screen (what we have now is SCPI remote control, and basic functionality over TFT display/touch-screen as it's shown in latest video).
Cost of the whole solution is not small, BUT if we take into account capability, performance and that is completely open and with advanced control then even in quantity of one it starts to make lots of sense. Total cost can be estimated using BOMs that are available on the GitHub, and for the Revision 4, they can be find on the following links:

Arduino Shield ~77€ (without Arduino board)
Pre-regulator ~36€ (for two)
Post-regulator ~62€ (for two)
AUX Power supply 33€

When we add enclosure (20€ without heatsinks nor customization of front and rear panel) and main transformer (~50€) total without VAT and PCBs is about 280€ (or 300€ with "eBay-grade" Arduino board).

Many people already asked the same question about selling PCBs. That supports my idea to organize group buy for at least PCBs and possibly customized metal enclosure. If you don't want to wait Eagle and Gerber files are also available on the GitHub and if you need three (that is min. quantity for order) or more maybe OSHpark could start to be attractive. You can find even more then what you possibly need here.

Since we are still working on it and everything is open for new suggestions don't hesitate to post your comments, wishes, ideas, etc.

[prasimix]

Many things was happen with this project it recent months both on hardware and software side. Details could be found on project home page or on the GitHub. In the meantime I was successfully completed an experimental group buy for bare PCBs, TFT display and customized metal enclosure. That encourage me to start thinking about another group buy but this time for assembled modules and all other parts. But PCBA service makes sense only for larger quantity that means more people needs to be involved and I decide to run new group buy as a crowdfunding campaign.

The campaign will be conducted on the CrowdSupply and I'd like to hear your opinions about pledge levels. First please note that I'm not going to offer a completed solution. The reason for that is CE/FCC certification that is very costly and for 100 units that is campaign goal it could make a whole calculation completely unattractive.
Again, this is a group buy, not a new product production kick start, because it's not a profit driven (I have another source of money for living). Therefore prices of all pledges will be set to cover without loss the cost of manufacturing, packaging, transportation and campaign fulfillment cost, crowdfunding platform (12%) and payment gateway fees (2.9% + $0.30).
I was thinking about the following pledge levels (the final number and contents will be set in accordance with interested parties wishes):

• Set of bare PCBs only (4 of them, 2 layer)
• As above + metal enclosure (with other metal parts such as TFT display support, AC/DC modules support, channel's heatsinks)
• Set of assembled PCBs only
• As above + metal enclosure set + wire harness
• As above + TFT display + AC/DC modules (2 of them)
• As above + Arduino Due
  The latest one include all what is needed to assembly a fully functional unit that can be ready to run after firmware is uploaded. In essence you'll need a screwdriver for that operation and PC with Arduino IDE for uploading. Of course, you also need multimeter to calibrate it using built-in calibration wizard (see video).

Thanks in advance for your valuable inputs.