Remote Development Board Test Bench
When engineers cannot obtain the RISC-V board they need, they can rent real hardware remotely, flash firmware online, and inspect serial output, waveforms, and power consumption.
Embedded engineers who cannot buy the target development board often have no choice but to guess in a simulator whether their firmware will actually run. When chips are out of stock, shipping is expensive, or customs clearance is slow, a real board with peripherals already connected can move a project forward more than another document.
After choosing a chip model, required peripherals, and debugging interface, an engineer sees reservable physical devices hosted by labs in different locations. Each listing specifies its connected sensors, displays, debuggers, and available times. The user uploads firmware and build instructions; before the reservation starts, an isolated environment prepares the build and flashing process.
During the reserved session, the browser shows serial output, logic-analyzer traces, power curves, and a device camera feed. Engineers can reboot the board, switch among preset wiring configurations, or have the platform retain a repeatable test setup. When something goes wrong, logs, the firmware version, and peripheral status are bundled into one experiment record for the team to continue investigating.
Board owners rent out idle equipment by the hour, while maintainers turn common chips and peripherals into validated wiring templates. The initial service focuses on common RISC-V development boards and publicly available peripherals. It does not host enterprise equipment containing confidential data or replace hardware tests that require on-site safety qualifications.
Why now
On August 16, an article by an engineer in Trinidad and Tobago brought development-board delivery, shipping costs, and customs difficulties into the RISC-V debate. S1 When observed on August 17, the article was ranked third on Hacker News, with 343 points and 179 comments, drawing more attention to remote access to real development boards. S2
Target user
The core user is an embedded engineer who temporarily cannot access the target board. Their firmware compiles, but they need to verify boot behavior, peripheral timing, or real-world power consumption. Waiting for cross-border shipping blocks debugging and delivery. University instructors and open-source maintainers also fit: they need multiple people to reproduce experiments in turn without repeatedly shipping hardware.
Minimal entry point
Start with a small set of RISC-V development boards that can be wired repeatably. For each board, expose only a serial console, reset, and one flashing interface. Build the control plane on labgrid’s remote architecture, which already supports USB uploads, power control, and measurement-device integration. S3 Run builds in isolated containers with no persistent credentials. During a reservation, relay serial output and control commands over WebSockets. Start cameras with low-frame-rate video, and provide waveform and power data as uploaded sample files. The first release should offer only maintainer-validated templates, not arbitrary rewiring. Save the firmware hash, toolchain version, and device state for every run.
Punching above its weight
Source the first devices from university labs, hardware communities, and independent course creators. They already have idle boards and can create credible wiring templates. Publish repeatable public experiments around specific chips, creating more precise search entry points than generic hardware rentals. Then give open-source firmware projects links for reproducing failures, so maintainers can open the same board with the same logs.
Competitors & gaps
- labgridGoogle
- labgrid already connects development boards on different hosts through a unified control layer. It supports serial consoles, SSH, power resets, USB flashing, and digital outputs, and can connect audio/video and measurement devices as well as work with pytest. S3 These capabilities cover much of the underlying control needed for a remote test bench. It is better understood as Python infrastructure that laboratories deploy themselves. Its documentation does not offer cross-institution device discovery, public availability windows, or transactions. Each lab remains responsible for reliable board wiring. The product opportunity is a managed layer for hardware listings, reservations, access control, and experiment records. It must also limit rentable setups to standardized wiring, rather than becoming outsourced remote operations.
- LAVAGoogle
- LAVA automates validation on physical and virtual hardware. It can accept jobs, deploy build artifacts, boot devices, run tests, and retain and export results. S4 The system suits kernel, bootloader, and system-level testing. Its documentation explicitly says that LAVA is neither a test lab nor a build farm. S4 Users must therefore provide their own devices, wiring, and build process. Its job model favors predefined tests rather than live, browser-based operation. A remote development-board test bench could add time-based rentals, camera views, and interactive debugging. The real gap is not scheduling, but standardizing hardware across labs and delivering it reliably.
How it makes money
Charge by reservation time for each device-and-peripheral combination, taking a commission on every booking. Logic analyzers, power meters, and cameras can be billed as add-ons.
The case against
Remote flashing can brick a board, so maintainers need reliable automated recovery. Loose wiring, power faults, and instrument drift can create false failures that are hard to identify. User-uploaded firmware may also attack gateways or probe lab networks. Isolation, rate limits, and device resets will continually raise operating costs. Board and peripheral combinations are difficult to standardize, and a growing template catalog will slow validation. Camera and waveform transmission are also affected by network latency, so the experience may not be better than waiting to buy a board. If utilization is low, revenue per session may not cover manual resets and consumables. First validate whether a small number of standard configurations can run reliably without supervision before expanding the market.