53-uniphi-wide-adapters

$99,999,999.00

In stock

SKU

2084

Asset valuation: $12,000,000,000. Generated 2026-06-27, duration 39.1s - Platform: Windows-11-10.0.26200-SP0 - CPU: 80 logical cores @ 1995 MHz - Python: 3.12.10 - uniphi: 0.1.0 - fastapi: 0.138.1 - uvicorn: 0.49.0 - psutil: 7.2.2 - zeroconf: 0.150.0

Skip to the end of the images gallery

Skip to the beginning of the images gallery

Details

Valuation

Generous asset valuation: $12,000,000,000. The listed price is the platform maximum; acquisition at valuation is handled by direct enquiry.

UniPhi DC -- Benchmark Report

_Generated 2026-06-27, duration 39.1s_

Machine

Platform: Windows-11-10.0.26200-SP0
CPU: 80 logical cores @ 1995 MHz
RAM: 31.7 GB
Python: 3.12.10

Versions

uniphi: 0.1.0
fastapi: 0.138.1
uvicorn: 0.49.0
psutil: 7.2.2
zeroconf: 0.150.0

Deploy latency (ms) -- end-to-end deploy_app, real-TCP loopback

Concurrent capacity (apps/sec) -- sequential single-client

Replication throughput (MB/s) -- chunked N=3 over tunnels

Reschedule recovery (ms) -- kill node, wait for apps to re-land

Methodology

Every cluster is real TCP between separate Hub and Node Python processes (asyncio servers on loopback). LAN adds about 0.3-0.5 ms RTT vs loopback; treat these numbers as upper bounds on what a real LAN delivers.
Bundles are minimal tarballs (~150 bytes) so deploy time is dominated by the fabric handshake, scheduler, persistence event, and one app.deploy + app.start frame -- not by the app's actual workload.
Replication uses StorageCoordinator.put_file over real tunnel TCP with N=3 replicas. Reported MB/s is user-visible store rate (bytes-in / time), not wire bytes; actual on-wire is 3x.
Reschedule timing starts the instant we kill the node and ends after Hub._reschedule ships the bundle + app.start to the new node. The 6-second heartbeat-reaper delay is excluded; this measures the reschedule algorithm, not the failure-detection policy.

Personal Wireless Grid (PWG)

The deposition-faithful sibling to UniPhi's KVM mode.

Why this exists

UniPhi grew up into a KVM-over-Wi-Fi product: one operator, one pointer, many

remote PCs on a video wall. That is a real product and it works — but it is

not exactly what the 2017 deposition (patent #3462) described.

The deposition was specifically about going the other direction:

> *"a technology gadget that removes wires and picks up a signal of your own

> link… multiple machines to one machine … device-one any port to expand

> (adapter) router a-another (adapter socket) … **personal machine

> router-a-gone personal wireless grid** … personal hardware cloud."*

> — C. G. Brown, 2017 (ref. 3462)

That is: many wired peripherals, each fitted with a small adapter that

replaces its wire, all routed wirelessly through one personal PC that

acts as the router-a-gone. Your PC then sees them as if they were locally

plugged in.

PWG is that, built. It lives in the same code repo and is covered by the same

patent application (U.S. App. 19/717,706) as UniPhi.

What it does

   [wired USB device]   ── adapter ──╮
   [wired RS-232 inst]  ── adapter ──┤  (( Wi-Fi ))  ──►  PWG HOST  ──►  YOUR APPS
   [wired audio jack]   ── adapter ──╯                   (one PC)         (each peripheral
                                                                           on a local port)

Each remote peripheral arrives on your PC as its own local TCP port

(port 7400 + N). Any app on the PC can read/write that port and the bytes

flow to/from the wired device on the other end of the grid. Pair with an

OS-level virtual-COM shim (com0com on Windows; socat PTY on Linux) and the

serial adapter shows up as COMx / /dev/ttyVx — so existing tools keep

working unmodified.

The three launch adapters

All three are exercised by python -m unittest tests.test_pwg.

Run it now (no hardware)

python -m uniphi.pwg --demo

[pwg] listening for adapters on 127.0.0.1:7373
[pwg] presentations on 127.0.0.1:7400+
+ attach  [usb   ] usb-sim-01   Sim USB Mass Storage     -> tcp://127.0.0.1:7400
+ attach  [serial] ser-sim-01   Sim Bench DMM (RS-232)   -> tcp://127.0.0.1:7401
+ attach  [audio ] aud-sim-01   Sim Audio Input (3.5mm)  -> tcp://127.0.0.1:7402

Try it — open another terminal and:

# pull a frame of audio
python -c "import socket; s=socket.create_connection(('127.0.0.1',7402)); print(len(s.recv(1600)),'B of PCM')"

# query the serial instrument
python -c "import socket; s=socket.create_connection(('127.0.0.1',7401)); s.send(b'*IDN?\r\n'); print(s.recv(256))"

Production deployment

python -m uniphi.pwg --listen 0.0.0.0:7373            # PWG host on your PC

Each real adapter (re-firmwared from the existing UniPhi dongle hardware)

connects to that endpoint on Wi-Fi, announces itself with one JSON line, and

the host opens a local port for it. Disconnect the adapter and the port goes

away; reconnect and it returns.

Wire protocol (newline JSON over TCP)

Reusing the UniPhi dongle hardware

The existing USB Dongle Blueprint (ESP32-S3) and the Serial/UART Adapter Card

(ESP32-C3 + level shifter) are the right boards for the launch USB and

serial PWG adapters — only the firmware mode changes. A buyer of the

UniPhi blueprint packs is, in effect, also buying the buildable hardware for

the Personal Wireless Grid.

Where this sits relative to UniPhi

Both modes ship from the same code repo, are covered by the same patent

application (U.S. App. 19/717,706), and reuse the same retrofit-adapter

hardware family — they are two ends of the same idea.

UniPhi — Two Product Options

> What UniPhi is, in one line: a small adapter that turns any wired device

> into a wireless one — it bolts on, joins your Wi-Fi, and needs no drivers on

> the device. Everything below is just two ways to package that.

Same software (uniphi hub + Fabric), two ways to ship the hardware. **Both

are kept** — pick per customer, or sell both.

Both run the identical control plane: one operator, one pointer, --grid N

roaming, one full-rate video at a time. Option B is simply "the adapter cards,

but each is its own little WiFi box, and your PC is the base."

Option B — the dongle lineup

Three self-contained WiFi dongles (KiCad schematics generated + validated):

A fully controlled machine = USB dongle (input) + DP dongle (screen).

Input-only control (headless boxes, servers, KVM-style) = USB dongle alone.

Honest engineering notes

USB dongle presents standard USB-HID, so the target needs zero software

— it just sees a keyboard/mouse. That's the magic, and it's driverless.

DP dongle must compress (raw DP is multi-Gbit; WiFi isn't). It carries a

hardware H.264 encoder; expect ~30–80 ms glass-to-glass. The Fabric runs

one DP dongle at full rate at a time, the rest at thumbnail — that's why

8-on-one-pointer fits the air.

Battery dongle's load-share path (run-while-charging) is a layout-time

refinement; the schematic shows charger + buck-boost + battery.

"Sell 8 at a time" — the Grid Pack

8 dongles = 8 machines on one pointer, out of the box, because the software

is built for exactly that (--grid 8, single-focus invariant proven in tests).

Suggested SKUs (you set the prices):

Why packs of 8 sell well here: it matches the software's natural unit (a

pointer comfortably roams ~8 machines), it's a clean price anchor, and refills

are just "buy more dongles." The software (the hard part, already built) is the

moat; the dongles are the razor blades.

> Provenance: still patent #3462 — "100 wireless machine adapters … multiple

> machines to one machine … personal wireless grid." Option B is that, almost

> literally: many tiny adapters, one machine in control.

UniPhi DC — Rack and Rack-of-Racks Architecture

The UniPhi Data Center now has three coherent altitudes, with real

working software at every level and layout-ready PCBs for the bottom

two.

                                  +--------------------+
                                  |    SuperHub        |
                                  |  (uniphi.dc.rack)  |   pure software,
                                  |   single CLI       |   runs anywhere
                                  +---------+----------+
                                            |
                  +-------------------------+--------------------+
                  |                                              |
   +--------------+------------+               +-----------------+----------+
   |       Rack 1 (HUB)        |               |       Rack N (HUB)         |
   |  wireless_data_center.kicad_sch           |  wireless_data_center.kicad_sch
   |  ESP32-S3 + ESP32-C6  + 2.5 GbE           |  ESP32-S3 + ESP32-C6 + 2.5 GbE
   |  uniphi.dc.Hub                             |  uniphi.dc.Hub
   |  + scheduler + storage coord               |  + scheduler + storage coord
   +-+----+----+----+----+----+----+            +-+----+----+----+----+----+----+
     |    |    |    |    |    |    ...            |    |    |    |    |    | ...
   +-+--+ +--+ +--+ +--+ +--+ +--+               +-+--+ +--+ +--+ +--+ +--+
   |Node| |  | |  | |  | |  | |  |  up to 8     |Node| |  | |  | |  | |  |  up to 8
   |    | |  | |  | |  | |  | |  |  per rack    |    | |  | |  | |  | |  |  per rack
   +----+ +--+ +--+ +--+ +--+ +--+               +----+ +--+ +--+ +--+ +--+
   wifi_data_center.kicad_sch                    wifi_data_center.kicad_sch
   CM5 SoM + USB-C + microSD + GbE               CM5 SoM + USB-C + microSD + GbE
   uniphi.dc.Node + StorageServer + apprt        uniphi.dc.Node + StorageServer + apprt

What runs where

What's proven (60 tests + a runnable demo)

Real-TCP fabric (uniphi.dc.fabric.TcpFabric) — 9 tests, no

simulation: real sockets, real handshake, real binary tunnels.

Real cross-node storage — 4 tests deploy a file → 3 nodes,

reassemble from any replica, top up after a node drop, recover from

on_node_lost. Tunnel-based, chunked 1 MiB.

Real bundle deploy + reschedule — 2 tests: deploy a tarball, kill

the holder, the survivor materializes the bundle in its apprt.

Real resource caps — 2 tests: an app that grows to 600 MiB under

a 250 MiB cap gets killed by the psutil watchdog within 8 s; an app

under cap runs to clean exit.

Real REST surface — 4 tests over fastapi TestClient: healthz,

nodes, app deploy + listing, dashboard HTML.

Real large-bundle path — 1 test ships a 300 KiB tarball via the

storage coordinator (well past the JSON-line cap), confirms install.

Real rack federation — 2 tests: SuperHub picks the richest rack,

rack loss moves apps to the survivor rack. Plus

examples/multi_rack_demo.py which

brings up 2 racks (6 nodes) over real TCP, deploys 2 apps, kills the

rich rack, and watches both apps migrate to the survivor.

Run it yourself:

python -m unittest discover -s tests   # 60 / 60 pass
PYTHONPATH=. python examples/multi_rack_demo.py

What's still hardware-side

Layout: hardware/wifi_data_center/LAYOUT.md

and hardware/wireless_data_center/LAYOUT.md

specify stackup, placement, diff-pair rules, antenna keepouts.

Schematics + footprints already in the KiCad files.

Firmware: firmware/rack_hub_esp32s3/

has a bring-up sketch that loops Wi-Fi → TCP 7800 → status LEDs. It's

a skeleton, not production firmware; the Python orchestrator continues

to run on a CM5 or x86 host attached to the rack hub board until the

S3 has a Python runtime.

What "rack-of-racks" actually means now

Software: SuperHub(racks=[RackRecord(id, hub), ...]) — feed it Hub

objects and it routes deploys at the rack altitude, with rack-loss

recovery built in. Hardware: the rack hub board's 2.5 GbE jack is the

uplink the SuperHub talks over (same uniphi.dc.fabric wire format

the nodes use, one altitude higher).

Same patent family (#3581 / #3582 / #3583), same control vocabulary,

same fabric. The structure recurses cleanly.

UniPhi

Make any wired device wireless.

Bolt a thumb-sized adapter onto something that has a cord — a keyboard, a

monitor, a CNC mill, a bench instrument, a whole PC — and it joins your Wi-Fi.

**The device itself never changes and needs no drivers; the wire stays, the

cord goes.** Anything wired becomes a wireless node on your own grid.

Then, because they're all on Wi-Fi, one console drives them — KVM-style, **one

computer at a time**, one pointer. That second part is the trick; *making the

wired thing wireless in the first place is the product. (UniPhi = unify* +

the AutoPhi/WonderPhi "Phi" family.)

> Provenance. This is the working software implementation of

> **Chris G Brown, patent #3462 / 2878 — "100 wireless machine adapters and

> *"things that use wires and need to be retro fitted by an adapter … as

> multiple machines to one machine … personal wireless grid."*

> The master invention list lives in ../1 light trigger.txt (proprietary IP —

> keep local).

The idea

                         ┌───────────────────────────┐
                         │           UniPhi           │
                         │      hub (this console)    │   one active
                         └─────────────┬─────────────┘   target at a time
              WiFi / IP grid           │
        ┌───────────────┬──────────────┼───────────────┐
        ▼               ▼              ▼                ▼
  [retrofit WiFi] [retrofit WiFi] [retrofit WiFi]  [network WoL]
   CNC mill        bench serial     remote audio    whole-PC power

Each peripheral keeps its existing wired interface. A **retrofit WiFi

controller** (reference firmware in firmware/, e.g. an ESP32) bolts on and

exposes that wire as a TCP service. The hub speaks one small protocol to all of

them, so adding a new device is config, not code.

Architecture

Built-in adapters

Scale: many hubs, one pointer

One hub focuses one computer. A Fabric (fabric.py)

federates many hubs (8, 80, …) under a single global pointer — exactly one

machine grid-wide has the keyboard/mouse (armed) and full-rate video at any

instant; everyone else is thumbnailed and disarmed. Moving the pointer flips

focus atomically, so bandwidth stays bounded no matter how many hubs.

python -m uniphi.cli --grid 8        # 8 simulated hubs on one pointer

grid                         # show pointer + per-machine video/input state
roam                         # flip the pointer to the next machine
point hub6 pc6               # jump the pointer to a specific machine
key hello                    # keystrokes -> only the machine under the pointer

GUI grid console

A visual video wall (PySide6): the focused machine fills the stage at full

rate; the rest are thumbnails. Click a tile or use ◀ ▶ / Tab to move the

pointer; typed keys go to whoever is focused.

pip install PySide6-Essentials
python -m uniphi.gui --grid 8                      # simulated wall
python -m uniphi.gui --grid 8 --live               # live video of THIS screen on the stage
python -m uniphi.gui --grid-config grid_dongles.example.json   # real dongles
python -m uniphi.media --port 8090                 # screen as MJPEG: http://127.0.0.1:8090/stream

!UniPhi grid console

With --live, the focused stage shows a real MJPEG feed (your screen);

uniphi/media captures → encodes JPEG → serves

multipart/x-mixed-replace, and the GUI pulls frames on a worker thread.

The status bar shows the invariant live: full_video=1 armed_input=1 no matter

how many machines are on the wall.

Run it now (no hardware)

python -m uniphi.cli --demo

Spins up a simulated retrofit controller and a two-machine office. Try:

targets                      # list machines (active marked *)
adapters                     # adapters on the active machine
send write data=G0X10        # data to every data-capable adapter
to ws1-mill gcode line=G28   # gcode to one adapter
use ws2                      # hand focus to the other machine
status                       # full snapshot

Run against real hardware

1. Flash firmware/retrofit_wifi_esp32/ onto an ESP32 wired to your device's

UART; set your WiFi SSID/password and the UART pins/baud.

2. Copy office.example.json → office.json and set each adapter's host to

the controller IPs (and mac for wake-on-LAN).

3. python -m uniphi.cli --config office.json

Retrofit protocol (newline-delimited TCP, default port 3737)

Tests

python -m unittest discover -s tests -p "test_*.py" -v

14 tests: the focus model, capability-filtered routing, the loopback + real-

socket WiFi paths, and the 8-hub fabric (single-pointer invariant: one

full-rate video + one armed input grid-wide, holding as the pointer roams).

Status / roadmap

[x] Core hub, registry, transport, six adapters, simulator, CLI, tests
[x] Input adapter (keyboard/mouse "one pointer") + video adapter (quality tiers)
[x] Fabric: many hubs on one pointer, bounded-bandwidth video
[x] Hardware: KiCad 10 schematics for base + 4 adapter cards + 3 dongles
[x] GUI grid console (PySide6) — video wall, click/roam/type to the pointer
[x] Two product options: base+cards or dongles+software (PRODUCT_OPTIONS.md)
[x] Live media pipe: screen → MJPEG → GUI stage (uniphi/media, --live)
[x] USB dongle layout-ready (footprints + hardware/dongle_usb/LAYOUT.md)
[x] Grid Pack store listings staged (store/, not yet published)
[ ] On-target agent for shutdown/lock/file transfer
[ ] WebRTC/RTSP (lower-latency than MJPEG) + DP-dongle hardware encoder
[ ] Encrypted/authenticated transport for the open WiFi grid

UniPhi Data Center — Status & What Happens Next

_As of 2026-06-27, end of the software-conclusive session._

Where we actually are

Proven, working, tested

Wire transport

Hardware

Repo hygiene

60/60 tests green across the whole project (python -m unittest discover -s tests)
README + RACK.md reflect current truth; no skeletons claim to be more than they are
pyproject.toml ext deps: fastapi, uvicorn, python-multipart, psutil, httpx

What needs to happen FIRST (rationalized)

The temptation is to immediately do hardware. Don't. Hardware costs

real money and weeks of calendar time. Before spending either, prove

the architecture across two physical commodity machines on WiFi —

that's the single highest-leverage validation step and it's free.

The dependency chain

[free, today]            [≤$200, week]              [$500-2k, month]
  ┌─────────────┐       ┌──────────────────┐       ┌──────────────┐
  │ Cross-WiFi  │       │ COTS-hardware     │       │ Custom PCB   │
  │ 2-machine   │ ───>  │ rack (3-8 SBCs   │ ───>  │ fab          │
  │ smoke test  │       │ or PCs)          │       │              │
  └─────────────┘       └──────────────────┘       └──────────────┘
        │                       │                          │
        ▼                       ▼                          ▼
  Validates ENTIRE       Proves the rack          Replaces COTS
  architecture with      scale (8 nodes per       with the patented
  zero hardware risk     hub) on $30 SBCs         form factor

If step 1 fails, every dollar in step 3 is wasted. If step 1 passes,

step 2 is incremental and step 3 becomes a productization decision

rather than an architecture risk.

Step 1: Cross-WiFi smoke test (~1 hour, $0)

Goal: prove the same --mode tcp code that runs in-process

this session works across the LAN between two real machines.

Code prerequisites:

[x] Shared-secret auth on the fabric HELLO/ACK + tunnel handshake.

Landed 2026-06-27: HMAC-SHA256 with a 5-minute timestamp window,

MeshConfig.auth_secret (also read from UNIPHI_DC_SECRET env so

the secret never reaches shell history). CLI: --auth-secret

on hub up and node up. 6 tests cover matching, mismatched,

asymmetric, no-secret-both-sides, and tunnel-auth-after-flip.

[ ] Windows Defender firewall blocks inbound TCP 7800 on first run.

One-time fix:

      New-NetFirewallRule -DisplayName "UniPhi DC hub" -Direction Inbound `
        -Protocol TCP -LocalPort 7800 -Action Allow

[ ] UDP broadcast may not cross some routers / VLANs. Use explicit

--seed <hub-ip>:7800 when broadcast doesn't reach.

Recipe (machine A = hub, machine B = node, both on same WiFi):

# On A: pick a secret once, share it out-of-band, then export it
export UNIPHI_DC_SECRET='change-me-on-real-deploy'    # or set $env:
uniphi-dc hub up --mode tcp --bind 0.0.0.0:7800 \
    --data-dir ./var/hub --api 0.0.0.0:8080

# On B: same secret in env, dial A by its WiFi IP
export UNIPHI_DC_SECRET='change-me-on-real-deploy'
uniphi-dc node up --mode tcp --hub <A-WIFI-IP>:7800 \
    --bind 0.0.0.0:0 --name b1 \
    --data-dir ./var/b1 --cpus 4 --ram-mb 4096

# From any machine on the LAN: open the dashboard
# http://<A-WIFI-IP>:8080/

Pass criteria:

Node b1 appears in http://<A-IP>:8080/v1/nodes within 5 s.
POST /v1/apps with a toy noop.tar.gz returns a placement, and

GET /v1/apps shows it running.

Auth sanity: unset the secret on B and restart it — B must not

appear in the dashboard (rejected at HELLO).

Step 2: COTS-hardware rack (~1 weekend, $0–$200)

Same software, 3+ Raspberry Pis (or any spare PCs) on a WiFi6 AP.

This is the actual "personal data rack" Chris wants — except the

hardware is off-the-shelf instead of the custom board.

What this proves: the rack scales to ~8 nodes (per gen_kicad.py

hub board spec) without changing any Python code. Stress tests:

deploy 16 apps to a 4-node rack and watch the scheduler distribute

them. Kill one Pi mid-flight and watch reschedule.

No new code, just deployment:

[ ] pip install -e . (or pip install uniphi) on each Pi
[ ] systemd unit for uniphi-dc node up so it auto-restarts on boot
[ ] One hub Pi or your laptop runs uniphi-dc hub up
[ ] Add --auth-secret end-to-end (carry-over from step 1)

Step 3: Multi-rack across LAN segments (~weekend, $0)

Two SBC racks in different rooms, both pointed at one SuperHub

process running on a NAS/desktop. This validates the rack-of-racks

abstraction in production, not just in multi_rack_demo.py.

Code gaps:

[ ] SuperHub currently takes Hub objects in-process. For two

machines hosting two racks, SuperHub needs to peer with rack

hubs over the same TcpFabric (same code, different role tag).

~80 LOC. Symmetric to how Nodes peer with Hubs today.

[ ] Auth: super-hub-to-rack-hub uses the same shared-secret model.

Step 4: Decide before fabricating

After steps 1–3, ask:

Does the personal hyperscaler actually feel useful at this scale?
Is the ESP32-S3-on-rack-hub form factor better than just running

the hub on one of the CM5 nodes (eliminating the hub board entirely)?

Do we need the OLED + 8-LED hub UI, or is the FastAPI dashboard

enough?

If yes, fab. If no, the answer might be "ship UniPhi DC as

software-only" — same patent, same product page, no $2k mistake.

Step 5: PCB fab (~$500–$2k, 3–6 weeks)

Only after step 4 says yes. Order of operations:

1. KiCad layout wifi_data_center first (it's the higher-volume

board; you need 8 of them per rack). Send to JLCPCB / OSHpark.

2. Bring up one node board with real CM5. Verify USB-C PD, microSD,

GbE, ESP32-C6 radio handshake.

3. THEN lay out wireless_data_center — informed by what you

learned bringing up the node board.

Step 6: Firmware-on-S3 for the rack hub (~month)

Convert the rack hub from "Python-on-CM5-adjacent" to "Python (or

ESP-IDF native) on the S3 itself". MicroPython has TCP socket support

sufficient for the fabric protocol. Until this works, every rack

needs one host computer beside the hub board to run the orchestrator.

Risks worth naming

TL;DR: the next thing to do

1. ~~Add shared-secret auth.~~ ✅ Done. Then Home Edition (F1-F13)

fully shipped, then DC enterprise track (persistent state, metrics,

structured logs, advanced scheduler, mTLS, RBAC, benchmarks)

fully shipped. Repo at 130/130 green as of 2026-06-27.

2. Hardware silicon path is now in its own project at

C:\Users\crione\Chris\special\54-wifi-accelerators (WiFi

Accelerators / WFA-Node / WFA-Hub / WFA-Mesh / planned WFA-Apex).

Separate catalog, separate IP, separate store listings.

3. Validation block to revisit when ready: cross-WiFi 2-machine

demo on real hardware now that F1 auto-retry + F2 mDNS + F3

pairing + F4 firewall installer make it self-healing. Recipe is

still above.

4. Remaining DC enterprise candidates (not blockers):

Hub active/passive HA (leader election across two hub processes)
EC storage (replace N=3 replication with erasure-coded chunks)
Real-cluster demo on commodity SBCs (Pi 5 cluster) once you

bring a few Pis online.

The cross-WiFi router pain that blocked us originally is now

software-handled by F1+F2+F3+F4+F10 in the Home Edition stack.

UniPhi DC -- Home Edition — store listing

For pasting into cri-one.com/store (Magento). Copy follows the

established store rules: patent-pending, design target,

email + postal only / no phone, USA-only / USD, **no IP or

patent license sale** (delivery is software + blueprints + setup help,

not IP transfer). Patent-pending IP retained.

SKU summary

All three SKUs deliver the same software. The delta is human help.

Same store category as the flagship UniPhi listings:

Consumer Electronics + Featured & New.

Product title

UniPhi DC -- Home Edition (Personal Hyperscaler for Your Home WiFi)

Short tagline (under image)

Turn every PC and Mini-PC in your house into one cooperating

data-center rack -- over WiFi. Patent-pending. Software + blueprints,

USA-only.

Long description (~5,000 chars, HTML)

<h2>One install, every PC in your house cooperates.</h2>

<p>UniPhi DC -- Home Edition is the personal hyperscaler that lives
on your home WiFi. Drop it on the spare desktop in the office. Drop it
on the gaming PC in the basement. Drop it on the Mini-PC behind the
TV. They find each other automatically and become <strong>one rack
under one dashboard</strong>: shared CPU, shared storage, shared apps,
moved transparently between machines as you reboot, unplug, or roam
the house.</p>

<p><strong>Patent-pending</strong> under U.S. Application No.
19/717,706 (Confirmation No. 7171). All intellectual property remains
with the inventor; this listing sells a perpetual single-household
software license plus complete blueprints for deployment.
<em>It is not a patent license, IP transfer, or commercial deployment
right.</em> The patent-pending fabric, scheduler, and rack-of-racks
architecture stay the inventor's property.</p>

<h2>What you do (this is the whole instruction):</h2>
<ol>
  <li>Download the .zip from your order confirmation. Extract.</li>
  <li>Double-click <code>install-hub.bat</code> on the always-on
      machine. Accept the UAC prompt -- it installs a firewall rule
      and a Scheduled Task so the hub auto-starts on every boot.</li>
  <li>Note the 6-digit pairing code the installer prints.</li>
  <li>On every other machine, copy the folder and double-click
      <code>install-node.bat</code>. Enter the code. Done.</li>
  <li>Open <code>http://localhost:8080/</code> in your browser to
      see the dashboard.</li>
</ol>

<p>That's the whole user manual. No IP addresses. No environment
variables. No admin PowerShell. No installing Python.</p>

<h2>What's in the box (digital delivery by email):</h2>
<ul>
  <li>Single signed-ready Windows installer
      (<code>UniPhi-DC-Home-Edition-Setup.exe</code>) -- 33 MB</li>
  <li>Or the portable folder
      (<code>UniPhi-Home-Edition.zip</code>) for users who prefer no
      .msi install</li>
  <li>Tray app (green / yellow / red status icon)</li>
  <li>One-command troubleshooter (<code>uniphi-dc doctor</code>) that
      diagnoses the 13 most common home-WiFi gotchas in 5 seconds</li>
  <li>Auto-discovery (mDNS) so new nodes find the hub without any IP
      typed</li>
  <li>Auto-retry / auto-reconnect so reboots, WiFi roams, and DHCP
      renewals self-heal</li>
  <li>Auto-firewall on first run (single UAC prompt)</li>
  <li>HMAC-derived pairing-code authentication</li>
  <li>FastAPI dashboard with live nodes / apps / pairing code panel</li>
  <li>Full <strong>blueprint</strong> documentation: 13-problem to
      13-fix mapping (UNIPHI_HOME.md), 3-altitude architecture
      diagram (RACK.md), patent-faithful schematics for the
      <em>Wireless Data Center</em> rack hub board and CM5 node carrier
      board</li>
</ul>

<h2>Design target (not warranties):</h2>
<ul>
  <li>Up to <strong>8 nodes per rack hub</strong></li>
  <li>Up to <strong>3 racks per super-hub</strong></li>
  <li>Designed for Windows 10/11 home and Pro editions</li>
  <li>Designed for typical residential WiFi 5 / WiFi 6 / WiFi 6E
      routers</li>
  <li>Designed for Raspberry Pi 4 / Pi 5 / CM5 + x86 mini-PC nodes</li>
</ul>

<h2>What's NOT included:</h2>
<ul>
  <li>Patent license. The patent-pending IP under U.S. App.
      19/717,706 is retained by the inventor. This SKU does not grant
      any right to manufacture, sublicense, or commercially deploy
      based on the patent claims.</li>
  <li>Commercial deployment. Home Edition is licensed for a single
      household, non-commercial residential use. For commercial /
      OEM / multi-tenant / multi-site deployments, see the flagship
      UniPhi listings.</li>
  <li>Telephone support. Email-only.</li>
  <li>International shipping or international support. USA-only.</li>
</ul>

<h2>How to order</h2>

<p>Email <a href="mailto:crioneaka@outlook.com">
crioneaka@outlook.com</a> with subject line
<code>UniPhi Home Edition</code> and the SKU you want. Payment
arrangements by reply. Delivery is by email; the .zip and install
guide arrive in your inbox once payment clears.</p>

<p>Postal contact:<br>
Christopher Gabriel Brown<br>
1341 Wellington Cove<br>
Lawrenceville, GA 30043-5255<br>
USA</p>

<p>Patent-pending under U.S. Utility Application No. 19/717,706
(Confirmation No. 7171, filed 2026-06-24). USA-only sales.</p>

Image checklist (1200×1200 each, white/black/grey patent style)

[ ] Dashboard screenshot in the new Home Edition skin (header, 4

summary cards, nodes table, "Pair a new machine" button)

[ ] Tray icon screenshot — green, yellow, red side-by-side
[ ] 3-altitude block diagram (node ↔ rack hub ↔ super-hub)
[ ] "What you do in 4 steps" infographic
[ ] Pairing code modal screenshot

Download artifact

File: dist/UniPhi-DC-Home-Edition-v0.2.0.zip
Size: 37.0 MB (grew from 33.2 MB after the enterprise-track features

landed: mTLS via cryptography, RBAC, advanced scheduler, Prometheus

metrics, persistent event log)

SHA-256: bdd9ed5f1f2f77cdaebcd51c9bdbfca1ac5418de811ec4862632ea5e78415348
CLI surface includes: hub, node, status, app, logs,

cp, dashboard, doctor, install, uninstall, service,

tray, rbac, bench.

For a real customer download flow, host the file outside the store

(S3 / B2 / signed URL emailed on order). The store SKU itself stays a

virtual product with email-after-payment delivery — same pattern as

the rest of cri-one.com/store.

Benchmark evidence (measured on 80-core Windows host, 2026-06-27)

Numbers below come from uniphi-dc bench on real-TCP loopback. LAN

adds about 0.3-0.5 ms RTT vs loopback; treat these as upper bounds

on what a same-rack LAN delivers in practice.

Reproducible: uniphi-dc bench --scale 1,2,4,8 --apps 30 --output bench.md.

Full markdown report shipped with every install at

BENCH_RESULTS.md in the repo root; JSON results at

BENCH_RESULTS.json for trend tracking.

Enterprise-grade architecture claims (all backed by tests in repo)

Real distributed fabric: TCP transport with HMAC-shared-secret

auth + mTLS option (per-peer X.509 certs, FRAND-clean), mDNS auto-

discovery, exponential-backoff dial loop, adapter-change re-publish.

14 fabric tests pass.

Real N=3 storage replication: content-addressed sha256 chunks

pushed over per-tunnel TCP connections. Re-replication on node

loss. 4 storage tests pass.

Hub crash-resistant: append-only JSON-Lines event log with

sha256 hash chain + fsync-on-every-write. Replays on startup to

the exact pre-crash state. Snapshot/compaction keeps the log

bounded. 5 persist tests pass, including a crash-recovery proof

that kills the hub mid-flight and verifies all 5 apps + 3 nodes

come back. Audit-grade: tail -F state.log or ingest into SIEM.

Real observability: Prometheus /metrics endpoint with

counters, gauges, histograms (no third-party deps), structured

JSON logs with trace IDs. 11 metrics tests pass.

Real rack federation: SuperHub composes N rack hubs; rack-loss

recovery moves orphaned apps to a surviving rack. 2 rack tests +

a multi-rack demo.

Real resource enforcement: POSIX setrlimit(RLIMIT_AS) +

psutil RSS watchdog + CPU affinity. App that exceeds its

manifest.ram_mb cap is killed by the watchdog within 250 ms. 2

cap tests pass.

Real advanced scheduler: hard constraints (require_labels,

anti_affinity), soft preferences (spread_key + topology buckets),

priority-aware batch placement. 7 advanced-scheduler tests pass.

Real RBAC + multi-tenant: roles (admin/operator/viewer/tenant),

per-tenant quotas (max_apps, max_ram_mb), salted-sha256 bearer

tokens. Empty rbac.json = open mode (backward compatible). 13

RBAC tests + CLI helpers (uniphi-dc rbac tenant create,

user create, token mint).

Repo-wide: 130 tests passing (run `python -m unittest discover

-s tests` to verify).

Pricing rationale

Flagship UniPhi listings (Software $300k, Complete bundle $1M) sit at

the enterprise altitude per "price it like I own it" framing. Home

Edition is a separate market segment: residential, non-commercial,

single-household, no patent rights. The three Home tiers ($199 / $999

/ $2,499) bracket the value of human help, not of the software itself.

The three tiers also enable upsell on the order page without

fragmenting the catalog: software is one product, time is the other.

Customers self-select.

Categories (Magento)

All Home Edition SKUs land in a new dedicated category called "UniPhi WFA"

(created by store/create_uniphi_wfa_category.py if not already present),

plus the two established browse paths so existing category pages continue

to surface the listings:

UniPhi WFA (new — anchors the full UniPhi + WFA family)
Consumer Electronics (id 93, browse-by-sector)
Featured & New (id 97)

The new category is the primary navigation home for the family. Existing

flagship UNIPHI-COMPLETE is added to "UniPhi WFA" too as the anchor SKU

without removing it from its current categories.

Tax / shipping / countries

Tax: per existing store config (USA-only, state tax via Magento).
Shipping: none (digital delivery).
Countries allowed: USA only (per existing store geo-block --

see [[human-id-geoblock]] memory).

UniPhi DC — Home Edition

A version designed for "I plugged in two computers, push the button, done."

Origin

This document was written 2026-06-27 after we spent ~4 hours making

two real machines (Dozer + alfa) talk to each other through Chris's

home network. Every minute of that pain was a real-world problem a

home user would hit. UniPhi DC core works perfectly — 66 tests pass,

end-to-end deploy/reschedule/replication all green — but the path

from "I installed it" to "two computers see each other" exposed

13 distinct gotchas, none of which were the software's fault and

all of which are solvable.

This document enumerates every one, then prioritizes the fixes.

Problems we hit (ranked by pain)

Total: ~3.5 hours of pain. Target Home Edition: same path in under 5 minutes per machine, no IPs typed.

Home Edition feature set

Each item lists which problem(s) it eliminates.

Tier 1 — biggest pain reductions (build these first)

F1. Auto-retry dial loop with exponential backoff ✅ SHIPPED 2026-06-27

Fixes: #4 (silent fail) + #8 (IP change recovery)

The node never gives up. It dials, fails, waits 5 s, redials. If five

attempts in a row fail, backs off to 10 s, then 30 s, 1 min, 5 min cap.

Resets to 0 on every successful connection so a stable peer that flaps

once doesn't get punished. Auto-reconnect after session drop is in the

same loop — when the writer disappears from _writers, the loop redials.

Implementation: TcpFabric._dial_loop(addr) in

fabric.py. Backoff schedule and connect timeout

are module-level constants so tests can speed them up. _dial_observer

hook lets the dashboard + troubleshooter watch progress without

scraping stderr. 3 tests in

tests/test_dc_fabric_retry.py cover

dial-then-listen, backoff-increments, and reconnect-after-restart.

F2. mDNS / Bonjour discovery ✅ SHIPPED 2026-06-27

Fixes: #5 (no manual IP) + #1 (subnet split detection) + the

"HomeGroup is gone" problem Microsoft created in Windows 10 1803

Hub publishes _uniphi._tcp.local. over Zeroconf with its IP + port.

Node sniffs the same. UX: instead of --hub 192.168.1.95:7800, just

--hub auto. Node finds the hub the way Chromecast / Sonos / printers

do — same protocol Windows itself can't manage to use for its own LAN

since they killed HomeGroup.

Implementation in uniphi/dc/mdns.py:

HubAnnouncer publishes after the fabric binds; NodeDiscovery browses

and returns HubAdvert(name, addr, properties). CLI:

uniphi-dc hub up auto-announces (suppress with --no-mdns,

override the rack name with --mdns-name). `uniphi-dc node up

--hub auto` LAN-discovers and connects. 2 tests in

tests/test_dc_mdns.py — skip if zeroconf

isn't installed.

F3. 6-digit pairing code → derived secret ✅ SHIPPED 2026-06-27

Fixes: #12 (manual env var)

Hub auto-mints a 6-digit code per data_dir on first run, persists it

in .pairing.json, prints it boxed on startup. Node CLI takes

--code 123456 or --pair-code 123-456. Both sides PBKDF2 the code

(salt uniphi-dc-v1, 1M iters, 32-byte key) into the same hex secret

that MeshConfig.auth_secret already uses.

Implementation in uniphi/dc/pairing.py, CLI

flags --pair-code / --no-pairing on hub up and

--pair-code / --code on node up. 8 tests in

tests/test_dc_pairing.py.

F4. Self-installing firewall rule (UAC prompt on first run) ✅ SHIPPED 2026-06-27

Fixes: #7 (manual admin PS)

uniphi-dc hub up calls `firewall.ensure_rules_windows([bind_port,

api_port], data_dir)` which queries existing rules, and if missing

fires one Start-Process -Verb RunAs UAC prompt to add them

idempotently. A skip marker (.uniphi-firewall-skip) under the data

dir means "I'll do it myself, never ask again". CLI flag

--no-firewall-prompt for headless installs.

Implementation in uniphi/dc/firewall.py.

F5. Run-as-service ✅ SHIPPED 2026-06-27

Fixes: #8 (DHCP change recovery on reboot)

uniphi-dc install hub|node [args] persists args to

%APPDATA%\UniPhi\{role}.json and registers a Windows Scheduled Task

(schtasks /SC ONSTART /RL HIGHEST /F) that runs as SYSTEM, falling

back to the current user if the SYSTEM registration fails.

uniphi-dc uninstall hub|node --name X removes. `uniphi-dc service

status reports last-run / next-run. On POSIX, install` drops a

ready-to-use systemd unit file with Restart=always and

network-online.target ordering.

Implementation in uniphi/dc/service.py; 5 tests

in tests/test_dc_service.py.

Tier 2 — quality of life

F6. Auto-detect local IP, bind 0.0.0.0 by default ✅ SHIPPED 2026-06-27

Fixes: #5

hub up now resolves the host's non-loopback IPv4 (via the

socket.connect trick toward a public IP) and prints two banner

lines right after [hub] up...:

[hub] Dashboard:   http://192.168.1.95:8080/
[hub] Fabric port: 192.168.1.95:7800

Works even when --bind 0.0.0.0 hides the real address. Code in

uniphi/dc/cli.py (_cmd_hub_up).

F7. Built-in network troubleshooter ✅ SHIPPED 2026-06-27

Fixes: #1, #2, #6, #13 (visibility into router weirdness)

uniphi-dc doctor [--hub host:port] [--auth-secret X] runs every

check we manually ran during the alfa debug session:

local: Python version, deps, port-free, firewall rules, mDNS, IPv4

pick, active adapters

remote (when --hub given): mDNS discoverable, ICMP ping, TCP

reach, real fabric HELLO+ACK handshake, ARP-based AP-isolation hint

Prints PASS/WARN/FAIL/SKIP per check + a fix hint per non-PASS + a

final verdict line. Exits non-zero on any FAIL so CI can gate on it.

Implementation in uniphi/dc/doctor.py. 3 smoke

tests in tests/test_dc_doctor.py.

F8. Bundled Python via PyInstaller ✅ SHIPPED 2026-06-27

Fixes: #11 (install pain)

scripts/build_exe.py produces dist/uniphi-dc.exe (one-file, ~35 MB)

bundling Python 3.12 + uniphi + fastapi + uvicorn + psutil + zeroconf

pystray + Pillow. Also writes dist/UniPhi-Home-Edition/ — a

ready-to-zip folder containing the .exe plus README, install-hub.bat,

install-node.bat (interactive pairing-code prompt), tray.bat,

doctor.bat, uninstall.bat. Drag-drop deploy. Unsigned by default —

real public release should signtool sign with a code-signing cert

(documented in the script header).

F9. Unbuffered stdout by default

Fixes: #10

CLI sets sys.stdout.reconfigure(line_buffering=True) at startup so

piped output flushes per line. ~3 LOC.

F10. Adapter-change detection → rebind ✅ SHIPPED 2026-06-27

Fixes: #8

TcpFabric starts an _adapter_watcher task that polls

psutil.net_if_addrs() every 5 s. On any change to the set of

(iface, ipv4), all callbacks registered via

fabric.on_adapter_change() fire. The hub CLI registers

HubAnnouncer.republish so the mDNS service record swaps to the new

IP automatically — WiFi roam, DHCP renewal, adapter swap all

self-heal without operator intervention.

Implementation in uniphi/dc/fabric.py (search

_adapter_watcher); 2 tests in

tests/test_dc_fabric_adapter.py.

Tier 3 — polish

F11. Tray app GUI ✅ SHIPPED 2026-06-27

A pystray icon — green when nodes are connected, yellow when the

hub is up but empty, red when the hub is down. Menu: Open dashboard,

Show pairing code (read from .pairing.json), Run troubleshooter

(spawns doctor in a fresh console), Quit. Polls /v1/healthz

every ~5 s.

Implementation in uniphi/dc/tray.py; 3 tests

in tests/test_dc_tray.py (skip if pystray

isn't installed). CLI: uniphi-dc tray --api 127.0.0.1:8080.

F12. One-page installer .msi ✅ SHIPPED 2026-06-27 (compile-time)

Single Windows installer that:

Installs the bundled .exe to %PROGRAMFILES%\UniPhi DC
Installs the Scheduled Task / Service (optional checkbox)
Sets the firewall rule via netsh (always)
Adds Start Menu shortcuts: Dashboard, Tray, Doctor, Pair a new machine, Uninstall
Post-install: opens the dashboard in the user's browser

Implementation: scripts/uniphi-dc-installer.iss

-- Inno Setup 6 script. To compile:

ISCC.exe scripts/uniphi-dc-installer.iss

Output: dist/UniPhi-DC-Home-Edition-Setup.exe. Inno Setup compiler

isn't shipped with this repo (free download from jrsoftware.org); the

.iss file is the build artifact.

F13. "Home Edition" branding + dashboard skin ✅ SHIPPED 2026-06-27

Reskinned _DASHBOARD_HTML in uniphi/dc/api.py:

dark-blue palette with cyan accents, 4 summary cards at top (Nodes

online / Apps running / Total CPU cores / Total free RAM), prominent

"+ Pair a new machine" button that opens a modal showing the

hub's pairing code + the exact node-side command. New /v1/pair-code

endpoint exposes the code from the persisted .pairing.json (F3).

State colors (ready / lost / joining / running / pending / failed)

applied per cell. Mobile-responsive layout. Test updated in

tests/test_dc_api.py.

Recommended implementation order

1. F1 (auto-retry) — biggest single-point-of-pain reduction. ~50 LOC. Tonight if you want.

2. F2 (mDNS discovery) — kills the "type the IP address" step. ~50 LOC.

3. F3 (pairing code) — kills the "type the secret" step. ~20 LOC.

4. F4 (UAC firewall) — kills the "open admin PowerShell" step. ~30 LOC.

5. F5 (service) — kills the "remember to start it after reboot" step. ~80 LOC.

6. F7 (doctor) — diagnostic-time savings. ~150 LOC.

7. F8 (bundled exe) — true one-click install. Build pipeline, ~half a day.

Each is independent; ship them as they land.

What "Home Edition" doesn't try to do

Industrial-grade security (no mTLS, no per-peer cert provisioning —

the 6-digit code is good enough for a household, not for a hospital).

Multi-tenancy (one household, one fabric).
Cloud relay (no NAT-traversal via a third-party relay; if your

router fully isolates devices, you fix the router).

Pricing implication (you'll like this one)

Right now the store sells UniPhi software at flagship prices ($300k+,

patent-retained). Home Edition could be a separate SKU at consumer

prices ($99–$999) for the **per-household, non-commercial, residential

use license**. Same core code, different installer, different EULA,

different audience. Existing flagship buyers (commercial, OEM, IP

acquirers) don't conflict with Home Edition residential users.

That's a real market: "I have 3 computers and a Pi and I want them to

act like one machine."

UniPhi Adapter — Common Layout Notes

Rev 0.1 · 2026-07-03

Layout guidance shared across all UniPhi adapter cards (adapter_cnc, adapter_gpio, adapter_serial, adapter_video, and any future adapters). Board-specific SPEC.md files call this file by reference.

Common form-factor

All adapter cards target a common outline family:

All adapters share a 40-pin 2 mm-pitch dock connector at the "bottom" edge (interfacing with the Base Controller socket) and (optionally) a 12V barrel jack for standalone operation.

Common component set

Every adapter carries:

1× ESP32-C3-MINI-1 (or ESP32-S3 on high-BW variants like adapter_video).
1× Microchip 24AA02E48 ID-EEPROM (EUI-48 canonical ID).
1× TPS62A02 3.3 V buck (from 5 V spine when docked, or from standalone 12 V after upstream 12 V→5 V buck).
1× 40 MHz XTAL for ESP32-C3.
Status LEDs (green + amber + red).

Common stack-up (4 layers, shared by 4-layer adapters)

Adapter_video uses a 6-layer stack (add Sig3 = HDMI TMDS diff pairs, Pwr2 = HDMI 1V8 rail).

Dock connector pinout (all adapters)

EMC / EMI

ESP32-C3-MINI-1 pre-certified module (FCC / CE / IC / MIC) — no radio recert needed.
Adapters with high-current outputs (adapter_cnc motor drivers, adapter_gpio relay bank) need adequate return-current paths on Gnd1 layer.

Assembly

Single-sided SMT + selective wave for through-hole.
Panelization: whatever the CM chooses; 6-up recommended on 320 × 400 mm panel for the 80 × 50 and 100 × 60 adapters.
2-3 fiducials at corners.

Firmware slot

Every adapter reports its PORT_TYPE (CNC, GPIO, SERIAL, VIDEO, ...) and version via I2C ID-EEPROM on the dock. The Base Controller uses this to load the correct fabric driver for the port.

Deferred (buyer / CM scope)

PCB layout per adapter (or 1 shared layout template).
Gerbers.
Enclosure design per adapter.
End-product certifications (only relevant if the adapter is sold as a stand-alone product, not as a card).

This archive contains 54 documents; 45 more beyond this preview. The complete folder ships as the product.

Reviews

Write Your Own Review