Вопрос по протоколу OWEN (разбор ASCII текста на PRESENTATION LAYER)

Я реализую OWEN стек по документации "ОПИСАНИЕ протокола обмена между ПЭВМ и приборами ОВЕН", застрял на пункте 5.1.5 "Строковый тип"

Конкретно, я отправляю пакет на получение "dev":
0000 23 47 4b 48 47 54 4d 4f 48 53 51 54 55 0d #GKHGTMOHSQTU.

Addres : 4
+ : 0
Remote : 1
Size : 0
Hash : 81d6 (LE: d681) (dev)

получаю ответ:
0000 23 47 4b 53 47 54 4d 4f 48 4a 47 4a 47 4a 49 53 #GKSGTMOHJGJGJIS
0010 53 54 47 54 49 4b 4a 54 4b 0d STGTIKJTK.

Где данные:
0000 30 30 32 cc d0 d2 002...

По описанию я должен получить что-то типа:

0000 30 30 32 50 4d 54 002PMT


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

Прошу помочь.

В качестве бонуса указываю на ошибку в вашей документации "ОПИСАНИЕ
протокола обмена между ПЭВМ и приборами ОВЕН".
В разделе 6.2 "Команды смены сетевых настроек прибора" указан параметр
"rS.dL" с hash 0x1e25, это не соответствует действительности.
Параметр "rSdL" даёт hash 0x1e25.

Ответили: это кодировка CP1251.
Тему можно закрывать

Цитата:

---

Сообщение от ASM

В качестве бонуса указываю на ошибку в вашей документации "ОПИСАНИЕ
протокола обмена между ПЭВМ и приборами ОВЕН".
В разделе 6.2 "Команды смены сетевых настроек прибора" указан параметр
"rS.dL" с hash 0x1e25, это не соответствует действительности.
Параметр "rSdL" даёт hash 0x1e25.

---

Точка тоже учитывается при расчёте хэша, т.е. длина строки, по которой считается хэш будет 5 символов, а не 4. В документации скорее всего указан хэш 0xcbf5, а без точки действительно получается 0x1e25, но по нему нельзя будет получить значение параметра.

Цитата:

---

В документации скорее всего указан хэш 0xcbf5,

---

Нет, это не так. Об этом я и говорю.
Более того, параметр 0xcbf5 девайс не ест, нужно указывать 0x1e25.

Цитата:

---

Точка тоже учитывается при расчёте хэша

---

Спасибо, КЭП. Но длина строки для расчёта HASH как была 4 буквы, так и останится.

Пожалуйста, не нужно вставлять бессмысленных комментариев с Вашими догадками о том, что написано в документации. Более того выдавать за истину Ваши догадки (это про расчёт HASH по 5 символам).

Прочитайте, пожалуйста, документацию если Вам интересна тема, и Вы хотите в ней поучавствовать.

Цитата:

---

Сообщение от ASM

Нет, это не так. Об этом я и говорю.
Более того, параметр 0xcbf5 девайс не ест, нужно указывать 0x1e25.

---

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

Цитата:

---

Сообщение от ASM

Спасибо, КЭП. Но длина строки для расчёта HASH как была 4 буквы, так и останится.

---

А тут уже возможно вы ошибаетесь. Я читал документации и изучал исходники протокола, более того я использую эти исходники в работе. Дело в том, что вычисление хэша параметра происходит как бы в два этапа, сначала строковое имя параметра преобразуется в бинарное 4-х байтовое представление (а не четырех буквенное!) функцией:
/* преобразование локального идентификатора в двоичный вид
name - локальный идентификатор
length - длина идентификатора
id - идентификатор в двоичном виде
*/
void name2id(char* name, size_t length, unsigned char id[4])
Как видите во входном параметре нет ограничения на длину. Но реально длина не может быть больше 5 символов (цифры, буквы английского алфавита и '-','_','/'), причём допускаются только 4 символа, точка обрабатвается отдельно, увеличивая на единицу значение предыдушего байта, но может быть произвольное количество пробелов в конце. В общем в исходниках всё видно.

А потом уже четырех-байтовое представление преобразуется в двух-байтовое.
/* свертка локального идентификатора */
unsigned short id2hash(unsigned char id[4])

Поэтому символьное имя параметра может иметь длину больше 4-х символов, я с этим уже сталкивался и у меня как раз был обратный случай, когда я пытался посчитать хэш по 4-м символам, выбросив точку, но прибор его не "съел".

Говорим об одно и том же разной терминологией.

Вопросы терминологии всегда были самые сложные, ведь термины это хэши в которые мы пакуем наши мысли, но они не всегда правильно интерпретируются другой стороной:) Получается, что если разработчики ОВЕН захотят, они могут сделать 8-символьный параметр, скажем, "r.E.A.d." и его хэш будет 0x2db6