Reverse engineering unknown RS232/UART binary protocol

Question

Background story

For couple of days I'm trying to crack the protocol used the old medical device, in order to collect data for a research in an automated way.

The device in question is Novametrix CO2SMO Plus, model 8100. Manufacturer of this device was bought, long time ago, by Respironics and than Respironcis was bought by Philips. Their website doesn't exists for last 12-14 years and archived copy doesn't have any useful information. Since device was designed before 2000 there's no software over the Internet - it was distributed on floppy disks so as software updates.

Device is very similar to model 7100, which was released ~3 years prior to the 8100. Devices mainly differ in software - the one in 8100 is much more sophisticated.

Physical layer

At first I stared from obvious things like determining physical layer of the connection - that went easy, since service manual actually lists all signals in DB25, located on the back of the device.

At the beginning I hoped 8100 will use similar, well documented by manufacturer, ASCII protocol (called NOVACOM1) as 7100 used. Unfortunately it's not the case. My device uses newer protocol called NOVACOM3 - there's zero information about it in the Internet; it seems like NOVACOM2 was never released.

I don't own oscilloscope (and I don't have an access to electronics labs on my college), so I determined baudrate of the port just observing the traffic with different baudrates with debugging mode enabled on device (more on that later). With high confidence I can say it's 9600 8N1 (like in previous model).

Device uses NXP MC68332 MCU, which according to the data sheet is a rugged 32 bit core with quite a few subunits useful in an automotive applications. It also seems to be a secure one - since I have almost no experience in EE I quickly dismissed any possibilities to attempt of physically attacking the CPU.

PC software

According to the service manual, manufacturer had developed PC software used for communication with the device - "CO2SMO Plus! for Windows". Unfortunately it was sold as a separate package and it's nowhere to be found now.

Diagnostic protocol

The device has two Novametrix protocols - NOVACOM3 and SATDIAG. Since diagnostic protocols are usually simpler I started from the later one:

• SATDIAG streams data continuously
• Protocol, besides sending data to the computer, contains some unknown upload mode for firmware update (probably some XMODEM or so... I don't have firmeware blob, so obviously I didn't played with this)
• After analysis I can say with high confidence each packet begins with 0x00 and ends with 0x0A (LF)
• Protocol streams packets few times a second (I didn't conducted any measurements on that, but it's 15-20/s)
• Device alternates between sending 9 and 25 bytes (including 2B of header and footer) packets
• Every few of seconds 41 bytes packet is transmitted
• Most probably no checksum is used (the same payloads contain different last byte, I also calculated popular checksums for few)
• Protocol seems to be aimed strictly for collecting performance data, some sort of resources usage or represents unknown internal state - changes in measurements aren't causing any notable changes in packets. I also tried manually searching for numbers similar to these displayed by the device - no luck.

In summary SATDIAG seems to be more like a debugger dumping some performance metrics or resources usage.

Control protocol

Next I started playing with the protocol used to talk to the PC software - NOVACOM3:

• The protocol follows request-response pattern
• In order to display live waveforms protocol has to contain continuous mode which just streams data without additional queries: that is what I want to get
• By sending different characters I determined that 0x00 marks end of the packet. There's no signs of any character marking beginning the the packets.
• It looks like device expects (some?) packets to be 8 bytes (including trailing NULL-BYTE) long - while sending different lengths terminated by 0x00 I see for 8 bytes device is consistent with replying with 2 bytes.
• Seems to have no checksum - I've got different 2 bytes responses with the same first byte and different 2nd
• Response packets seems to have no length defined
• Sending multiple 0x00 seems to "zero" the device input buffer - while I was playing with determining length sending 3-4 0x00 was causing device to behave consistently.
• Sending multiple 0x00 generates no response
• Protocol may have some blocks of commands: while I started scanning by sending 1 byte + 0x00 I've got no response for 7 bytes after each of the bytes: 0x10, 0x30, 0x50, 0x70, 0x90, 0xb0, 0xd0, 0xf0
• All responses which I was able to get were 2 bytes or 4 bytes (and the longer ones seem to be 2 packets actually). Each packet was started with 0x2A
• The only responses o was able to get were: {0x2A, 0xA0}, {0x2A, 0xA1}, {0x2A, 0x80}
• The packet {0x2A, 0x80} may actually be some sort of ACK, since a lot of times I had to wait for second packet for a 1-1.5s when responses were 4 bytes long.
• 0x20 (space) / 0x40 (@) / 0x60 seems to be a white character - sending it followed by 0x00 leads to no response. These characters are also very common in SATDIAG. It's a little bit suspicious that they're spaced so evenly 20-40-60. Now while writing this I think it might be some connection with the ranges described few points before (10-30-50-70-90-...)

I'm stucked...

I wasn't able to force device to start streaming - if I would manage to do that figuring out parameters shouldn't be that hard, since I have the display on the unit and I know which parameters to expect. Until than... I have no idea how to progress further. I also tried contacting Philips division which bought the company - no response whatsoever.

Any ideas?