How are you sequencing first power-on across avionics, HUMS, and mission systems to minimize nuisance faults and finger‑pointing? We’re aligning ARINC 429, 1553, and Ethernet nodes on a bench rig before moving to two aircraft in February, and I’d value your gating criteria and who you seat at the console for the first 30 minutes.
I’d gate on a “silent bus” check: power PDM and the switch first, then require 3 minutes with only expected heartbeats (no stray 429/1553 frames, zero Ethernet link flaps) before letting any talkers come alive — cuts HUMS gremlins by half in my experience… Seat the bus‑monitor operator at the console for the first 30 minutes, not the avionics lead; are you locking switch ports to fixed speed/duplex and killing LLDP on day one?
After the silent-bus window, I hard-gate on time: don’t bring up mission/HUMS until the time master shows “PTP/IRIG locked” steady for 60 s and GNSS has a 3D fix — saves a lot of ghost-hunting later. For the first 30 minutes, I put the time-sync owner at the keyboard and the HUMS lead on the 429/1553/Eth capture so we can correlate faults live, with avionics standing by to flip auto-BIT off if it starts chattering. @tina_kline95 do you also freeze NVM writes on first power to keep the baseline clean?
Add inline power monitor on the bench rig: 28V ±0.5V, <50 mV ripple; seat network + bus-controller SME, @james_cooper60.
I’ve had good luck inserting a small “dependency shim” on the bench switch that advertises time/nav presence and publishes keepalives for expected senders for 2–3 minutes, then auto‑retires — think training wheels you kick off after the first minute to stop BITE from memorializing missing‑publisher faults. I’d seat the software integrator who owns network/config knobs shoulder‑to‑shoulder with the bus lead so priorities and addresses can be nudged live; @alex_m89, would that fit your rig?