/004

SIDELOBE

“How much field computer can you build from commodity hardware?”

In progress Experiment Hardware · Embedded · RF

// The question

Purpose-built field computers — ruggedized handhelds with radios, sensing, and long battery life — have traditionally been the domain of defense contractors and industrial suppliers, priced accordingly and specified by committee.

Meanwhile the hobbyist supply chain has quietly become absurd: microcontrollers with radios cost a few dollars, decent displays cost less than lunch, and sensors for almost any physical quantity ship in breakout-board form. The question writes itself — if you design seriously against cheap parts, how far up the capability curve can a handheld actually get?

// The constraint

Why isn’t this already easy? Integration. Any one module is trivial; making a dozen of them share power, buses, interrupts, and an enclosure — reliably, outdoors, on a battery — is where hobby projects go to die. RF is unforgiving of casual layout. Power budgets punish every lazy decision. And a device you must hold and use in the field imposes industrial-design constraints a desk prototype never faces.

The commercial versions solved this with engineering departments. That’s precisely the cost structure under test.

// The attack

Modular by construction: a core compute-and-power spine with radios, sensors, and interface hardware as swappable modules, so the device is a platform rather than a one-off. Design work leans on the lab’s own tooling — the PCB pipeline from Experiment 001 feeds this one directly, which is not a coincidence. Experiments here are supposed to compound.

// The leverage

  • The hobbyist industrial base. Volume manufacturing for the maker market drove capable MCUs, radios, displays, and sensors to near-disposable prices, with documentation and community knowledge attached.
  • Cheap fabrication. Prototype PCBs in days for pocket money; 3D-printed enclosures overnight on the bench. Iteration cost collapsed from “tooling budget” to “coffee budget.”
  • Open embedded software. Mature open toolchains, RTOSes, and protocol stacks mean the firmware starts at the interesting layer instead of at zero.
  • AI-assisted hardware engineering. Datasheet reading, pinout checking, and driver scaffolding — the slow, error-prone connective tissue of embedded work — now runs with machine assistance.

// The build

In progress. Current state: working bench prototypes of the core spine and initial radio and sensor modules, firmware bring-up across the module set, and enclosure iterations moving toward something that survives a jacket pocket. This page will grow artifacts — boards, builds, field notes — as the hardware does.

// The failures

  • Cheap parts lie. Datasheets for low-cost modules omit, round, and occasionally invent; a real bring-up ritual of measure-first, trust-later became standard procedure.
  • Power budgeting by spec sheet failed immediately — quiescent draws and radio transients only reveal themselves on a meter. The battery-life story is written in measurements, not datasheets.
  • The first integration attempts confirmed the constraint section above: every module worked; the assembly didn’t. Bus contention and grounding discipline are where the real engineering lives.

// The result

Too early to declare. The honest status is: the economics look as promising as hypothesized, the integration is as hard as feared, and the device works on the bench but has not yet earned the word “field.” That’s what the current phase is for.

// The implication

If a small lab can carry a handheld from question to working field hardware on commodity parts, then custom purpose-built devices — instruments, field tools, one-customer hardware — stop being a category reserved for companies with manufacturing departments. “We should build a device for this” becomes a reasonable sentence for a two-person team to say.

NotebookThe gap between “dev board on a desk” and “tool in a hand” is the whole experiment.