NetCrate 1.2a

Problem

Small response teams can arrive before fixed communications are restored or larger communications assets are established. Personal hotspots and a single carrier leave the operation dependent on one path.

Description

What I built or investigated

NetCrate is a rugged, preconfigured field gateway combining Starlink compatibility, support for T-Mobile, Verizon, and AT&T cellular paths, separate operational and guest/public Wi-Fi, external antennas, Linux routing, and AC/DC/battery operation.

Iterations

The work did not happen in one jump.

1. 01

   Moved from a collection of networking components to a single case that could be opened, powered, and deployed quickly.

2. 02

   Built a Raspberry Pi gateway around an IPv6-only LTE environment, including NAT64/CLAT and local routing.

3. 03

   Separated operational and public traffic instead of treating every connected user the same.

4. 04

   Added external antenna and power architecture for a self-contained field unit.

5. 05

   Shipping and field handling exposed mechanical weak points, leading to rework of retention, internal layout, and deployment readiness.

6. 06

   Converted one-off technical work into documentation, pricing, evaluation agreements, procurement materials, and customer support planning.

Result

Where the project landed

Model 1.2a was commercially delivered and field-deployed with Disaster Aid USA in March 2026. The current system is designed for under-five-minute setup after service activation.

Lessons

What carried forward

• A field product is hardware, network configuration, power, documentation, packaging, training, and support—not just a router in a case.
• Redundancy is valuable only when failover behavior is tested under real constraints.
• Physical ruggedization can be as important as software reliability.
• Customer discovery changed the positioning from “internet in a box” to an early-operations continuity tool.

Images & evidence

Work in context