rjmcmahon
/
FiWiControl
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs(readme): explicit Pi5+iperf2 and ESP32 802.11 telemetry sections 

Made-with: Cursor
This commit is contained in:
Robert McMahon 2026-04-10 19:07:35 -07:00
parent 13c3e4cf0d
commit 2db7d822cc
1 changed files with 14 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
README.md
View File

@ -16,9 +16,21 @@ A **first concrete goal** for this stack is to support **PCIe hot-swap (hot-plug
That work fails if the bench is informal—wrong port, wrong power path, or no shared picture of what was connected when. FiWiControl targets that gap by combining **documented inventory** (INI + **`--verify-inventory`**), **remote automation** (**`ssh_node`**, **`python3 -m fiwicontrol.commands`** to bring up rigs), and **programmable power / USB paths** (**`fiwicontrol.power`**) so sequences are **scripted and checkable** before the PCIe harness runs. Longer term, **SPC** (below) is meant for **many hot-plug cycles**—spotting drift in failure rates or side metrics—not only general Fi‑Wi bring-up.
**Immediate roadmap:** a **fleet of Raspberry Pi 5** boards as the primary **lab rig controllers** (remote **`fiwicontrol`** install, discovery over SSH, PCIe / Fi‑Wi harness hosts—docs and examples already assume Pi-class rigs), running **iperf 2** for **synthetic traffic** during network and bring-up experiments. Next: **ESP32** integration for **telemetry** (sensors, counters, rig health alongside those runs) and expanded **ush** orchestration alongside OpenSSH—not only the **`ush`** transport already wired through **`ssh_node`**, but first-class tooling for benches that standardize on **ush**. Beyond today’s Pi-oriented install path, **`ssh_node`** **`ush`** transport, and inventory/CLI stack, the rest is still roadmap.
## Lab fleet: Raspberry Pi 5 and iperf 2 (planned)
**Product differentiation:** we expect **advanced telemetry** and **advanced use of iperf 2**—load and measurement patterns tied to rig state, inventory, and (eventually) SPC, not only ad hoc throughput runs—to help **differentiate** Umber Fi‑Wi products in the market.
We expect a **fleet of Raspberry Pi 5** boards as the primary **lab rig controllers**: remote **`fiwicontrol`** install, discovery over SSH, PCIe / Fi‑Wi harness hosts (docs already assume Pi-class rigs). Those Pi 5s will run **iperf 2** as **synthetic traffic** endpoints—controlled load and measurement during Fi‑Wi and bring-up experiments, not one-off manual runs. **None of this is automated in-repo yet** beyond what you can already drive by hand over **`ssh_node`**; first-class orchestration and reporting are roadmap.
## ESP32, IEEE 802.11, and advanced telemetry (planned)
Separately from the Pi 5 **`iperf`** plane, we plan **ESP32**-based nodes for **advanced telemetry**, including rich use of **IEEE 802.11 (Wi‑Fi)**: airlink statistics, channel / PHY-adjacent metrics, retries, timing, and correlation with harness and inventory state. The goal is lab- and field-grade **802.11 telemetry**, not only GPIO or serial counters. **This stack is not implemented yet** in **`fiwicontrol`**; today’s code is still the commands / lab / power packages above.
## `ush` expansion (planned)
Expanded **ush** orchestration alongside OpenSSH—not only the **`ush`** transport already wired through **`ssh_node`**, but first-class tooling for benches that standardize on **ush**. Roadmap only beyond today’s transport path.
## Product differentiation
We expect **advanced telemetry** (including **802.11**-centric ESP32 data) and **advanced use of iperf 2 on Raspberry Pi 5** hosts—patterns **tied to rig state, inventory, and (eventually) SPC**, not ad hoc throughput screenshots—to help **differentiate** Umber Fi‑Wi products in the market.
## Statistical process control (planned)