Eagle 754 Service ToolkitOverviewService procedureSafetyHardware

Route A: capturing one OEM CAL.EXE session

The OEM program exists in two generations, both of which use the same ventilator link (2400/1200 8N1):

Press only F5 → F3 → F5 → F10 (manual §4.3–4.5). Do not press F1/F2/<RET> (start a calibration point), F8 (load default values), F4 (save data to EEPROM) or F7 (clear protection flag): on a unit whose EEPROM protection was left cleared these overwrite the flow and pressure calibration tables. The bridge prints this reminder when it starts. * Windows "CAL V2.7" (754 manual, "I-Cal"): installs to C:\Program Files\IMPACT\M100\CAL.EXE, menu-driven; "The RTC can be reset and defaults can be written separately from the CALIBRATION menu" (Impact's factory test procedure: Calibration menu → Reset RTC; afterwards USER PROGRAMS shows "0 or 44 days and 0 hours"). In the CALIBRATION menu choose only Reset RTC; FACTORY and AUTO calibration and "write defaults" rewrite calibration data. Because Reset RTC is one menu action, mark it once (rtc_reset): learn splits the recorded hold + reset + release bursts into the three commands automatically when the first and last bursts carry the same bytes. Needs Windows NT/2000/XP, two COM ports (or one COM + USB for the Model 100). Earlier Windows releases 1.1, 2.0 and 2.6 use the same ventilator link.

Where copies come from: service shops that still own the calibration kit, other training programs, the MedWrench Eagle 754 forum (threads Calibration Software, Calibration, Software to connect to a laptop for PM 2000hrs reset), DOTmed's service-technician forum, and ZOLL Medical technical support. When asking ZOLL, cite US Army Supply Bulletin SB 8-75-S2 para 1-12 (2007), which records that Impact distributed the 754 "operation/service manuals and software" to military customers from www.impactii.com/shared/calsoft.htm; DoD-surplus training units are exactly the population that page served. You only need to run it once while the bridge records.

Analyzer requirement, by generation: the DOS program's own procedure (§4.0) says the RT-200 is not needed for the RTC reset (its setup messages merely scroll slowly). Field technicians report that the Windows I-Cal program insists on communication with both the ventilator and the analyzer before it offers "Reset RTC". For the Windows version, therefore, run eagle754 emulate <analyzer-port> --profile rt200 on the port the OEM program expects the analyzer on (never the ventilator's adapter); for the DOS version it is optional.

Wiring for the capture

 OEM program  ──(virtual COM or TCP)──►  eagle754 bridge  ──(USB-RS232, straight cable)──►  Eagle 754 AC supply DB9
      │
      └──(second virtual COM)──────────►  eagle754 emulate --profile rt200        (optional)

All three can run on the same laptop.

  1. Install DOSBox-X. Copy tools/dosbox-x/cal754.conf and edit the paths at the bottom.
  2. The config maps the DOS program's COM1 to a TCP nullmodem that connects to 127.0.0.1:5000:

ini [serial] serial1=nullmodem server:127.0.0.1 port:5000 transparent:1 serial2=nullmodem server:127.0.0.1 port:5001 transparent:1

transparent:1 makes DOSBox-X pass raw bytes without its RTS/DTR framing. 3. Start the bridge first (it listens for DOSBox-X):

bash eagle754 bridge --pc tcp-server://127.0.0.1:5000 --vent COM5 --out captures/oem_session.jsonl

and, if the program insists on the analyzer, in a second window:

bash eagle754 emulate tcp-server://127.0.0.1:5001 --profile rt200 (the emulator accepts the same tcp-server:// URL as the bridge). 4. Start DOSBox-X with the config, run CAL. Type the markers in the bridge window before each key: init, hold, rtc_reset, release, exit. Type quit to close the bridge. 5. eagle754 learn captures/oem_session.jsonl -o commands.json → eagle754 show-commands commands.json.

For the Win32 CAL V2.7 use a Windows XP virtual machine (VirtualBox) with the VM's COM1 mapped to a TCP server or to a host virtual COM port, and proceed the same way.

Option 2: com0com virtual COM pair (Win32 CAL V2.7 on the same PC)

com0com's kernel driver is test-signed: on Windows 10 (1607+) and 11 it loads only after bcdedit -set TESTSIGNING ON and a reboot, which is why Option 1 (TCP) is preferred. If you accept that:

  1. From the com0com Setup Command Prompt: install PortName=COM7,EmuBR=yes,EmuOverrun=yes PortName=COM8 (EmuOverrun stops the sender hanging when the other end is closed).
  2. Point CAL V2.7 at COM7 for the ventilator. Run the bridge on the other end:

bash eagle754 bridge --pc COM8 --vent COM5 --out captures/oem_session.jsonl 3. For the analyzer port create a second pair COM9 ⇄ COM10, point CAL at COM9, run eagle754 emulate COM10 --profile rt200.

(com0com's companion hub4com can also do the splitting, but it defaults to CTS handshaking and 19200 baud; the ventilator wires no handshake lines, so --octs=off --baud=2400 is mandatory before the real port. The toolkit's bridge needs none of that.)

Option 3: Linux, DOSBox-X direct serial or socat

sudo socat -d -d pty,rawer,echo=0,link=/dev/ttyCAL pty,rawer,echo=0,link=/dev/ttyBRIDGE &
eagle754 bridge --pc /dev/ttyBRIDGE --vent /dev/ttyUSB0 --out captures/oem_session.jsonl
# DOSBox-X: serial1=directserial realport:ttyCAL

DOSBox-X prepends /dev/ to the realport: value itself (so write ttyCAL or pts/3, never /dev/...), and on Windows it prepends \\.\ so realport:COM10 and above work. The -d -d flags make socat print the /dev/pts/N names it allocated; link= under /dev needs root, or use link=$HOME/ttyCAL and realport:../home/<you>/ttyCAL.

Wine for the Win32 version: ln -s /dev/ttyCAL ~/.wine/dosdevices/com1 (lower-case, no colon; start at com3 if Wine auto-mapped /dev/ttyS0/S1 to com1/com2), and add your user to the dialout group.

Windows XP in VirtualBox for CAL V2.7: give the VM a serial port in Host Device mode pointing at the host's /dev/ttyBRIDGE or COM8; the guest sees a plain 16550 COM1 and needs no USB-serial driver (XP drivers for current FTDI/CH340 silicon are scarce).

Option 4: receive-only Y-cable tap (OEM PC wired directly to the vent)

Split pins 2, 3 and 5 of the straight cable to two USB adapters' receive pins (pin 2 of each adapter sees one direction). Run eagle754 tap COM5 --out captures/tap_pc.jsonl and eagle754 tap COM6 --out captures/tap_vent.jsonl at the same time, then merge by timestamp. This is the least convenient option; use it only when the OEM PC cannot be re-pointed at a virtual port.

What learn produces

"hold": {"marker": "hold", "steps": [{"tx": "…hex…", "delay_before_s": 0.0, "rx": "…hex…", "rx_window_s": 1.0}],
         "expect_stream_stop": true}

Check: hold should have expect_stream_stop: true (the unit stopped cycling), release should have false, and the OEM program's periodic poll (if any) should appear under polls, not inside a command. If several bursts were attributed to one marker because you typed it early, re-run learn with a smaller --marker-window.

If the OEM program never transmits

DOS programs and some Win32 serial libraries wait for CTS/DSR before sending. The ventilator wires only pins 2, 3 and 5, so when CAL.EXE talks to a real adapter (Option 3 directserial, or a direct cable) loop the adapter's own handshake lines back at its DB9: RTS→CTS (7–8) and DTR→DSR→DCD (4–6–1). Options 1 and 2 do not need this because the virtual link asserts them.

If you obtain CAL.EXE but cannot run it

python tools/scan_exe.py CAL.EXE lists ASCII strings and short byte sequences next to the known UI strings ("Please Wait While Reset Vent754", "FACTORY CALIBRATION", "Hold"). Command strings for a 1990s serial protocol are often literal in the binary and give probe --set file:candidates.txt a very short list to try.