Hardware notes: port, cable, chips, memory battery
RS-232 port
- Location: 9-pin female Sub-D on the side of the Universal AC Power Supply module (024-0002-00). The DC-DC converter module (vehicle power) carries the same connector. The serial lines travel from the CPU board to the module inside the EXTERNAL POWER jack cable (the manual: "The EXTERNAL POWER JACK includes pins containing signals for the COMMUNICATIONS PORT"), so the ventilator must be on external power for the port to work.
- Wiring (manual, Communications Port): pin 2 = Send, pin 3 = Receive, pin 5 = Ground. No handshaking lines.
- Because the ventilator transmits on pin 2 (like a PC/DTE), connect it to a laptop with a
straight-through DB9 male-to-female cable. If you only see data when you swap 2 and 3
(null-modem), your adapter is wired as DCE; either cable is fine as long as
monitorshows data. - Level shifter inside: MAX232 (U1 on the display/switch PCB). Standard ±10 V RS-232; any USB-RS232 adapter works electrically. Buy a genuine FTDI FT232R cable from an authorised distributor: Windows 11 has the driver in-box and FTDI's driver deliberately corrupts the data stream of counterfeit chips ("NON GENUINE DEVICE FOUND!" injected into the bytes), which would wreck a protocol capture. CH340-based cables are the second choice (drivers in the Linux kernel and on Windows Update). Avoid Prolific PL2303HXA/XA: Prolific's current Windows driver refuses them.
- No handshake lines: set RTS/CTS, DTR/DSR and XON/XOFF off (the toolkit does). If a legacy DOS program on a real adapter never transmits, loop RTS→CTS (7–8) and DTR→DSR→DCD (4–6–1) at the adapter's DB9.
Serial parameters
Ventilator: 2400 baud (older firmware may use 1200), 8N1, no flow control (manual §14, Computer Calibration v2.7). RT-200 analyzer: 9600 7E1, CR terminator. Impact Model 100 analyzer: 9600 8N1, STX/ETX framing.
Why 2400: the CPU is a Philips 80C552 (8051 family) on a 20 MHz crystal. Its UART derives the baud rate from a timer reload (baud = 2^SMOD / 32 × 20 MHz / 12 / (256 − TH1)), which gives 2400 within about 1 % (TH1 = 0xEA or, with SMOD set, 0xD5) and 1200 exactly as well. 9600 would also be reachable, so the rate is a firmware choice, not a hardware limit; the OEM software only uses 2400/1200 and the firmware is not known to accept anything else.
CPU board (702-0754-03) parts that matter for service
| Ref | Part | Role |
|---|---|---|
| U1 | Philips 80C552-24 | 8-bit microcontroller, on-chip UART, 8-ch ADC, 2 PWM |
| U2 / U3 | ROM / RAM | firmware and working memory |
| U5 | National NM93CS66N | serial (Microwire) EEPROM, 256 × 16 bit, with a hardware protect register; stores calibration tables |
| U6 | Xilinx XC7354 | glue logic + the independent "Backup Ventilator" |
| U10 | Dallas DS1202 (Impact P/N 055-1202-00) | serial real-time clock with 24 bytes of battery-backed RAM: holds the maintenance clocks (hours since PM, days since PM, non-use duration) |
| B1 | 3.0 V lithium cell (Impact P/N 021-0021-00) | powers U10 whenever the ventilator is off (parts list: "BATTERY, LITHIUM, 3.0V"). Impact's own service worksheet records "RTC Battery ___ Volts" at every PM, so measuring it is part of the OEM procedure |
| J3 | 2-pin header | the OEM "Pushbutton Assembly" (P/N 571-0005-00) plugs in here, through the notch in the battery-compartment divider behind copper tape, to permit EEPROM protection changes |
The OEM EEPROM procedure (keys 1-5 in CAL.EXE) maps directly onto the NM93CS66's protect-register instructions: "EEPROM Program Mode Enabled" = PREN, "Protection Register is Cleared/Set" = PRCLEAR / PRWRITE, "Protection Address is at 255" = unprotected (PRREAD returns all ones), "EEPROM Protection Address Is Correct" = protected. The pushbutton drives the chip's PRE pin, which is why a software probe cannot defeat protection.
Factory expectation after an RTC reset (Impact 754(M) Portable Ventilator Test Procedures, §16.1): "A reading of 0 or 44 days and 0 hours should be expected" in USER PROGRAMS. The 44-day value is probably what a freshly initialised clock register decodes to; either is normal immediately after the reset.
Route C - clearing the clock with the memory battery
The DS1202 keeps time and its 24-byte RAM only while powered. Without the lithium cell and with main power off, its registers become undefined/zero and its clock-halt flag is set. The firmware records "hours of use since PM" in the DS1202 (manual, Real Time Clock), so a battery pull is the hardware equivalent of OEM F3 for the clock portion. Expect the same aftermath as the OEM reset: the unit reboots, demands a transducer calibration (MODE → CAL), and the counters read 0.
Procedure (training unit only):
- Note
Hrs,Dys,Versionfrom USER PROGRAMS. - Power OFF, disconnect external power, remove the main battery pack (manual, battery replacement).
- Open the case per the manual's disassembly section and locate the CPU PCB (702-0754-03). The lithium cell is near U10 (DS1202). If it is soldered, this is a soldering job; if it is in a holder, lift it out.
- Wait at least 60 s, then short the cell's holder pads briefly through a 1 kΩ resistor to drain the backup capacitor, if any.
- Install a fresh cell (check the voltage marking on the old one; 3.0 V lithium coin cells are standard), reassemble, reconnect the battery pack and external power.
- Power on; run MODE → CAL; check USER PROGRAMS for
0 Hrs / 0 Dys.
Caveats: the firmware may also log the PM date in the EEPROM (U5). If the advisory persists after a battery pull, the EEPROM holds a flag that only the serial command clears; use Route A or B. A dead memory cell is also a known cause of spurious advisory alarms after storage (the "memory battery" check in the OEM PM inspection), so replacing it is legitimate maintenance in its own right.
Analyzer side (for the OEM program)
The OEM program opens a second COM port for the RT-200 (25-pin connector on the analyzer) or the
Model 100 (9-pin or USB). With eagle754 emulate that port can be the other end of a virtual pair
(com0com on Windows, socat pty pair on Linux) or a second USB adapter looped back into a third.