Обратный инжиниринг устаревшего последовательного порта связи

У меня есть устаревшее (более 20 лет) программное обеспечение, созданное закатом. Он выполняет последовательный порт связи с медицинским устройством. Сейчас я нахожусь в процессе изучения обратной инженерии связи и воссоздания ее в новом программном обеспечении.

Мне удалось записать последовательную связь, как это происходит между программным обеспечением и устройством, используя Монитор последовательного порта.

Я могу посмотреть на таблицу данных устаревшего программного обеспечения и увидеть, как полученные данные хранятся там. Моя проблема заключается в том, что я не могу разбираться ни с хвостом, ни с хвостом полученного потока данных, и у меня нет предыдущего опыта работы с последовательным портом связи, и поэтому я хотел посмотреть, может ли большой коллектив SO помочь мне подтолкнуть меня в правильном направлении (хотя в этот момент я почти потерял надежду, что это так просто, как правильное декодирование данных, и начинаю думать, что мне понадобится внутренняя работа устаревшего программного обеспечения, чтобы понять поток).

Техническая деталь:

• 9600 бод
• Длина слова 8
• 0 паритет

Полезная нагрузка поступает в двух разных потоках:

[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

Распечатка производится с монитора последовательного порта, и я понимаю, что многие управляющие символы просто устанавливаются на «точку». Хотя, насколько я могу судить, они, похоже, не дают четкой картины того, что происходит.

Обратите внимание, что я уже общался с производителями программного обеспечения и устройств и, к их чести, они пытались помочь, но не смогли найти какую-либо соответствующую информацию.
Я также попытался изучить дополнения к двоичным файлам, но они имеют еще меньше смысла.

Любые полезные советы, подсказки или советы будут оценены на этом этапе.

Редактировать:

В целях разъяснения; Я надеюсь, что кто-то, обладающий знаниями о связи через последовательный порт, может знать и, возможно, распознать использование распространенной техники сжатия или кодирования, о которой я не знаю, что может привести к преобразованию потока во что-то, совпадающее с набором данных, который я могу увидеть в устаревшем программном обеспечении. Код не запрашивается