We decided to implement the SCPI protocol via USB to control our Powerblock. It's time to decide which specific commands should be implemented. 

Instrument Classification:

• bf_keyword = DCPSUPPLY

Base Functionality:

• Capability request:

  • SYSTem:CAPability? - This query returns an <instrument_specifier>, example reply from power supply with additional functions: (DCPSUPPLY WITH (MEASURE&MULTIPLE&TRIGGER)). More about <instrument_specifier> at 1.4.1 SCPI 1999.

• Output state control:

  • OUTPut[:STATe] {OFF | ON | 0 | 1} - change output state of device.
  • OUTPut[:STATe]? - queries the output state of device.
  • As stated in Command Reference, *RST sets the output state to off.

• Source control:

  • [SOURce]:CURRent[:LEVel][:IMMediate][:AMPLitude] {<Current>} - When a power supply is operating as a voltage source, this command sets the current limit. When a power supply is operating as a current source, this command sets the output current.
  • [SOURce]:CURRent[:LEVel][:IMMediate][:AMPLitude]? [MIN | MAX] - query for setting of current (target, min or max limits).
  • [SOURce]:VOLTage[:LEVel][:IMMediate][:AMPLitude] {<Voltage>} - When a power supply is operating as a voltage source, this command sets the output voltage. When a power supply is operating as a current source, this command sets the voltage limit.
  • [SOURce]:VOLTage[:LEVel][:IMMediate][:AMPLitude]? [MIN | MAX] - query for setting of voltage (target, min or max limits).
  • At *RST a power supply is required to set the voltage and current to “safe” conditions. This is generally achieved by setting them to their values closest to zero.

• Status Reporting:

  The device status system consists of the OPERation (information about normal device operation, current operations) and QUEStionable (signal quality information) subsystems. Each subsystem consists of 3 parts (Event, Condition and Enable register), ref. by NGE100 User Manual:

  • CONDition - this register is directly written into by the hardware or the sum bit of the next lower register. Its contents reflects the current instrument status. Read only register. Its contents is not affected by reading
  • EVENt - this register indicates whether an event has occurred since the last reading, it is the "memory" of the CONDition register. It is permanently updated by the instrument. Read only register. Reading the register clears it.
  • ENABle - this register determines whether the associated EVENt bit contributes to the sum bit (status mask). Read and write access. Its contents is not affected by reading.

• STATus:OPERation[:EVENt]? - reading device condition via event (memory) register. More about bit field of this register at 9.3 SCPI 1999.

• STATus:OPERation:CONDition? - reading device condition directly. More about bit field of this register at 9.3 SCPI 1999.

• STATus:OPERation:ENABle? - reading status mask for operation register.

• STATus:OPERation:ENABle {0-65535} - enables the bits in the status mask for operation register. More about bit field of this register at 9.3 SCPI 1999.

• STATus:QUEStionable[:EVENt]? - reading signal quality register via event (memory). More about bit field of this register at 9.4 SCPI 1999. For a power supply, the bits of interest in the QUEStionable status structure are VOLTage and CURRent. When a power supply is operating as a voltage source, bit 1 (CURRent) shall be set. When a power supply is operating as a current source, bit 0 (VOLTage) shall be set. When the output is unregulated, both bits shall be set (for example, while the output is changing to a new programmed value).

• STATus:QUEStionable:CONDition? - reading signal quality register directly. More about bit field of this register at 9.4 SCPI 1999.

• STATus:QUEStionable:ENABle? - reading status mask for questionable register.

• STATus:QUEStionable:ENABle {0-65535} - enables the bits in the status mask for questionable register. More about bit field of this register at 9.4 SCPI 1999.

Additional Functionality:

• Measurement capability:

  • For more details on the implementation, see 7.2.1 SCPI 1999.
  • af_keyword = MEASURE
  • MEASure[:SCALar]:VOLTage[:DC]? - queries the measured voltage value of the selected channel. Example output "1.000E+00"
  • MEASure[:SCALar]:CURRent[:DC]? - queries the measured current value of the selected channel. Example output "1.000E+00"
  • This unctionality further require no additional Measurement Instruction commands and has no interaction with the power supply’s triggering system, if implemented.

• Multiply supplies capability:

  • For more details on the implementation, see 7.2.2 SCPI 1999.
  • af_keyword = MULTIPLE
  • Each channel of the power supply is considered as separate instrument.
  • INSTrument:NSELect {1 | 2 | 3} - numerical selection of a channel. <num> - number of channel (counting from 1).
  • INSTrument:NSELect? - queries the numerical channel selection.
  • INSTrument[:SELect] {OTPut1 | OUTPut2 | OUTPut3} - selection of a channel by name.
  • INSTrument[:SELect]? - queries the named channel selection.
  • STATus:OPERation:INSTrument[:EVENt]? - reading summary device condition via event (memory) register. More about register interconnections at 9.5 SCPI 1999.
  • STATus:OPERation:INSTrument:CONDition? - reading summary status device condition register directly.
  • STATus:OPERation:INSTrument:ENABle? - reading status mask for summary operation register.
  • STATus:OPERation:INSTrument:ENABle {0-65535} - enables the bits in the summary status mask for operation register.
  • STATus:OPERation:INSTrument:ISUMmary<n>[:EVENt]? - reading dedicated instrument condition via event (memory) register (<n> = 1 | 2 | 3).
  • STATus:OPERation:INSTrument:ISUMmary<n>:CONDition? - reading dedicated instrument condition directly (<n> = 1 | 2 | 3).
  • STATus:OPERation:INSTrument:ISUMmary<n>:ENABle? - reading dedicated instrument status mask (<n> = 1 | 2 | 3).
  • STATus:OPERation:INSTrument:ISUMmary<n>:ENABle {0-65535} - enables the bits in the dedicated instrument status mask (<n> = 1 | 2 | 3) for operation register.
  • STATus:QUEStionable:INSTrument:CONDition? - reading summary status of signal quality register directly.
  • STATus:QUEStionable:INSTrument:ENABle? - reading status mask for summary status of signal quality register.
  • STATus:QUEStionable:INSTrument:ENABle {0-65535} - enables the bits in the summary status mask for questionable register.
  • STATus:QUEStionable:INSTrument:ISUMmary<n>[:EVENt]? - reading dedicated instrument signal quality via event (memory) register (<n> = 1 | 2 | 3).
  • STATus:QUEStionable:INSTrument:ISUMmary<n>:CONDition? - reading dedicated instrument signal quality directly (<n> = 1 | 2 | 3).
  • STATus:QUEStionable:INSTrument:ISUMmary<n>:ENABle? - reading dedicated signal quality status mask (<n> = 1 | 2 | 3).
  • STATus:QUEStionable:INSTrument:ISUMmary<n>:ENABle {0-65535} - enables the bits in the dedicated instrument status mask (<n> = 1 | 2 | 3) for questionable register.

• Trigger capability:

  • For more details on the implementation, see 7.2.3 SCPI 1999.
  • af_keyword = TRIGGER
  • INITiate:CONTinuous {OFF | ON}
  • INITiate[:IMMediate][:ALL]
  • [SOURce]:CURRent[:LEVel]:TRIGgered[:AMPLitude] <Voltage>
  • [SOURce]:VOLTage[:LEVel]:TRIGgered[:AMPLitude] <Current>
  • TRIGger[:SEQuence][:IMMediate]:SOURce {BUS | EXTernal | ...}
  • Need to implements the *TRG common command.
  • A complex implementation for a simple device. The HMC804x example implements only two functions supporting this subsystem. The NGE100 example is slightly more complex. A precise definition of the trigger functionality for the device being designed is required

We’ve just submitted Powerblock to the NGI0 Commons Fund

— a European initiative supporting open-source and open-hardware projects that strengthen the digital commons.

Our proposal focuses on bringing Powerblock to a fully documented, manufacturable open-hardware design and preparing its public launch on Crowd Supply.

The NGI0 program, coordinated by NLnet Foundation, funds small to medium R&D projects that advance open, trustworthy, and sustainable technologies. If selected, the grant would help us accelerate development, testing, and community documentation.

In any case, we’ll continue to build in the open — all progress logs and design updates will remain visible here and on our GitHub.

Fingers crossed 🤞 and back to building!

We've stuck a little bit with the average current regulation when our supply goes to the CC (constant current) state. The LM51772 has an internal DAC for Iset, or we can set a resistor between ILIM and GND. Our goal is to substitute Riset with our scheme so that we can set it with the DAC of the MCU:

At first, it was ringing a lot, but after the wires shortened, it became much stable and we can control the current! That was because our auxiliary scheme had become a part of the control loop. In the prototype, we should be very careful with it.

Here you can see gorgeous soldering PLS to PLS. Anyway really small current goes about 7cm from the chip to our loop...

Let's get to the result:

We can control the current from 40mA to 3.4A with a step of 0.7mA. 

- Shunt should be bigger, not 10 but 20mOhm

- Add filters to ILIM to adjust the speed and stability of the loop

- Be careful with routing in the prototype due to high sensitivity and tiny currents.

- DAC signal should be divided

Our team at Encadra has joined the development of PowerBlock-323.

We are contributing our experience in product design and enclosure engineering to help move the project forward.

As part of this work, we are now evaluating two enclosure directions: one made from bent sheet metal and another from solid aluminum. Both versions share the same functional layout, but they differ in manufacturing methods and trade-offs.

We will continue to share design updates as the project evolves. Next topics may include thermal aspects, assembly approach, and finishing options. Feedback from the community is very welcome.

Our op-amp PCB is currently stuck somewhere in Finnish customs (classic…), so instead of waiting, we kicked off Mockup #1 testing without it.

The first experiment focuses on the ATRK input for output voltage regulation on the LM51772EVM. The datasheet isn’t very clear about how this feature behaves, so let’s figure it out ourselves.

Setup

• STM32 DAC connected directly to the ATRK input of LM51772EVM

• Sweeping DAC voltage while measuring Vout 

• Three different Vout setpoints, setup over I²C

Observations

At first glance, the DAC seems a bit nonlinear — maybe due to bias current? So we checked linearity directly.

Result: DAC looks fine. That means the nonlinearity is a quirk of the LM51772 itself. And that’s actually fine for us. All we need from ATRK is the ability to slightly trim Vout (no more than ±50 mV).

Results

Near the maximum output of 32 V, the trim resolution looks promising:

• ~200 µV/step for the last 10 mV of Vout

• ~600 µV/step for the last 60 mV of Vout

With an additional op-amp stage to amplify the DAC voltage into the desired range, resolution will only improve.

Next steps

Once the op-amp PCB finally arrives, we’ll move on to testing ISET regulation, comparing direct ATRK control vs. buffered DAC inputs with op-amps.

When people hear “power supply,” they usually think about hardware: schematics, PCB layout, components, thermal design. And yes — our project is indeed a significant hardware challenge. But the real killer feature of the Powerblock 323 won’t just be its silicon — it’s the embedded software running inside.

Why? Because in automated testing, reliability isn’t about shiny knobs or displays. It’s about software that can:

• Negotiate USB-C PD profiles,

• Parse SCPI commands without surprises,

• React to overloads,

• Stay stable after thousands of enable/disable cycles.

That’s why we’re starting to outline the firmware architecture early. The block diagram above illustrates our conceptualization of the system.

In short: we’re treating firmware as a first-class citizen, not an afterthought. A PSU for DUT testing is only as good as its software brain.

This is just the first sketch, but it already helps us see where complexity lies and what needs extra attention.
BTW, SCPI parser works + first USB PD negotiation tests ok. Next step - make them work together.

Scheme

Voltage control

LM51772 gives the ability to control the output voltage in two ways simultaneously: I2C and external(ATRK or DTRK). To achieve a small error, we could set a rough voltage with I2C, then fine-tune it with ATRK. The DAC signal should be attenuated and shifted to near FB, 0.8V

The goal is to manipulate the ATRK lower than 0.8V. So, adding 750mV and choosing a gain 20mV/V.

Modelling with tools.analog.com

AnalogDevices has an instrument for designing, so it's simple to generate new schematic:

Looks fine. Let's export and model in LTSpice

Modelling with LTSpice

DC sweep 0-2.5 Vin

Achieved range in simulation from 753 to 796 mV. ATRK step - 12uV, Vout step - 0.5mV

Average current control

Average current control has another architecture, so we have two options:

• 10/20mA steps via I2C. The desired step is 1mA.
• External ISET with a resistor.

 Instead of a resistor, we'll use a DAC with a FET, stabilising the current in the ISET net. 

External DACs

Added DACS on the board just in case something goes wrong with the built-in STM32.

PCB

Simply put everything on the board

This board connects the Nucleo board with the LM51772EVM. We're almost ready to test everything together!

Goals

Test software is ready. Time to test the test software!

Features to test:

• STM32 PD controls the voltage from the Type-C power supply
• 2 channels of the STM32 DAC are controlled in the terminal

Why did I choose them? Regulation of Vout and average current - the biggest risk at the moment. PD is needed to test the power supply EVM with real Type-C inputs.

Scheme

Simple connection of two devboards from ST and a power adapter. 

Test

For power delivery, there is a ready solution from ST. On the PC side using Stm32CubeMonitor UCPD. Manipulating voltage through the GUI is straightforward. 

The only moment was inconvenient - UCPD utilises Nucleo's USB-VCP only when the built-in ST-LINK is reconfigured to VCP + debug. In the default state (Drive+VCP+Debug), they don't work together.

Results

• 2 DACs are controlled through the terminal, but are twisted and 
• Can request USB PD supply with profiles: 
  • 5V 1.5A
  • 9V 3A
  • 20V 3A

Ready to power up LM51772EVM!