Projects: work packages and part bins

Every project here is a long road. To make an afternoon count, each is cut into work packages sized to the time at hand, and each package has its own bin holding every part it needs. Free afternoon → pick a bin whose prerequisites are done → start.

Follow what inspires

There will always be more projects than time. This table is a menu, not a queue: pick what's exciting that day; switch, expand, refocus or drop freely. Nothing here has a deadline, and an unfinished package costs nothing as long as its log says where it stopped.

Remembering across months

• Each bin is a file (bins/): its next step at the top, a parts checklist (needed / ordered / in the bin), what was learned, and its sessions, newest first. It grows as long as the interest does: more sections, more parts, or a spin-off package with a file of its own.
• End every session with a two-minute note in the bin's file: what got done, the very next step, open questions, what was learned. It's what makes the next afternoon start in minutes, not an hour of re-reading.
• A card in the physical bin: the code, the next step, a QR to its file. Opening the bin shows where to start.
• Learning electronics as you go: each bin file keeps what was learned and the links that helped; learning.md collects the concepts across packages.
• Ask Claude "where was I on F100-F1?": it reads the bin file and the repo and picks up the thread.

How it works

• A package is one sitting: A (afternoon, ~4 h), D (a day), W (a weekend).
• A bin per package, labelled with its code (e.g. F100-F1) and a QR code to its file in bins/. Parts go in the bin when they arrive, not on a shelf.
• Ready = every part in the bin and every prerequisite done. Mark it ready on the bin label (a dot) and in its file.
• Shared consumables (wire, terminals, fuses, heat-shrink, zip ties) live in one consumables crate, restocked from shopping.md; bins hold only what's specific to the package.
• Done means the "done when" line is true; the bin file stays as the record, and the physical bin empties back into stock.
• Later: an ASP chooser, "I have 4 hours, what's ready?", over this table.

Packages

Order of value, roughly: HUB-1, 4R-1, DF-1, DF-2, F100-F1, CAN-1. Each stands alone.

* Menu:

* HUB-1::      NixOS on ThinkCentre 1: WireGuard, MQTT, misra
* HUB-2::      Shore-heat outlets: 3 local smart plugs/relays, schedule on the hub
* 4R-1::       Vehicle box: Pi 5 + SSD + 12 V buck, NixOS, Victron Bluetooth readout
* 4R-2::       Fridge circuit shunt and its logging
* 4R-3::       ARB fridge Bluetooth: scan, sniff, decode what we can
* 4R-4::       GPS (u-blox USB, gpsd) and the cellular router, dial home
* 4R-5::       Gobi rack plate: 70 cm and 2 m rings, solar-charger RF noise check
* 4R-6::       Fridge experiment, first week of runs
* DF-1::       KrakenSDR bench bring-up at home, 70 cm magnetic-mount ring
* DF-2::       Tape-measure Yagi (2 m) and offset attenuator builds
* DF-3::       Android Auto app: skeleton with bearings over the map (developer mode)
* DF-4::       Chevy DF gauge: round display on an ESP32, needle from the bearings
* F100-F1::    Second battery: tray, DC-DC charger, fusing, shunt
* F100-F2::    Headliner Bluetooth audio from the house battery
* F100-F3::    Shore inlet, GFCI, block heater (fit or test)
* CHEVY-C1::   Isolated 12 V house system: battery, solar panel, shore charger, relay off the 6 V ignition
* CHEVY-C2::   Dash Bluetooth audio from the 12 V side
* CHEVY-C3::   Shore inlet and block heater
* CAN-1::      Bench CAN bus: two ESP32 nodes, transceivers, the Pi logging
* CAN-2::      Wideband air/fuel sensor (CAN output) on the F100
* CAN-3::      Temperatures, oil pressure, RPM (opto) on the F100
* SDR-1::      GNU Radio basics with an RTL-SDR: a 2 m FM receiver and a waterfall
* SDR-2::      Ternary modem prototype in GNU Radio: loopback, then on the air within Part 97
* PROD-1::     First KiCad board: the CAN sensor node as an open design