Project Logs

Collapse

• From Concept to First Hardware Test Results

  Ioan Larionov • 03/31/2026 at 13:35 • 0 comments

  
  
  PwrBlock is our open-source programmable power supply for test fixtures and electronics testing automation.

  It is no longer just a schematic or a render. We already have the first assembled samples, and they have gone through the first real tests. This article is a short update on what PwrBlock is, what we have already confirmed on hardware, and what we are improving next.

  Why We Are Building It

  The idea behind PwrBlock is simple.

  When building test fixtures, engineers often end up using either a full bench power supply with lots of unnecessary features, or a generic DC-DC module that works until it suddenly becomes the least predictable part of the setup.

  We wanted something else: a compact, programmable, open hardware block that can be embedded directly into a test stand and controlled as part of the system.

  PwrBlock is part of a larger plan to build a family of open hardware tools for electronics testing: power supplies, programmers, switch matrices, DAQ modules, and other building blocks that can be combined into complete fixtures.

  What Is Inside

  The current revision is built around a few key components.

  Protection: TPS25983

  • 2.7 V to 26 V
  • 2.7 mΩ integrated 20 A FET

  MCU: STM32G0C1CE

  • Cortex-M0+ CPU, up to 64 MHz
  • 512 KB flash
  • USB Type-C Power Delivery controller

  The main reason we chose this MCU family is the built-in Power Delivery controller. It lets us avoid using a dedicated USB PD IC.

  Measurement: INA229

  • up to 85 V
  • 20-bit, ultra-precise
  • SPI interface with alert output
  • integrated temperature sensor, ±1 °C

  This chip gives us accurate measurements of current, voltage, power, and energy at the output of the supply, without extra calibration. It also gives us temperature data.

  Power stage: LM51772

  • Buck-boost
  • I2C configuration interface

  This is the heart of the block. It can step voltage down, step it up, and be configured over I2C.

  First Confirmed Power Results

  One of the first things we wanted to validate was long-term operation near maximum output power.

  So we ran a simple test with these conditions:

  • Output: 32 V / 3 A
  • Input: laboratory power supply
  • Load: electronic load
  • Board condition: no enclosure, no heatsink
  • Duration: 3 hours under load

  The results were:

  • Input power: 103.64 W
  • Output power: 96.17 W
  • Efficiency: 92.7 > %
  • Heat losses: 7.47 W

  That was an important milestone for us. It means the project has already moved from concept to confirmed real-world operation close to the target power level. Although it's not correct to measure efficiency after the wiring.

  Thermal Behavior

  After three hours at around 96 W output power, we checked the thermal picture of the board.

  The hottest point on the top side was the inductor body at 80 °C. The DC-DC converter itself stayed at 71–72 °C. On the bottom side, the hottest area was the thermal path from the inductor pads into the inner PCB layers, reaching 86 °C.

  The inductor itself is rated for temperatures up to 165 °C, so we do not expect thermal problems from these results. Still, thermal chamber testing is definitely on the roadmap.

  The main takeaway is clear: the block can already operate without overheating even without an enclosure. The enclosure test is still ahead, but it is already obvious where the next improvement should go. We will likely use a larger inductor, and thermal coupling into the enclosure through a thermal pad under the inductor area should work well.

  Current Limiting at Low Current

  Voltage regulation over I2C works exactly as expected.

  We get:

  • 10 mV steps in the 1–24 V range
  • 20 mV steps in the 3.3–32 V range

  We also added a useful extra feature: analog fine adjustment. It works well for small offsets around the digitally programmed voltage and allows us to reach about 1 mV adjustment steps.

  This behavior is not explicitly described as a feature in the LM51772 documentation, but it works. We apply an offset to the ATRK input...

  Read more »

• Crowdsupply campaign has started

  Ioan Larionov • 02/26/2026 at 20:41 • 0 comments

  Hardware projects die quietly: not because the idea is bad, but because uncertainty + scaling pressure hits too early.

  Crowd Supply gives hardware founders a rare thing — a path to first users and real shipping.

  Today we’re starting Everypin’s journey with our first open-source production testing building block, PwrBlock 323.

  If this resonates, please subscribe/support — we’ll deliver.

  👉 https://www.crowdsupply.com/everypin/

• It's alive!

  Ioan Larionov • 12/23/2025 at 18:05 • 0 comments

  Finally, the very first Powerblock is assembled and works! What a miracle!

• Almost ready for prototyping

  Ioan Larionov • 11/18/2025 at 11:52 • 0 comments

  Almost ready for prototyping. Fixing the last issues and choosing the right manufacturer.

• block design layout

  Ioan Larionov • 10/23/2025 at 08:42 • 0 comments

• Planning SCPI USB interface

  Ioan Larionov • 10/10/2025 at 05:51 • 0 comments

  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...

  Read more »

• Submitted to NGI0 Commons Fund

  Ioan Larionov • 10/06/2025 at 19:47 • 0 comments

  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!

• ILIM emulation test

  Ioan Larionov • 10/06/2025 at 19:39 • 0 comments

  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

• Design Update: PowerBlock-323 Housing

  Andrew • 10/03/2025 at 01:57 • 0 comments

  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.

• Testing ATRK Regulation – Mockup #1

  Ioan Larionov • 09/24/2025 at 17:50 • 0 comments

  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.

  DAC Steps	ATRK dV	Vout dV	dV/step
  100	0,08	0,06	0,0006
  50	0,04	0,01	0,0002

  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.

View all 14 project logs