Project
Layout Feedback
Sensor and IO nodes that report what the layout is doing over MQTT.
- Status
- active
- Platform
- RP2040 / RP2350 · MicroPython
- Source
- bazauto/layout-feedback
Stub. To be written up after a design interview.
Decisions
- acceptedBuild our own active-high block detector
· Off-the-shelf detectors pull low for occupied, so a broken wire under the layout reads as a clear block. A home-designed board with an active-high output makes that fault read as occupied instead.
- acceptedThe block detectors' Input A is left unpowered, against the datasheet
· Powering an LM-iD.1's Input A, as every datasheet says to, makes its output idle at 5V into 3.3V expander inputs. It's deliberately left unpowered on Westgate Hollow.
- acceptedMQTT for hardware, WebSocket for operators
· Sensors and point feedback talk to the orchestrator over MQTT under a binding contract. Operator devices, including the handheld throttle, use the orchestrator's WebSocket control plane.
- acceptedPoints are commanded by one device and read back by another
· Cobalt iP point motors take DCC commands but can't report their position, so position comes from their S2 contacts on a feedback node. That catches hand-thrown points, but creates two mappings nothing cross-checks.
- acceptedSensor nodes publish only the sensors that are actually wired
· An unwired expander input reads as "clear", so publishing the whole pin table would tell the orchestrator a block is empty using a wire that doesn't exist. Nodes publish an allow-list instead.
- acceptedSensors must keep talking, and silence is treated differently from lying
· Every sensor re-sends its reading at least every 30 seconds. A silent sensor degrades only its own blocks, while a garbled message Safe-Stops the layout.
Log
Nothing logged yet.