I have a legacy (20+ y.o) software that has been sunset by its creators. It performs serial port communication with a medical device. I am now in the process of looking into reverse "engineering" the communication and recreating it in a new piece of software.
I have been able to record the serial communication as it happens between the software and the device using Serial Port Monitor.
I can look at the legacy software's data table and see how the received data is stored there. My problem is that I can't make heads nor tail of the received data stream, and I have no previous experience with serial port communication, and thus wanted to see if the great collective of SO might help push me in the right direction (though at this point I have almost given up hope that this is anything as simple as decoding the data in the right way, and beginning to think I'd need the internal workings of the legacy software to be able to understand the stream).
Technical detail:
Payload arrives in two different streams:
[17/05/2017 01:28:30] Written data (COM3)
16 06 13 06 00 01 00 00 ca ........Ê
[17/05/2017 01:28:30] Read data (COM3)
16 06 13 06 00 02 00 72 0a a7 03 00 00 04 4b 7a .......r.§....Kz
00 70 78 42 00 00 00 00 00 00 00 0f 02 1d 07 e0 .pxB...........à
04 1b 07 e1 00 9b 0b 1e 00 2e 8d 98 c6 0c 00 00 ...á.›....˜Æ...
00 00 0b 1b 00 21 00 00 1e b1 1e ae 00 03 00 00 .....!...±.®....
61 39 00 00 02 c6 00 57 00 00 00 02 00 00 00 01 a9...Æ.W........
00 08 00 03 00 00 4e 4f 50 51 52 53 54 55 56 57 ......NOPQRSTUVW
58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65 66 67 XYZ[\]^_`abcdefg
68 69 6a 6b 6c 6d 6e 6f b0 71 51 hijklmno°qQ
[17/05/2017 01:28:30] Written data (COM3)
16 06 13 06 04 01 00 00 c6 ........Æ
[17/05/2017 01:28:30] Read data (COM3)
16 06 13 06 04 02 00 ce 00 03 08 1c 11 05 07 e1 .......Î.......á
00 32 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .2..............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 01 00 03 00 01 00 03 ................
00 00 00 00 00 00 00 00 00 32 00 06 00 06 00 08 .........2......
00 06 00 06 00 06 00 06 00 06 00 06 00 06 00 07 ................
00 07 00 06 00 08 00 07 00 06 00 06 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 02 00 03 00 02 ................
00 03 00 00 00 00 00 00 00 00 00 2d 00 06 00 07 ...........-....
00 06 00 06 00 08 00 06 00 08 00 06 00 06 00 07 ................
00 06 00 06 00 06 00 06 00 06 00 06 00 06 00 00 ................
00 00 00 00 00 00 56 ......V
The print out is from Serial Port Monitor, and I do realize that a lot of the control characters are simply set to a 'dot'. They though don't seem to give a clear picture of the what is going on either as far as I can tell.
Note that I have already communicated with the software and device manufacturers and to their credit they have attempted to help, but were unable to dig up any relevant information. I have also attempted to look into complements of the binaries but they make even less sense.
Any and all helpful tips, tricks or points would be appreciated at this point.
Edit:
For clarification; What I am hoping someone with knowledge about serial port communication might know of, and perhaps recognize the usage of, a common compression technique or encoding that I don't know off that might cause the stream to resolve into something matching the data set I can see in the legacy software. No code is being requested
Like everyone else said this is a guess work and it is a binary protocol, only the original comms protocol will tell you exact details.
All you could figure out from the data above is that