Control Panel: Workcell - docs/ssh-step-explainer.txt

by Caleb

Control Panel: Workcell — Raspberry Pi CM5 carrier and smart power-distribution hub for Adom workcells. Four metered supply inputs (4× INA228, 20-bit) feed a switched, isolation-capable rail set delivered to the docked Control Panel: Scaffold over a Samtec ET60 blade dock with SWD/UART debug and RP2350 boot/reset control. On board: gigabit Ethernet, M.2 Wi-Fi + Bluetooth, USB-C/USB-A 3.0 with eFuse-protected VBUS, CAN FD, an 18-LED camera-feedback ring, and nested molecule slots for a PiProbe v1

Overview Files Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Download

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

SSH STEP EXPLAINER — Control Panel Test Procedure step 1.5.6
=============================================================

WHAT THE STEP ASSUMES
---------------------
Yes — it assumes the link-partner PC is already connected to the board by
the Ethernet cable. Specifically:

1. The 90 m Ethernet cable is plugged between the board and the link-partner
   PC (done in 1.5.1). SSH runs over this same cable — the point of the step
   is that the *link under test* also carries a real interactive session.
2. Both ends have IP addresses on the same subnet. If there is no DHCP
   server on the bench, set static addresses:
     on the PC:    sudo ip addr add 192.168.10.1/24 dev <eth-interface>
     on the board: sudo ip addr add 192.168.10.2/24 dev eth0
   (run on the board via the USB-UART debug console, which works without
   any network).
3. The board's SSH server is enabled in the OS image (it is in the release
   build) and you know the image's username/password (release notes).

WHY THE STEP EXISTS
-------------------
iperf3 (1.5.3) proves raw throughput, but a stalled or renegotiating link
can still pass short iperf bursts. A held-open SSH session is a cheap
canary: any link drop kills or freezes the session immediately, and the
50-cycle flap loop in 1.5.5 must not take the session down permanently
(TCP should survive brief down/up transitions or reconnect cleanly).

WHAT "FAIL" LOOKS LIKE
----------------------
- The session freezes for more than ~10 s during 1.5.3 (throughput test).
- "broken pipe" / "connection reset" while the cable was untouched.
- After 1.5.5 completes, a new SSH session cannot be opened.

RELATION TO THE REST OF THE PROCEDURE
-------------------------------------
Once 1.5.6 passes, every later section may be run over SSH instead of the
USB-UART console (§0.3). The debug console remains the fallback whenever
the network is deliberately disturbed.