Думаю, что, если знать - что и почему в этих цифрах, за средний - с лихвой!
А в общем , это обмен (трасировка) по 101 протоколу, асинхронная, небалансная передача.
Пакеты постоянной (10), и переменной длины (68). Да это всё описано в ссылке, что я давал. Ну, а что внутри, тоже можно там же прочитать. Но эти вопросы для обсуждения не на этом форуме. Да и , думаю за эти посты модератор может дать по кумполу.
28-07 19:01:20.928 <10 5B 7E D9 16
28-07 19:01:21.021 >10 09 7E 87 16
28-07 19:01:41.178 <10 7B 7E F9 16
28-07 19:01:41.225 >68 26 26 68 08 7e  0d 86 01 7e e9 03 00 00 00 00 80 00 00 00 00 80 00 00 00 00 80 00 00 00 00 80 00 00 00 00 80 00 00 48 42 00  8e 16 
28-07 19:03:21.225 <10 09 7E 87 16 

RinOSpro, 
отвечай на вопросы по пунктам;
.1.есть ли описание протокола?
.2.допускает ли канал связи потерю/искажение данных
.3. есть ли девайс работающий по данному протоколу?
.4.есть ли лог обмена девайса с чем либо по данному протоколу?

и подумаем как ковырять данное

Очень ценная статья есть здесь http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1126 с приложенным файлом. Лично мне очень нравится, и можно применять на прктике для тестирования каналов передачи данных с разными скоростями и паритетами. Протокол простой, но работает чётко. 

Virtuals Хорошо щас отвечу, но есть одно но! В общем такая ситуация протокол есть я даже могу посылать команды и принимать их. Но знаешь какая глобальная проблема?! как сделать качественную обработку.... Не то что тупо получил пакет сравнил с чем то и, отправил, нужно в реализация на высоком уровне... просто устройство сцуко умное... 

Кстати Magik тот лог что ты мне показываешь


Я уже такой реализовывал... это было довольно просто нежели сейчас... У предыдущего устройства протокол был 2 A4 )) и все нормально реализовал работает. а у нового протокол 150 A4 ((( и продвигаюсь как черепаха...


Virtuals 
1. Да 150 стр. англ. текста.
2. Да есть контроль правbльности пакетов достигается через CRC16
3. Да девайс есть и есть уже небольшие продвижения )
4. Лог обмена есть причем от родной программы этого девайа.

Вот не понимаю как в родной программе так все красиво и без глюков работает ) а у меня не получается ((

RinOSpro, 
ну так как мне нереально читать доки ваши то могу дать несколько советов, по крайне мере как я поступаю!

итак:
1. забудте что данные приходят пакетами кусками и т.д. представте что это непрерывный поток
2. нам нужно гдет хранить данные пока мы их полностью непримем, и не обработаем
3. для начала определимся что есть начало БЛОКА а что конец (именно набор условий)
(сдесь и далее буду приводить свой пример)
//набор спецификаций: 
блок начинается на 10 01 
кончается на 10 02
если в блоке встречается 10 то она меняется на 10 10
--
отсюда выводим правила
начало: 10 01 если перед ними нет нечетного количества десяток
конец: если было начало и если есть 10 02 и перед ними нет нечетного количества десяток

4 так научились выделять из потока нужные нам блоки, тепер структура обработки

процедура приема данных:
принимаем байты неважно как, и побайтово выкидываем в процедуру буфера
конец

процедура буфера:
принимаем по одному байту в раз
проверяем размер буфера на предмет возможного переполнения (если переполнение то сбросить флаги начала блока...)
пихаем байт в хвост буфера
отдаем буфер на дешифровку
конец

процедура дешифровки:
анализируем буфер сначала и ищем начало блока (условия известны) если нашли то сдвигаем буферт так чтобы первым было начало буфера /10 01/ дыбы выкинуть мусор и взводим флак начала
если флаг начала анализируем буфер на предмет конца блока если ненашли то свалить
иначе из буфера выдераем весь БЛОК, что осталось смещаем на первую поз, сбрасываем флаги
а блок передаем в процедуру анализа
конец

процедура анализа
вот сюды и будут падть уже чистые блоки согласно вашим протоколам
осталось проверить контрольную сумму и если все пучком
то принять ответные действия

  
ЗЫ удачи в этом нелегком деле

Это сообщение отредактировал(а) Virtuals - 29.7.2008, 12:22

Virtuals помоему это нереально сложно... 

Я так подумал, почитал и наверно буду делать в потоке через статусы... 

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

Примерно так... Как вам такая схема?

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

Это сообщение отредактировал(а) Virtuals - 31.7.2008, 21:07