а почему о прошивке забыть? на одном из форумов автор писал, пожалуйста, берите прошивку кому надо и делайте с ней что хотите. про экзешник. глянул hex редактором - похоже, это pcode сделанный в vb6.0. ищу декомпилятор (платить 50 евро жалко )
нашел декомпилятор) вопрос: программа при загрузке сразу коннектится? или кнопку какую-то нажать надо? Вот тут проект на vb - может что интересного увидишь? У меня нету среды, чтобы установить. Вечером попробую почитать повнимательнее. http://filedropper.com/monitor
а вот тут бейсиковский файл со всеми функциями. http://wikisend.com/download/422822/MONITOR_rev.5.bas попробовать бы всё это безобразие открыть в шестом вижуал бейсике и в режиме трейса запустить - может, станет понятно, где и как оно работает?
для полного счастья нужно знать, какой именно pic (и какая его нога там используется для коммуникаций) - тогда можно в даташите попробовать найти похожие строчки... все равно, пока что выглядит безумно сложно.
На сколько я помню pic18f252, мозги в падлу снимать и смотреть точно. Тут народ когда на инвент переходил ковыряли их, могут точно подсказать. Но правильнее всего ковырять саму прогу мониторинга.
тут такой вопрос возник. предхоз говорил про жор масла. у меня мнение, что если и жрет - то по минимуму. если не раскручивать сильно - жора не заметил. а вот когда подержать обороты на 4К и выше какое-то время - появляется вонь горелого масла. открыв капот, увидел, что по нижней стороне клапанной крышки маслице. ну и из крышки маслозаливной горловины тоже сочится. если с фонариком посмотреть - видны лужицы масляные в тех местах, где форсунки в головку вставляются. то есть не жрет, а выплевывает. 1. есть сомнения насчет правильности показаний щупа (когда уровень масла на минимуме - этих симптомов как будто меньше) 2. читаю про прокладку. пока не снимешь крышку - не знаешь, то ли резиновую прокладку покупать, то ли пробковую. 3. (собственно по теме) - пишут, что сопливость может быть следствием не столько плохой прокладки крышки, сколько забитости системы рециркуляции газов. и далее встречается мнение, что на лискаре оно несколько отличается от традиционного сетапа. у кого-то оно вовсе в воздухе болтается. хотя в стоке говорят про какую-то сеточку на крышке распредвала, на фотках в инете ничего такого на этой крышке не нашел (скорее сам неверно понял) Кто на лискаре чистил - расскажите, плз, что и как?
v_kot, а почему ты решил, что это именно эти два байта? не один? не четыре? (пытаюсь прогнать общедоступные алгоритмы crc)
Я выложил сюда только одну посылку, у меня их много, есть одинаковые посылки, в которых меняется только десятая доля напряжения аккумулятора, так вот в них линейно меняется байт в середине пакета и нелинейно эти два: первый пакет: 0x3E,0x43,0x41,0x31,0x31,0x30,0x30,0x30,0x30,0x0D, 0x3E,0x41,0x43,0x31,0x31,0x30,0x30,0x36,0x34,0x37, 0x41,0x46,0x46,0x31,0x37,0x39,0x43,0x38,0x31,0x43, 0x38,0x43,0x38,0x39,0x41,0x38,0x30,0x43,0x37,0x30, 0x30,0x30,0x41,0x30,0x30,0x38,0x36,0x33,0x31,0x0D второй пакет: 0x3E,0x43,0x41,0x31,0x31,0x30,0x30,0x30,0x30,0x0D, 0x3E,0x41,0x43,0x31,0x31,0x30,0x30,0x36,0x34,0x37, 0x41,0x46,0x46,0x31,0x37,0x39,0x44,0x38,0x31,0x43, 0x38,0x43,0x38,0x39,0x41,0x38,0x30,0x43,0x37,0x30, 0x30,0x30,0x41,0x30,0x30,0x38,0x36,0x33,0x30,0x0D третий пакет: 0x3E,0x43,0x41,0x31,0x31,0x30,0x30,0x30,0x30,0x0D, 0x3E,0x41,0x43,0x31,0x31,0x30,0x30,0x36,0x34,0x37, 0x41,0x46,0x46,0x31,0x37,0x39,0x45,0x38,0x31,0x43, 0x38,0x43,0x38,0x39,0x41,0x38,0x30,0x43,0x37,0x30, 0x30,0x30,0x41,0x30,0x30,0x38,0x36,0x32,0x46,0x0D вот показания программы на этих пакетах:
Привет, а лямбда рабочая? 0.46 усредненное значение при не работающей. Доза впрыска почему такая большая?
тут немножко другое обсуждается) вообще вот любопытно, нафига было кодировать байты в ascii коды, которыми опять же передавались байты (там же шестнадцатиричные опять значения лезут) и получается, что в той первой последовательности на предыдущей странице AC1100 64 7A FF 17 9E 81 C8 C8 9A 80 C7 00 0A 00 86 2F 2F - контрольная сумма по этим значениям. вот её и пробовать угадать алгоритм!
Так выдал сканер порта, он сначала в HEX а потом тоже само в ascii, я просто для удобства не убирал. В последнем моем посте только в HEX. А почему в ascii выглядит как HEX, мне тоже немножко любопытно. Хотя это помоему специфика работы UART и это есть наши значения.
ну отлично. понятно, что этот байт (или два байта) отвечает за напряжение. хочу попробовать reveng для брутфорса crc, но насколько я понял, для этого нужно на вход дать хотя бы несколько строчек. одна вот есть. вторую - лениво пересчитывать из hex в ascii, когда оно там в сканере порта уже было...
а вообще очень смахивает на то, что происходит тупо вычитание последующих значений из предыдущих. а в конце остается байт младший байт от получившегося значения... в сообщении 109 красным отмечены младшие разряды седьмого байта. увеличение этого разряда на единичку (то есть увеличение значения всего седьмого байта на единицу) приводит к уменьшению байта контрольного числа (соответственно, двух красных байт) на единицу: 0x33,0x31 (31), 0x33,0x30 (30) и 0x32,0x46 (2F). какое-то хитрое вычитание? а больше нет похожих последовательностей?
Мозги отправляют ответ после приема посылки: >CA110000. Пакет передается посимвольно в ascii последовательности (точка это 0x0D) >CA110000.>AC11 00 64 7A FF 17 9E 8 1 C8 C8 9A 8 0C7 00 0A 00 86 2F CA110000 - это походу эхо запроса. AC11 – что то связанное с идентификацией пакета 00 - R.P.M. значение * 25 64 - M.A.P. значение * 0.01 7A - T.COL значение - 40 FF - T.AIR 17 - LAMBDA значение * 0.02 9E - U.BAT значение * 0.07698 8 - изменение этого значения ничего в программе не меняет 1 - отображает галочки (концевики, климат…) C8 - LCOR.I значение * 0.5 C8 - LCOR.W значение * 0.5 9A - Vxx значение * 0.5 8 - изменение этого значения ничего в программе не меняет 0C7 -Doza значение * 0.025 00 – расход бензина (в проге суммируется и считает полную лажу, хотя я замутил все только из за этого показания ) 0A - AFS_OUT значение * 0.02 00 - ON_TMR значение * 0.1 86 - Vxx_STR значение * 0.5 2F - контрольная сумма (алгоритм вычисления пока не расколдовал) Софтину отображения данных с мозгов можно написать уже сейчас, но без проверки пакета по контрольной сумме это не серьезно.
собственно, чтобы подтвердить эту догадку, предлагаю отправить с эмулятора 0x3E,0x41,0x43,0x31,0x31,0x30,0x30,0x36,0x34,0x37, 0x41,0x46,0x46,0x31,0x37,0x39,0x46,0x38,0x31,0x43, 0x38,0x43,0x38,0x39,0x41,0x38,0x30,0x43,0x37,0x30, 0x30,0x30,0x41,0x30,0x30,0x38,0x36,0x32,0x45,0x0D и увидеть 12,3В в проге
Посылку схавало, но показания получились 12.2 Там множитель стоит 0,07698 и округлило результат до 12.2