EZ Duplicator was a Linux-based appliance for copying, verifying, and securely erasing USB drives across a large bank of ports. I worked on the Python application, device discovery, serial communication, controller firmware, power control, PCB layout, and fitting the hardware into the enclosure.

One persistent problem happened before copying could begin. If the USB hubs powered up at the wrong point while Linux was starting, the operating system could miss some of the connected devices. By the time the application opened, it could be working with an incomplete set of drives.

I built the 12 Volt Power Manager, or 12VPM, to control when the hubs received power. The application sent a repeating serial message, called a heartbeat, to a separate microcontroller. The controller switched on the hub supply after receiving that message and switched it off if the messages stopped.

Two EZ Duplicator systems have been in production use since the project began. The hardware worked, but there are parts of both the electronics and software that I would design differently now.

Let Linux start before powering the hubs

USB enumeration is the process of detecting connected devices and setting them up for use. With a large bank of hubs and drives, that process could be incomplete while the host was booting.

Retrying a copy or improving an error dialog would not help if Linux had never discovered the target drive. I wanted the host to finish starting and the application to establish its control connection before powering the hubs.

The intended sequence was:

  1. Start Linux with the controlled hub supply off.
  2. Start the EZ Duplicator application and open its serial connection to the 12VPM.
  3. Send a heartbeat to indicate that the application is ready.
  4. Have the 12VPM switch on hub power after receiving it.
  5. Keep sending heartbeats. If they stop, let the controller's watchdog switch the hubs off.

Linux handled the operator interface and USB devices. The smaller controller handled the hub power supply.

The application and power controller

I built the Linux application in Python using GTK for the interface. It supported bit-for-bit and data-only copying, verification, secure erase, drive discovery, capacity checks, updates, diagnostics, logging, and error handling. A small web endpoint also provided live diagnostic logs.

EZ Duplicator operator interface: workflow selection, settings access, and live diagnostic log output.

The 12VPM used an Arduino-class microcontroller, a serial connection running at 115200 baud, and relay control for the hub supply. When it received HEARTBEAT, it returned ACK, reset its watchdog counter, and enabled hub power. The host also checked for acknowledgements and could offer the operator a recovery option if they were missing.

Related power-management patent work names me as inventor and digitalVAR, Inc. as applicant. Figure 3 shows the connection between the Linux host, controller, and hub bank.

Patent figure showing the Linux host CPU, USB serial control link, 12 Volt Power Manager, and controlled USB hub bank.
Patent FIG. 3: system architecture linking the Linux host, 12V Power Manager, and USB hub bank.

From off-the-shelf parts to my first PCB

The first 12VPM used off-the-shelf parts to prove the startup sequence. The second version put the controller on a custom board and added cabinet-fan control using a DS18B20 temperature probe. The fan threshold was configurable and stored in external EEPROM.

12VPM V1: the initial proof-of-concept, assembled from an Arduino Nano, terminal blocks, a relay module, and a temperature-sensor breakout inside a clear enclosure.

V2 was my first PCB. I was still learning how transistors worked and how to use them correctly in a schematic. It also introduced me to working with separate ground and +5 V planes and designing a board to fit an enclosure.

The board let me put the controller, relay connections, power connections, and temperature-sensor interface together in the appliance. It needed substantial electrical-design improvements before I would use it as the basis for another revision.

12VPM V2: the custom PCB revision that consolidated the controller, relay outputs, power connections, and temperature-sensor interface into the appliance enclosure.

Why I used a heartbeat instead of a fixed delay

A fixed delay would wait a set amount of time after startup, whether the application was ready or not. The heartbeat gave the controller an ongoing indication that the host application was still communicating.

Host application Serial messages Controller action Hub power
Starting or unavailable No heartbeat Keep the relay open Off
Sending heartbeats HEARTBEAT received and acknowledged Close the relay and refresh the watchdog On
Crashed, rebooting, or disconnected Heartbeats stop Open the relay when the watchdog expires Off

I could inspect the commands and responses at both ends of the serial connection, which helped me troubleshoot the early versions. Figure 4 shows the heartbeat and relay behavior.

Patent figure illustrating heartbeat commands from the host, the 12 Volt Power Manager controller, and relay control for the USB hub power supply.
Patent FIG. 4: 12VPM command handling for host heartbeats, controlled hub power, and the watchdog response.

What the results establish

The controller was implemented on real hardware, and two duplicators have been used in production. That demonstrates the approach was put into use, but it does not establish a measured reliability improvement across different hub banks and drive combinations.

The public project records do not include a repeatable set of startup tests across port counts, hub configurations, drive types, and Linux versions. They also lack relay-timing captures, thermal measurements, and a before-and-after comparison of field failures. Those are results I would want from a new revision.

Design review: what I would change now

Separate copying, device discovery, and the interface

The Python/GTK application grew one feature at a time. Copying, dialogs, background processes, diagnostics, settings, updates, file access, and hardware communication ended up too closely connected.

I would separate the copying engine, device discovery, hardware control, and user interface. Each part would have a defined way to exchange requests and status, with tests for what happens when it fails. The interface would display that status instead of handling so much of the work inside dialogs and widgets.

Measure the watchdog timeout with a clock

The original firmware decremented a counter as its main loop ran. Comments described an intended timeout of about ten seconds, but the actual interval depended on how quickly the loop executed and what happened on the serial connection.

I would use elapsed time from a clock that is not affected by changes to the system's time of day. I would also define startup, normal operation, lost communication, faults that stay active until cleared, and recovery as separate states.

I would log transitions and test serial disconnections, host restarts, power interruptions, and sensor faults. If needed, I would add a hardware watchdog so the board could recover independently of the heartbeat-handling firmware.

Rework the electronics before another board

A new board would need the microcontroller, power supply, programming and debug connection, switching drivers, protection, and service connections designed together.

Before layout, I would review the actual loads, grounding, heat, and repair needs. That would include fuses, voltage-spike protection, default output states, relay or solid-state switching, current and contact ratings, connector retention, test points, and how the board would be assembled and serviced.

The first board got the controller into the appliance. A new design should make it easier to test, build, and repair as well.

Build repeatable tests

I would build a fixture that sends heartbeats, disconnects the serial link, cycles host power, changes simulated temperature readings, and measures when the controlled supply turns on and off.

On Linux, I would use a simulated serial device and test drives to check discovery, retries, incomplete copies, verification failures, and recovery without needing the complete appliance for every test. Each test would need a defined pass/fail result.

What I learned

The application could only work with the drives Linux had found. Tracking the missing drives back to startup timing led me to work on the power supply and controller firmware as well as the application.

The project also showed me what I would need to improve beyond a working prototype: clearer separation in the software, a timeout measured in time rather than loop counts, better electrical design, and repeatable tests with recorded results.

Project facts

  • Role: Linux application development, 12VPM firmware, hardware prototyping, PCB layout, and system integration; named inventor on the Power management system patent (US 12,307,259 B2).
  • System: A Linux USB duplication appliance with a Python/GTK interface and a microcontroller-based 12 V hub-power manager.
  • Technology: Python, GTK, Linux, USB, serial communication, Arduino-class firmware, C/C++, DS18B20, EEPROM, relays, and PCB layout.
  • Status: Two systems have been in production use since inception. The improvements described above are proposed changes for a new revision.
  • Source: EZ Duplicator on GitHub