VW Scanner - портативный сканер для VAG небольшой отчетец

  • Автор темы Pasha@VR6
  • Дата начала
  • Ответы 348
  • Просмотры 226К
AKD2 написал(а):
Как сказать, осциллографом кое-что можно выведать.
Устройство Cyber_RAT` известен :)
Нажмите, чтобы раскрыть...

Это не осцил, а запись последовательности 0 и 1... причем 5 вольт макс ;)
а я помехи хотел импульсные смотреть и что вообще на шинах происходит...
А вместо такого девайса проще 4 резисора и несколько диодов на ЛПТ (ну или через АП5 для страховки) и будет 4 канальная фиготень такого же рода и без микроконтроллера ;)
 
Cyber_RAT написал(а):
Это не осцил, а запись последовательности 0 и 1... причем 5 вольт макс ;)
а я помехи хотел импульсные смотреть и что вообще на шинах происходит...
А вместо такого девайса проще 4 резисора и несколько диодов на ЛПТ (ну или через АП5 для страховки) и будет 4 канальная фиготень такого же рода и без микроконтроллера ;)
Нажмите, чтобы раскрыть...

Думаю помехи тут ни при чем, VagCom же без проблем работает.
Хоть 500 В. если надо, не проблема, частотнонезависимый делитель 1 к 100.
На LPT длительность точно не померишь. Автор девайса навернняка много чего знает, тем не менее был вынужден соорудить это устройство. Я не настаиваю, просто хотелось хоть чем-то помочь.
Не очень низкочастотные/высокочастотные помехи можно посмотреть через звуковую карту.
 
помехи тут как раз таки и причем :)
только вот инженеры ВАГ - знают каким образом у них реализован протокол для защиты от оных... а я нет ;)
Длительность на ЛПТ меряется неплохо (только не под винду проги нужно а под голый ДОС, да и не в этом дело...). за схему спасибо :drinks: - видел ее не раз, но что-то запямятовал (надо покапать ее в сторону простого осцилла (типа как у боджи ;)))
p.s. перекапываю исходники моноскана - уже появился ряд вопросов, но задавать не спешу %) ибо как говорят: лучше слыть идиотом, чем заговорить и резвеять все сомнения :lol2:
 
Cyber_RAT написал(а):
p.s. перекапываю исходники моноскана - уже появился ряд вопросов, но задавать не спешу %)
Нажмите, чтобы раскрыть...

Критиковать Monoscan не собираюсь, с протоколом там тоже не все гладко (ИМХО, т.к. я только подключал каждую версию по нескольку раз при проверке адаптеров, постоянно не пользуюсь), у VagCom устойчивость выше.
 
В тему в тему.... это я уже видел, правда на немецком. Там еще есть макроконтроллерный сканер для ODBII было б неплохо объеденить и то и другое в одном флаконе. ;)

p.s. заканчиваем испытание и обкатку прошивы с реализацией протокола коррекции ошибок связи... пока результаты радуют (у меня наработка в общей сложности около 5 часов и ни одного обрыва) (Спасибо Hounddog за исходники и за исследование протокола :) )
 
отправил новую прошиву для сканера v1.5 (пока только для 3310 версии) смотреть на 1 странице этого топика чуть попозжа %)

p.s. отправил прошивку и для сканера с индикатором 16х2 v3.0b
тестируем - отписываемся :confused:
 
Тема сканера продолжается... мини фото прототипа (пока еще недоделанного сканера + БК), цепляется к датчику спидометра и форсунке... и К линии. режим работы выбирается из меню.
сделан на основе экрана от Сименса s65 (176x132точки 65535 цветов)

BWBzRF53PC.jpg
 
Возвращаясь к старой версии сканера на LCD 3310. вчера был фотик в машине - сделал пару снимков расшифровок ошибок.
Ошибка лямбды

bKVBlTzgVz.jpg

ошибка MAP

0DchfFSKJv.jpg


вот так это все выглядит.

p.s. насчет VW-Scanner и второй N (не задумывался и не обращал внимания :) )
принимаю предложения по улучшению и исправлению ошибок (как в коде, так и орфографических)
:confused:
 
Cyber_RAT написал(а):
Дописал расшифровку ошибок, но только для Индикатора НОКИИ3310 (там 6 строк по 14 символов, на 2 по 16 будет совсем не информативно :( )
работает так:
смотрим ошибки в  цифровом виде, если хочется расшифровки - жмем энтер(связь с блоком разрываем, ибо поиск в ПЗУ по I2C шине идет долго) и листаем ошибки в расшифрованном виде - например:
ДМРВ
ОБРЫВ/К.З. на+

ЛЯМБДА
НЕТ СИГНАЛА

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

Но ведь это не здорово, если до сих пор так – закрывать соединение с ECU для поиска описания кода ошибки, а затем коннектиться заново, даже если и автоматически.

Я конечно сознаю, что EEPROM внешняя, что I2C последовательный интерфейс, но
1) неужели 8 обращений к EEPROM, за которые можно бинарным поиском найти описание кода ошибки среди 134 описаний занимает больше 1 секунды ?
2) если 1) все равно медленно то можно на startup загрузить в RAM контроллера индекс с кодами ошибок и адресами описаний в EEPROM и искать в RAM.
3) если 2) не проходит из-за размера RAM, то можно сделать поиск с resumable state – задавать подпрограмме поиска время выполнения, по истечении которого она будет приостанавливаться с сохранением своего состояния, после чего можно пингануть ECU и вызвать подпрограмму поиска снова для продолжения поиска с предыдущего состояния.

Но это - технические вопросы. А идеологический вопрос таков:

4) Какой смысл загружать в EEPROM описания всех возможных кодов ошибок, которые могут выдать все возможные ECU с этим протоколом, которые исчисляются даже не сотнями, а тысячами, а затем искать в этой туче. Конкретному пользователю сканера нужны несколько десятков ошибок своих нескольких ECU.
Но тут опять возникает вопрос об удобной записи в сканер одной или более конфигураций ECU. И с появлением нормального дисплея он только обострится, т.к. наверняка захочется отображать названия зон измерений, нормальные значения зон мелким шрифтом и т.п.

Если запись нужных конфигураций с компа не кажется глупой идеей и еще не сделана, то можно обсудить пару финтов ушами, чтобы сделать ее без затрачивания такого же количества усилий, что и на коммуникацию с ECU.
 
Расшифровка ошибок прицеплялась последней, и мучаться с переработкой всей программы не хотелось. На данный момент, связь не рвется, поиск идет в фоне, и ошибки выдаются сразу в виде
Error(s) 1/X
XXXX-XXXXXXXXXX-XX
Расшифровка (если есть)
...................................
..................................
...................................

На счет связи с компом - новая версия сканера имеет разъем для ММС (SD) карточек (ведение логов, расшифровки ошибок (Хоть 1000 хоть 2000, только надо небольшую прожку наваять, чтобы таблички поиска и добавление ошибок в файл были на компе)).

p.s. использование ММС сугубо денежного характера... 16-32 мб карточки стоят копейки (а у многих валяются без дела от фотоаппаратов и телефонов), по сравнению с хотя бы 1 мегабитной памятью с интерфейсом SPI или I2C, да и удобно - врубил запись логов, покатался, а потом дома взглянул что там у нас за поездку творилось...

p.p.s. а вообще хотелось бы услышать пожелания трудового народа - может еще что-нибудь добавим (или отнимем).

p.p.p..s. почитал на немецком форуме про их сканер для ODB - II... прога ужасна простая (такое чувство что протокол упростили, но нужно еще посмотреть). можно попробовать добавить и ODB-II - хотя бы чтение ошибок??? (только вот негде у меня проверить все это дело)
 
Cyber_RAT написал(а):
На счет связи с компом - новая версия сканера имеет разъем для ММС (SD) карточек (ведение логов, расшифровки ошибок (Хоть 1000 хоть 2000, только надо небольшую прожку наваять, чтобы таблички поиска и добавление ошибок в файл были на компе)).
Нажмите, чтобы раскрыть...

Так скорость обмена данными с карточкой позволит найти среди 2000 записей на карточке нужную за требуемое время ?
 
Ну воообще-то скорость работы с ММС по SPI возможна до 20 млн бит в секунду :)
2000 ошибок = 2байта на номер ошибки * 2000 * 2байта указателя 8000 байт(в крайнем случае 3 байта на указатель если файл превысит 65к).... даже с учетем отвлечения на прерывания и обновления экрана, и с учетом что SPI реализован програмно, 2 млн бит где-то выходит за 1 секунду... проблемм я думаю не будет, а если еще учесть что под буфер чтения с ММС отведено 512 байт, то можно блоками искать. (прочитал, поискал, послал ЭБУ поддержание коннекта, считал следующий блок из ММС...)
Тут другой нюанс... чтобы все это смотрелось читабельно, необходимо распарсить ошибки еще на PC (переносы слов, сокращения, формирование индексов для поиска), а времени и на то и на другое - не хватает пока :( поэтому дело движется не так быстро как хотелось бы.
 
Cyber_RAT написал(а):
2000 ошибок = 2байта на номер ошибки * 2000 * 2байта указателя 8000 байт(в крайнем случае 3 байта на указатель если файл превысит 65к).... даже с учетем отвлечения на прерывания и обновления экрана, и с учетом что SPI реализован програмно, 2 млн бит где-то выходит за 1 секунду... проблемм я думаю не будет
Нажмите, чтобы раскрыть...

Все равно бинарный поиск юзай
2000 ошибок = 2байта на номер ошибки * Log2(2000) * 2байта указателя = 44 байта
 
если можно - поподробнее?

p.s. сегодня пытался продумать как оптимально сделать поддержку типа lbl файлов для вагкома... пока ничего не придумал :(
 
да-да-да :) я уже почитал.. впринципе то что надо! только упорядочить ошибки на компе и с переносами разобраться, чтобы не получалось типа:
Выход за пределы а
даптации. Ниже вер
хнего предела.

 
Уважаемые, подскажите, а где можно почитать по протокол связи OBD? Что послали, что получили, команды, структуру получаемых данных, времянки. Хочется в это вникнуть, прежде чем попытаться чтото сделать.
 
какой конкретно интересует протокол?
odb-II, kwp1281, kw2000, can ?
 
Войдите или зарегистрируйтесь для ответа.
Назад
Сверху Снизу