Indy TCPClient и мошеннический байт в InputBuffer

Я использую следующие несколько строк кода для записи и чтения с внешнего модема/маршрутизатора (также известного как устройство) через IP.

TCPClient.IOHandler.Write(MsgStr);
TCPClient.IOHandler.InputBuffer.Clear; 
TCPClient.IOHandler.ReadBytes(Buffer, 10, True);

MsgStr — это строковый тип, содержащий текст, который я отправляю на свое устройство. Буфер объявлен как TIdBytes. Я могу подтвердить, что IOHandler.InputBufferIsEmpty возвращает True непосредственно перед вызовом ReadBytes.

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

Проблема, с которой я столкнулся, заключается в том, что при разговоре с некоторыми устройствами возвращается первый байт при первой отправке строки после установления соединения помещает мошеннический (случайный) байт в вывод моего буфера . Последующие байты верны.

например, 10 байт, которые я ожидаю, могут быть: #6A1EF1090#3, но я получаю .#6A1EF1090. в этом примере у меня есть точка там, где ее быть не должно.

Если я попытаюсь отправить еще раз, все будет нормально. (т. е. вторая запись, отправленная после установления соединения). Что странно (для меня), использование Socket Sniffer не показывает возвращаемый случайный байт. Если я создам свой собственный «сервер», чтобы получить ответ и отправить что-то обратно, он будет работать нормально в 100% случаев. Другое программное обеспечение, т.е. не мое программное обеспечение, прекрасно взаимодействует с устройством (но, конечно, я понятия не имею, как они анализируют данные).

Есть ли что-то, что я делаю неправильно выше, что могло бы вызвать это - учитывая, что это происходит только в первый раз, когда я использую запись после установления соединения?

Спасибо

ИЗМЕНИТЬ

Я использую Delphi 7 и Indy 10.5.8

ОБНОВЛЕНИЕ

Хорошо. После долгих испытаний и поисков я не стал ближе к поиску этого решения. Я получаю два основных сценария. 1 - отсутствует первый байт и 2 - "введен" байт в начале принятого пакета. Использование TIdLogEvent и TIdLogDebug показывает либо отсутствующий байт, либо начальный введенный байт в зависимости от ситуации. Таким образом, мое заявление ReadBytes выше последовательно показывает, что, по мнению Инди, существует (на мой взгляд).

Кроме того, для дальнейшего тестирования я скачал и установил компоненты ICS. К сожалению (или к счастью, в зависимости от того, как вы на это смотрите), это не показало тех же проблем, что и Indy. Это не показало отсутствие первого байта и не показало введенный байт в начале. Тем не менее, я провел только поверхностное тестирование, но Indy воспроизводит поведение «почти сразу», тогда как ICS еще не создал его вообще.

Если кому-то интересно, я могу предоставить небольшое демонстрационное приложение, иллюстрирующее проблему и IP-адрес, к которому я подключаюсь — это общедоступный IP-адрес, поэтому любой может получить к нему доступ. В противном случае на данный момент мне просто придется обойти это. Я не хочу переключаться на ICS, так как ICS может нормально работать в этом случае, и, учитывая, что использование этого сокета составляет почти всю суть программы, было бы неприятно полностью заменить Indy на ICS.