Eagle 754 Service ToolkitOverviewService procedureSafetyHardware

Service procedure: clearing the PM advisory on a training Eagle 754

Read SAFETY.md first. Have ready: the ventilator on its AC power supply, the USB-RS232 adapter and straight DB9 cable, this toolkit installed (eagle754 selftest passes), and a pen to record the USER PROGRAMS counters.

0. Baseline

  1. Record Hrs, Dys and Version from USER PROGRAMS (FRONT_PANEL.md).
  2. eagle754 connect. The wizard walks through the adapter, the cable (straight-through to the 9-pin port on the AC supply module), external power, powering up in A/C, listening at 2400 baud, trying 1200 and the other rates if needed, and tells you whether the two frame cadences from the manual are present. It sends nothing to the ventilator and saves a capture. Then eagle754 monitor COM5 --seconds 30: the P? sparkline should track the pressure bar graph when you squeeze the test lung. If the wizard ends without data: swap to a null-modem cable, try another adapter (counterfeit FTDI chips are crippled by the Windows driver), then check the port is on the supply module and the unit is on external power.
  3. eagle754 capture COM5 --out captures/<serial>_stream.jsonl --seconds 120 while you change rate, VT, mode and trigger an alarm. eagle754 analyze captures/<serial>_stream.jsonl --json captures/<serial>_analysis.json --draft-protocol captures/<serial>_protocol.json. The varying byte positions in the status frame are your rate/VT/mode/alarm fields; name them in the draft file and re-run monitor --protocol to see decoded values. This step is optional for the reset but it is what turns the port into a teaching tool (live waveform on a projector).

1. Choose the route

You have Use
Any copy of CAL.EXE / CAL V2.7, even on an old XP box Route A (OEM_SOFTWARE_CAPTURE.md)
A commands.json from someone who already did Route A on a 754 eagle754 pm-reset directly (section 3)
Neither, but time and a training unit Route B (section 2)
Neither, and you are comfortable opening the case Route C (HARDWARE.md)

2. Route B: probing

The ventilator reacts to "control signals" on this port (manual). The probe finds them.

  1. Start with the cheapest sweep, with the unit in A/C on a test lung, AC power connected:

bash eagle754 probe COM5 --set bytes --json captures/probe_bytes.json Each of the 256 single bytes is sent ~0.6 s apart. The report flags candidates that produced extra bytes, a new frame class, or stopped the stream. 2. If nothing single-byte reacts, try two-byte conventions used by 1990s terminal-style firmware:

bash eagle754 probe COM5 --set esc # ESC + printable eagle754 probe COM5 --set ascii-cr # letter + CR eagle754 probe COM5 --set pairs-upper # AA..ZZ 3. A candidate that stops the stream and shows FACTORY CALIBRATION on the LCD is hold. Confirm the toggle: eagle754 send COM5 <hex> twice; the stream stops, then resumes with a reboot. Write it into commands.json (copy eagle754/data/commands_template.json):

json "hold": {"steps": [{"tx": "<hex>", "rx": "<reply hex or empty>", "rx_window_s": 1.0}], "expect_stream_stop": true}, "release": {"steps": [{"tx": "<hex>", "rx": "", "rx_window_s": 1.0}], "expect_stream_stop": false} 4. Finding the reset: put the unit in Hold (eagle754 send COM5 <hold hex>), then probe again with --set esc, --set ascii-cr and --set bytes. Candidates that get an acknowledgement while held are service commands. After each promising candidate: send hold again to release, let the unit reboot, run MODE → CAL, and read Hrs/Dys in USER PROGRAMS. The one that zeroes them is rtc_reset. Expect to also find the OEM "save to EEPROM" and "load defaults" commands; do not use them. 5. Fill rtc_reset in commands.json, set "status": "learned", and continue with section 3 on the next unit. Share the file (serial numbers removed) by pull request.

Discipline: one candidate set per session, log file names that include the unit serial, LCD photos of anything unexpected. If the LCD ever shows a message you do not recognise, power-cycle before continuing; the service state does not survive a reboot.

3. The reset

eagle754 show-commands commands.json          # sanity check: hold/rtc_reset/release present
eagle754 pm-reset COM5 --commands commands.json --dry-run
eagle754 pm-reset COM5 --commands commands.json

The tool: checks the stream is live → sends init (if learned) → sends hold and verifies the stream stops → asks you to confirm FACTORY CALIBRATION on the LCD → sends rtc_reset and compares the reply with the learned one → sends release → waits for the stream to resume. If you answer no at the confirmation, or anything fails after Hold, it sends release before exiting. The log is captures/pm_reset_<timestamp>.jsonl.

4. Finish

  1. MODE → CAL (Transducer Calibration alarm after an RTC reset is expected).
  2. USER PROGRAMS: 0 Hrs, 0 Dys. The advisory is gone from the AMC.
  3. Operational check: A/C 12 bpm, VT 500, test lung; alarms (disconnect, high pressure) sound.
  4. Label and log. Next due: 12 months or 2000 h, whichever first.

Recurring use

Keep commands.json with the toolkit. Every subsequent unit is section 3 only: five minutes, including the CAL step. For a fleet, eagle754 pm-reset COM5 --commands commands.json --yes runs unattended once you trust the sequence, but the LCD confirmation step is worth keeping.