Конвертер dat в txt – нужна помощь

[Cars]

День добрый. Помогите конвертировать двоичные данные из dat в десятичные, в формате txt. Может готовые универсальные конвертеры есть? Проблема еще в том, что неизвестна структура данных в dat. Сигналы записывались в dat программируемым контроллером Fastwel. Возможно в его мануале есть инфа про структуру, я не специалист по контроллерам :(

Мануал и dat-файлы прикрепляю. Заранее благодарю за помощь!

Мануал: https://cloud.mail.ru/public/My5Q/F72or5xFx
dat-файл: https://cloud.mail.ru/public/LJ88/SwTGP89hm

[Pphantom]

Cars в сообщении #1056350 писал(а):

День добрый. Помогите конвертировать двоичные данные из dat в десятичные, в формате txt. Может готовые универсальные конвертеры есть?

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

[profrotter]

Тема перемещена из форума «Механика и Техника» в форум «Software»
Причина переноса: не указана.

[Sphinx Pinastri]

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

Файл, похоже, состоит из последовательности небольших по модулю чисел
записанных в 16-разрядном двоично-дополнительном коде, младший байт
идет первым.

[Dmitriy40]

Sphinx Pinastri в сообщении #1056395 писал(а):

Файл, похоже, состоит из последовательности небольших по модулю чисел записанных в 16-разрядном двоично-дополнительном коде, младший байт идет первым.

Похоже. Только есть странный артефакт при переходе через 0: 0xFFFE, 0xFFFF, 0x00FF, 0x0000, 0x0001 (в обратную сторону тоже). Артефакт не обязательно именно 0x00FF, бывает и 0x00FE и 0x00FB и видимо ещё много разных значений с нулевым старшим байтом.

-- 25.09.2015, 00:39 --

И ещё более странный артефакт почти в самом конце файла: 0xFFE6, 0xFFEB, 0x00E8, 0xFF00, 0x00FB, 0x0006, 0x000F.
В общем при почти каждом переходе через 0 что-то странное творится. Как будто при переходе через 0 в следующем слове забывают перекодировать младший байт в дополнительный код и обратно, он так и остаётся инверсным. Бррр.

[Cars]

Может поможет дополнительная информация о файле:
Сигнал считывался с акустического датчика через АЦП в течение 4 сек с частотой 2 кГц. Итого файл содержит 2000*4=8000 выборок (значений сигнала). Каждая выборка в файле представлена в виде двоичного кода в 12 разрядов, где старший разряд отображает знак («0» соответствует «+», «1» соответствует минусу). Далее идет 11 разрядов – модуль выборки сигнала. Итого каждая выборка занимает 2 Байта, а файл 2Байта*8000=16тысБайт. Например, двоичная выборка 011111111111 в десятичной системе соответствует 4095, 111111111111 соответствует -4095, 000000000000 и 100000000000 - оба соответствуют нулю.

Сказанное выше – это всё что я смог вытянуть из инженера, передавшего мне этот файл для расшифровки. Для меня осталось не ясным:
1) почему файл занимает не ровно 16 тыс Байт, а чуть больше (может какая-то информация присобачивается в начале и конце файла)
2) 2 байта это 16 разрядов, а выборки записаны в 12 разрядах. Чем заполнены оставшиеся старшие 4 разряда из выделенных 16 разрядов? Нулями?

[Progger]

Dmitriy40 в сообщении #1056419 писал(а):

Похоже. Только есть странный артефакт при переходе через 0

Скорее всего это связано с тем, что с какого-то датчика снимается сначала младший байт, а затем старший. Если между этими моментами происходит переход через 0, то имеем такую ситуацию.
Результат в txt, xls

-- 25.09.2015, 10:51 --

Cars в сообщении #1056460 писал(а):

1) почему файл занимает не ровно 16 тыс Байт, а чуть больше (может какая-то информация присобачивается в начале и конце файла)

Файл занимает ровно 16кб - т.е. в нём 8192 выборок.

Progger в сообщении #1056461 писал(а):

2) 2 байта это 16 разрядов, а выборки записаны в 12 разрядах. Чем заполнены оставшиеся старшие 4 разряда из выделенных 16 разрядов? Нулями?

В 12 разрядах снимаются данные с АЦП. Программа их обрабатывает и записывает в файл уже в 16 разрядном виде с нормальным представлением знака. Видимо для удобства дальнейшей обработки.

[Cars]

Progger в сообщении #1056461 писал(а):

Результат в txt, xls

Большое спасибо, особенно за графическое представление в S_DAT04.xls, которое многое проясняет.

Progger в сообщении #1056461 писал(а):

Скорее всего это связано с тем, что с какого-то датчика снимается сначала младший байт, а затем старший. Если между этими моментами происходит переход через 0, то имеем такую ситуацию.

Не искажает ли это истинные значения сигнала? Если искажает, то можно ли это исправить и как?

[arseniiv]

(Оффтоп, возможная аналогия.)

Cars в сообщении #1056471 писал(а):

Не искажает ли это истинные значения сигнала? Если искажает, то можно ли это исправить и как?

Это получается как чересстрочность в передаче видео — т. е. сделать-то что-то можно, но только «косметически», т. к. мы как раз не знаем значения, не снятые с другого датчика тогда, когда снималось значение с одного. Можно, например, вставить «промежуточные» значения, беря в них один байт из предыдущего значения, а другой из следующего — но если мы не угадаем, какой надо брать из какого, мы, наоборот, сделаем хуже. Да и такое сглаживание (если угадаем) должно быть чем-то оправдано, а не просто «чтоб было» — и памяти в два раза больше будет, и никакой новой информации, и возможные искажения каких-нибудь вычисляемых величин.

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

Надеюсь, не наврал и аналогию не перепутал.

[Progger]

Cars в сообщении #1056471 писал(а):

Не искажает ли это истинные значения сигнала? Если искажает, то можно ли это исправить и как?

Т.к. старший байт меняется довольно редко, то искажений быть почти не должно. Проблему при переходе через 0 я учёл при конвертации, поэтому могло остаться несколько мест, где уровень сигнала пересекает 256, 512 и т.д. (по модулю). В принципе это тоже можно учесть, если считать что сигнал меняется не очень быстро (т.е. не должно быть скачков на ~256).