эти файлы с фотками делает вот этот прибор - kris-p
в файлах должны быть сведения о распознанном госномере, скорости движения и дате/времени, т.к. в специальной программе-мониторе к данному устройству они открываются.
к счастью, сотрудник. дело в том, что сведения с треног приносят на флешке на центральный пост, где стоит программа для распечатки "писем счастья". существуют категории владельцев ТС, которым бессмысленно слать квитанции и, соответственно, переводить бумагу и почтовые расходы. поэтому возникла мысль создать и использовать утилиту до обработки в централизованной программе, которая бы удаляла файлы, относящиеся к ТС по определённому списку.
Если переименовать или скопировать 03.11_09.21.04_N1.trg в 03.11_09.21.04_N1.txt и в любом hex-редакторе подставить первыми символами 0xfe и 0xff, то он откроется в блокноте - там бОльшая часть - это русский unicode текст. Среди прочего там "pКрис П Петровский мост ограничение макс скорости 40 км"
есть ли шанс разобраться с форматом файлов? Вполне вероятно, никаких шифров нет. Лучше закиньте сюда файлы trd и pmd, которые гарантированно открываются в этой программе + инфо по ним - какие гос-номера и скорости, т.е. данные, по которым их можно сопоставить с бинарным содержимым, если это конечно не является разглашением служ. информации. По уже выложенным файлам трудно судить, где и что - они в родной программе открывались?
например в 03.11_09.21.04_N1.trg смещение a8 (последние четыре байта) : 4c d0 ff 06 - unixtime даты/времени нарушения (22790 секунд с наступления 3.11.2010, т.е. 6 часов 19 минут 50 секунд UTC), вроде верно.
al пишет: Петровский мост ограничение макс скорости 40 км
это правда.
гос номера в этих файлах нет, т.к. по фото-кадру к ним программа не смогла распознать его. проще говоря, там троллейбус с нечитаемым номером...
Цитата
al пишет: (22790 секунд с наступления 3.11.2010, т.е. 6 часов 19 минут 50 секунд UTC), вроде верно.
должно быть 3 ноября 2010 г., 9:21:04 - время создания файлов и оно есть в их названии.
Хорошо бы ещё получать их этих файлов действительную зафиксированную скорость ТС, чтобы делать сводный отчёт о нарушениях "неприкасаемых" ТС и в случаях очень грубых нарушений пересматривать их статус или принимать какие-то специальные меры.
...время по Гринвичу, т.е. прибавляем к нему +3 часа - Московское (зимнее) время, оно самое. Вы сообщите, с какой скоростью ехал этот троллейбус.
Ограничитель, по-моему, был поставлен не на 40, а на 39 км/ч - это тоже правда?
Странная константа повторяется два раза по смещениям 0x86 и 0xA0: 25 77 D0 02 - это не серийный номер датчика случаем? хотя далее идут соответственно 01 AD 9A FF и 01 9С 60 00 - что наводит на мысль о каком то интервале времени или координатах (GPS внутри?) Смещение 0x99 : 27 то бишь 39 десятичное... по одному файлику трудно распознать, что там именно было.
Закачал архив файлов. Там около 50 сработок. Архив записей (пароль: ilovegibdd). Если у троллейбуса была установка по ходу движения, то здесь навстречу. Порог срабатывания установлен на 62км/ч. Скорости ТС не записал отдельно, но там N53 двигался со скоростью около 104.
госномер легко читается в файлах *.trg, а вот зафиксированная скорость мною пока не найдена.
так вот же она 08.11_20.46.25_N53.trg - смещение 0x3f:68 - 104 км.ч. для проверки гляньте в N34 - 56, N32 - 55, N55- 68, N15 - 54 км.ч. смещение пока можно вычислить по магической последовательности 2577D504 плюс 0f байтов - искомая скорость. скоро отвечу более развёрнуто...
1) первые 4 байта - 00 00 00 6с (везде одинаковые); 2) следующие 4 байта - это длина текстовки (00 00 00 16) сразу за ними, т.е. длина строки в байтах. Видимо 32-х битная константа. Интересно, что расположение байтов для хранения констант и символов - мотороловское, т.е. сначала старшие байты, потом младшие. 2.1) далее unicode-строка "катукова 40" 3) после строки идёт константа FF FF FF FF 00 00 00 00 01 00 00 00 (везде одинаково), 4) далее два байта константа - номер искомого файла, т.е. то что в имени файла (N54) - 36 00 (54 десятичое) 5) Магическое число 1 : 25 77 D5 04 (смотрим далее) 6) четыре байта 76 СС 17 FF - назовём их X1, их значения нарастают от замера к замеру, если принять это число за 32-битную константу. Или возможно это глобальный аппаратный счётчик датчика совместно с Магическим числом 1 (5), т.е. 64-битное число. Почему? -Замер от 3.11, выданный вами ранее, явно указывает на это, там старшие байты были 25 77 D0 02 - т.е. мЕньшее число. Мне кажется это что-то вроде внутренних часов, или по аналогии с Pentium-совместимыми процессорами - счётчик тактов центрального процессора с момента запуска.
7) Четыре байта 00 00 00 05 - флаг опознания номера? 05 - опознан, 03 - нет, судя по всему. 8 ) Четыре байта 00 00 00 02 (везде одинаково), но вроде бы не направление, в замере от 3.11 так же 00 00 00 02. 9) четыре байта 00 00 00 4A - зафиксированная скорость (74 км/ч), м-да, зарезервировано аж 32 бита, с заделом... : ) Опять же, при сравнении с замером от 3.11 - там было попутное направление - скорость тем не менее сохранена по модулю, уже без знака.
10) один байт 00 или 01 - что то, что не я не смог привязать, но это не флаг распознавания номера - там 00 или 01 не зависимо от этого.
11) пять байт 00 00 00 01 00 - то же самое, не распознано, везде одинаково. 12) Магическое число 2 : 25 77 D5 04 13) Четыре байта 73 38 A0 00, скорее всего это тоже 64-битный счётчик. Значение счётчика всегда меньше, чем (5)-(6), может быть это отсчёты начала и окончания радарного захвата, где нужна такая точность. ----------------------------------------- Два случая, если опознанный номер - то 14) 00 00 00 05 - видимо повторяет (7) - флаг опознания номера. 15) 00 00 00 10 - длина следующей строки (16 байт), 16) Собственно unicode-строка гос.номера x139xx48, причём интересно, что буквы идут в русской кодировке, хотя вроде как в номерах специально используются буквы, сходные с латинницей. 17) 00 00 00 06 - здесь 06 всегда, если номер распознан 18) FF FF FF FF - везде однаково 19) 00 00 01 76 20) 00 00 00 C6 21) 00 00 01 C2 - (21) всегда больше чем (19) 22) 00 00 00 D6 - не распознаные мной константы, здесь что-либо трудно предполагать... ----------------------------- Если номер не распознан, то переходим от пункта (13) сразу к (23): 23) 00 00 00 09 - всегда равно 9 24) 00 00 00 0A - длина последующей строки unicode (10 байт) 25) unicode-строка с порядковым номером замера 17391 возможно, внутренняя абсолютная нумерация, по видимому общий счётчик замеров данного конкретного устройства. 26) 4С D8 33 03 - 4 байта UNIXTIME, дата-время от 01.01.1970 в секундах по UTC-времени - время фиксации, 62851 секунда от начала 8.11.2010, с учётом UTC+3, 20:27:31 - странно, что не совпадает, но близко. найденный online конвертер показывает то же самое (http://www.direct-time.ru/index.php?id=12)
Если взять замер от 3.11 - там после пункта (13) сразу идёт (26), т.е. окончание, без промежуточных структур. Видимо флаги (7)-( 8 ) определяют их наличие/отстутствие.
Я бы сначала сделал утилитку, раскидывающее всё это в некий текстовичок или xls-табличку, чтобы потом её можно было бы распечатать и искать дальше связи между неопределёнными константами, если это конечно нужно.
может быть это и есть константы (5) и (12)? возьмите замеры от одного устройства за более ранний период - если там так же = это он и есть. а может быть и pmd-файл. там совсем просто пример 08.11_20.37.36_N23_main.pmd 1) 00 00 00 66 (всегда одинаково) 2) 00 00 00 26 длина следующей unicode-строки 3) строка &HCEOKIEEIGNODHPI_14 причём после подчёркивания число нарастает по каждому замеру, но есть и "дырки" - отстутствующие номера. HCEO KIEE IGNO DHPI может быть похоже на серийный или уникальный номер. (в 3.11 был &PKOEMADCNFFCBIBC_55)
4) 00 00 00 64 00 00 00 64 00 00 00 64 01 - 13 байт (одинаково везде) 5) FF FF FF FF FF FF 00 00 00 00 --------------------------------- FF FF FF FF 00 00 00 00 00 00 (в замере от 3.11) - не понятно, но возможно это режимы съёмки (углы).
По хорошему, тут работы на день, если есть доступ к устройству - залезли в конфигурацию, поснимали, записали режимы, потом меняем одну опцию, снова снимаем. Потом сравниваем дампы.