Форум Авто Сигнализаций - Разаработчики Пандект 477/577 - зачем постоянно опрашивать метку???

Форум Авто Сигнализаций (http://www.alarmforum.ru/index.php)

- Pandora, Pandect (http://www.alarmforum.ru/forumdisplay.php?f=12)

stotten,
Это только у 471-ой модели? а у других?

Цитата:

Сообщение от Voyager (Сообщение 29750)

Сообщение от ATiА как раз продукция Альтоники в последние годы как раз часто проявляла низкое качество своих фирменных реле блокировок.

Это ваш личный опыт или где-то обсуждалось? Можно получить ссылки или ключевые фразы для поиска в сети?
Если ваш личный опыт то какие именно реле альтоники показали себя не с лучшей строны? Их ведь много подвидов..

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

Ясно. Спасибо.
А правильно ли был установлен блок ББ и реле? (на одном проводе и все рекомендации от альтоники соблюдены)

Voyager, честно, в таких ситуациях не особо интересно проверять "правильность" установки комплекса. Да и проблема не в самом ББ, а именно в релюшках. Обычно замена реле исправляет ситуацию (программатор к счастью еще остался).
Но факт есть- реле глючат. И часто на ходу.
Указанный выше Туарег приехал ко мне именно после очередного глушения двигателя как раз во время обгона.
Вот так.
Так что не стоит сильно пинать Пандект. Да,теоретически контроль метки может являтся проблемой. Но на практике при нормальной установке и "настройке" все работает очень четко. А аппаратных проблем практифески нет (тьфу-тьфу-тьфу). В отличии от конкурентов.

Мы не пинаем. Мы пытаемся сдвинуть производителей с места.
Пока все кивают друг на друга
У нас все хорошо, в отличии от
:)

Если АТ реализует - будет боооольшой плюс фирме

Есть шанс стать первыми - процитирую ответ на мой вопрос от поддержки Multitronics, полученный сегодня:

Цитата:

От: Тех. поддержка [support@multitronics.ru]

Цитата:

вопрос к вашим разработчикам - обращался ли к вам кто-либо из разработчиков сигнализаций и иммобилайзеров по вопросу получения сигнала текущей скорости с шины CAN?

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

В связи с этим 3 вопроса к разработчикам

1) Были ли обращения к вашей фирме по поводу получения скорости с CAN?
2) Если нет - насколько сложно сделать отдельный модуль (без экрана, кнопок - или их минимумом и тп) для получения сигнализациями с шины CAN скорости/оборотов/температуры двигателя? Какие есть варианты по его настройке на конкретную модель машины в случае реализации?
3) Если не сложно - какой на ваш взгляд интерфейс для сигнала предпочтительней?

По данному вопросу к нам еще никто не обращался, спасибо за информацию, мы передадим ее разработчикам.

--
С уважением,
Служба технической поддержки mailto:support@multitronics.ru
ООО "Мультитроникс" http://www.multitronics.ru

Посмотрел сегодня навигатор Nuvi310 в работе - не знаю, или он так тормозит с прорисовкой, или частота опроса спутников так настроена. Если можно более оперативно получать скорость - можно как вариант использовать. Минус GPS - могут заглушить и потеря в тоннелях.

А насчет релюшек - если как принято в критичных местах - ставить их попарно? Не в плане пару одинаковых в текущей реализации. А сделать новый конструктив, куда впихнуть сами релюшки.
Функцию самодиагностики производить при снятии с охраны. То есть по сигналу с главного блока каждая щелк туда/обратно - и при нештатном срабатывании идет сигнал о проблеме. вопрос индикации - чисто технический

Поддержка штанов пандектов *70/*77

Цитата:

в критичных местах - ставить их попарно

Угу в параллель реле пандекта, причем НР контактами.

Набросок.
Состояние релюшки контролировать датчиком движения.
Т.е. при движении с некоторой задержкой (чтобы ен противоречить функционалу пандектов *70/*77 ) НР контакты стали НЗ контактами.
Чтобы не случилось с пандектом (его релюшкой) - пока есть движение контакты реле пандекта будут запараллелены замкнутыми контактами страхующей релюшки. Как только остановились - контакты разомкнулись.
Если на пандекте были разомкнуты контакты - то и дублирующие разомкнутся.
Если без метки заводится, то страхующая релюшка в состояние НЗ переходит с задержкой по времени после начала движения.

GrigoryFF, вроде CAN и OBD II разные протоколы? Вы ничего не путаете?

Особо интересующимся могу сказать, что экселлент позволяет программировать срабатывание в антихайджеке только части блокировок, т.е. назначаем антихайджечной то же топливо (блокировка позволит встать не моментально), и все хорошо. касаемо же небывалой ситуации с потерей метки также могу подкинуть местечек где все достаточно грустно в 433 - думается мне на 2.4 такие тоже есть.

А еще есть системы, позволяющие задавать время задержки срабатывания реле блокировок плюс к вклчению индикации светом до срабатывания блокировок

AChiller,
чтобы не путаться - я имел в виду то, откуда берет данные БК Multitronics:
http://www.multitronics.ru/vag/

Цитата:

Протокол OBD-2 стал обязателен в Европе, начиная с 2001 года. На более ранних машинах данный протокол как правило не применялся, поэтому владельцы таких автомобилей были лишены возможностями пользоваться диагностическими функциями бортовых компьютеров Multitronics.
...
Легкое подключение.
Теперь для подключения бортового компьютера Multitronics владельцу достаточно подсоединить прибор к диагностической колодке, которая находится обычно в легко доступном месте (н-р под рулевой колонкой). Данный способ подключения не требует от владельца знаний электросхемы машины и экономит время - такое подключение занимает в среднем 5...10 минут, включая первоначальную настройку бортового компьютера!
...
Расширенная диагностика.
Универсальный протокол диагностики OBD-2 заявляет вывод в обязательном порядке максимум 10...12 параметров, характеризующих работу автомобиля. При этом производители могут отключать вывод некоторых параметров или снижать возможности диагностики.

Если правильно использовать терминологию, то CAN - физическая шина, OBD2 - протокол передаваемых данных, наверно так?
Могу еще сослаться на статью
Чем отличаются протоколы OBD2, CAN, SAE, VPW, PWM и пр. и как вообще с этим всем разобраться?

Цитата:

Чем отличаются протоколы OBD2, CAN, SAE, VPW, PWM и пр. и как вообще с этим всем разобраться?

Протокол OBD2 определяет единый стандарт наборов данных о неисправностях и параметрах реального времени, обрабатываемых ЭБУ. Иначе говоря, он определяет, "что мы диагностируем".

В рамках протокола OBD2 существуют протоколы, я бы скорее назвал их интерфейсами передачи диагностической информации. На сегодняшний день, их пять:
- ISO9141
- ISO14230 (KWP2000)
- ISO15765 (CAN)
- SAE J1850 VPW
- SAE J1850 PWM
Они определяют такие параметры как формат передачи диагностической информации, ее скорость, управляющие сигналы и пр. Иными словами, интерфейсы определяют метод передачи данных или "как мы диагностируем".
ISO - международный стандарт, но применяется он в большей степени в европейских автомобилях, а также в азиатских, предназначенных для европейского рынка.
SAE - американский стандарт, но он также нередко используется в автомобилях азиатского производства, предназначенных для американского рынка.

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

Этот В&О был найден в Автодиагностика.RU - Автомобильное диагностическое оборудование для автосервиса, компьютерная диагностика автомобилей

И насчет CAN
CAN-интерфейс в микропрцессорных системах управления

Цитата:

CAN (controller area networks) - асинхронная последовательная шина с одной логической линией, имеющей открытую структуру с эквивалентными узлами. Физический уровень CAN - шины представляет собой соединение "монтажное И" между всеми устройствами, входящими в шину. CAN - узлы представляют собой контроллеры, осуществляющие процедуру приема-передачи данных и имеющие логику обслуживающую ошибки. CAN - узлы соединяются с шиной двумя сигналами, RxD для приема с шины и TxD для передачи на шину. Все узлы изначально включены на прием информации. Принято следующее соглашение о состоянии шины: пассивное (recessive) состояние шины соответствует уровню логической 1, а активное (dominant) состояние соответствует уровню логического 0. Когда по шине не передаются сообщения, она находится в пассивном состоянии. Передача сообщения всегда начинается с доминантного бита.
Каждая посылка на шине содержит до восьми байт данных и идентификатор, указывающий приоритет и назначение сообщения. Дополнительная информация, содержащаяся в посылке, позволяет определить тип посылки и осуществить проверку на ошибки. Сообщения, передаваемые по шине, не содержат прямого указания адреса сообщения. Идентификатор определяет только приоритет сообщения и его обозначение. Все CAN - узлы на шине читают одну и ту же информацию и каждый узел решает, принять ли данное сообщение или игнорировать его. Сообщение, передаваемое для нескольких узлов, принимается ими одновременно, что важно для синхронизации в системе управления.
Благодаря арбитрации шины, сообщение с высшим приоритетом передается первым, обеспечивая функционирование системы в реальном масштабе времени и быструю передачу информации. Сообщение, имеющее идентификатор с меньшим значением, обладает более высоким приоритетом.

Типичная структура CAN-сети: