Вариант маршрутного комьтера

[shamigulov]

Дабы не оффтопить в

Будь ласка Увійдіть або Зареєструйтесь щоб побачити посилання.

, где начинался разговор.

Предыстория: обсуждаются технические вопросы создания простого маршрутного компьютера.

Прототип самодельного изготовления:

Прототип фабричного производства:

Первый не подходит по причине сомнений в совместимости с Шевроле Ланос и из-за желания отображать то, что мне кажется важным, а в этом проекте исходников нет, что бы их переписывать. Да и самому проще сделать, чем в чужом разбираться. Уже проще, когда с протоколом разобрался, спасибо L2-Max'y и _Sandra_ .

Второй не подходит по причине только одного единовременно отображаемого параметра. Да и опять-таки хочется устройство под себя.

На сегодняшний день уже есть работающее устройство, отображающее на маленьком экранчике (который в перспективе планируется сунуть в приборку под спидометр) обороты, температуру охл. жидкости, скорость и напряжение ак. батареи. Параметры чисто для тестирования - их перечень будет потом изменен - как минимум расход топлива надо будет добавить. По нажатию кнопочки весь ответ от ЭБУ, содержащий в том числе коды неисправностей, сохраняется в ПЗУ микроконтроллера. Эту информацию можно потом либо считать через "большой" комп, либо пролистать на экранчике. Весь бюджет устройства пока примерно 300-400 руб. Точно не знаю, поскольку детали не покупал, использую имеющиеся в наличии. Как дойдет до окончательного воплощения, посмотрю что сколько на сегодняшний день стоит в розничной торговле.

Реализация данного варианта на сегодняшний день приостановлена поскольку "... другая идея в голову попала - использовать для вывода информации с устройства разлоченный навигатор, связав его по USB с моей железкой..." Вариант связать с навигатором через Bluetooth (есть готовые решения) не интересен, поскольку у моего навигатора BT отсутствует

Вот такая тема.

Змінено 10 листопада 2011 користувачем shamigulov

[Гість sergbb]

...Да в общем-то уже почти считает

...связав его по USB с моей железкой...

Так держать

Только полностью на внешнее устройство расчитывать не стоит.

По моему мнению должно выглядеть гдето так:

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

- 2 устройство (типа клиент)с большим дисплеем (ПК,КПК...)и с большими возможностями по управлению первым устройством.

[Igr44]

Дружище!

Особо не раскатывай губу на наружное отображение по юсб протоколу, замучаешся косяки исправлять. Да и какой смысл? Ну есть у тебя чинайский нави, ну подцепиш ты к нему наружу свой девайз, и что? На этом возможность повторения или приобретения твоей магической коробки заканчиваются. Добивай 8 на 2!

Ведь великолепный вариант! плату постараемся по максимуму утоптать , чтобы стала под спидометром. ты бы для ориентировки хотя бы схему выложил или трассировку портов, что будет на ввод что на работу с индикатором что на вывод.

[Igr44]

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

МАЛО!!!

Это уже есть, еще и с цифровой скоростью и двумя одометрами.

рой дальше, делай упор на расход: суточный, моментальный, средний, но для этого необходимы часы реального времени как минимум.

[MikeTS]

полностью согласен с Игорем. Сделай полностью, откатай вариант 8х2, а потом уже будешь идти дальше. А то как обычно ни один вариант толково не выйдет. Ты еще учти тот факт, что не у всех навик есть в пользовании.

[Igr44]

именно так друже!

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

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

Вариант оптимум это 8 на2, движок 876 (873), можно и 18 серия если по ресурсам не хватит ( в корпусе с 28 пинами) считывание с форсунки, датчика скорости, опционально ацп на термосенсор ну и естественно анализ напряжения бортсети, и все!

[shamigulov]

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

Не совсем согласен. Навиков много, но, как я понимаю, большой процент их имеет:

1.в качестве операционки WinCE

2.возможность связи и большим компом через Active Sync

А это значит:

1. Программа написанная для одного будет с успехом работать и на других, ну может быть размер программного окна только надо будет сделать настраиваемым под разные экраны

2. Если я правильно понимаю (я пока только разбираюсь с новым для меня вопросом) Active Sync подключает к USB навика виртуальный СОМ-порт. И если к нему есть программный доступ через API (а это еще надо выяснить), то вообще никаких проблем ни с обменом, ни с совместимостью не будет.

Но эти рассуждения так, в плане обмена мыслями.

А так - вы меня убедили - на выходных попробую довести устройство до окончательно варианта с использованием ЖК-дисплейчика 8*2. Если потом и свяжу с навиком, то так никто ведь не мешает совместить два варианта отображения в одном устройстве. Девайсу будет достаточно просто отсылать данные в навик по сом-соединению, а это ресурсов МК почти не требует. Да и навик все-таки иногда по назначению используется , чтобы информация на дисплейчике все-таки при этом отображалась бы.

В связи с принятым решением вопрос для обсуждения - что выводить на дисплейчик? Места мало, поэтому помогите решить, что самое существенное. Я думаю так - в верхнюю строчку постоянно выводить обороты (у меня в приборке тахометра нет ) и средний, скажем за последние 5 секунд, расход топлива. А в нижнюю строку с поочередной сменой раз в секунду следующие параметры - температуру охл. жидкости (хотя надо ли?), средний расход топлива за текущую поездку, напряжение бортсети (хотя надо ли?)

Какие будут предложения?

Да, если успею красиво нарисовать принципиальную схему на выходных выложу, могу и исходник прошивки для МК. Но я пишу на MicroPascale - если кому интересен такой вариант исходника. Печатки пока нет - устройство собрано на макетной плате.

[mich_ya]

В связи с принятым решением вопрос для обсуждения - что выводить на дисплейчик?

Может сделать выбор что выводить в каждую строчку?!

Тогда в каждую строчку можно будет выбрать любой желаемый параметр... ибо у каждого свои существенные показатели

[shamigulov]

В связи с принятым решением вопрос для обсуждения - что выводить на дисплейчик?

Может сделать выбор что выводить в каждую строчку?!

Девайс - это все-таки микроконтроллер, а не компьютер. Как показывает предыдущий опыт, реализация различных меню выбора, с соответствующим ветвением алгоритма работы устройства (ведь для всех вариантов выбора надо предусмотреть свои куски алгоритма, которые пойдут в прошивку) оказывается очень прожорливой в плане объема программы. Написать-то это можно, но прога потом в МК не поместится - надо будет либо более продвинутый МК ставить, что дорого, либо переписывать наиболее "прожорливые" куски программы на ассемблере, чего не хотелось бы по причине большой трудоемкости такого программирования и желания оставить проект свободным для доработки желающими. Разбираться в чужом ассемблере слишком муторно, тогда уж проще свою программу написать.

[mich_ya]

Девайс - это все-таки микроконтроллер, а не компьютер.

- и все же реокмендую выбор ибо получится какой то полуфабрикат...

1. Мгновенный расход - интересен для оттачивания навыков вождения и экономии топлива...

2. Средний расход на 100 км - интересен всегда, особенно если он показывает правильно

3. Обороты - кому как...

4. Напряжение борт сети - позволяет следить за АКБ, нагрузкой и генератором и вовремя принимать меры...

...

Остальные маршрутные параметры - интересно подключать по мере надобности.

Но к примеру:

п.1 - я бы уже себе не ставил,

п.3 - есть тахометр,

п.4 - если все впорядке, то и не нужен, но чтобы хотя бы сигнализировало при выходе за допустимые пределы...

Блин - без перебора Вам наверно самому надо определяться что больше нужно... т.к. сегодня интересны одни параметры, а завтра другие...

[shamigulov]

2. Средний расход на 100 км - интересен всегда

Средний за какой период времени? Или средний за последние 100 км?

особенно если он показывает правильно

насколько я понимаю совсем правильно не получится в принципе. соответствующего датчика в системе нет, вычисляется расход по оборотам, температуре воздуха, какая-то коррекция по всасываемому объему вводится, коэффициент соотношения топливо/воздух (который не обязан в действительности быть равным заданному)и т.д. то есть точность в любом случае по-моему будет не лучше ± 10%

[mich_ya]

Средний за какой период времени? Или средний за последние 100 км?

Вот и Вы придумали несколько показателей

я писал про: Средний с момента обнуления на текущий момент...

[mich_ya]

насколько я понимаю совсем правильно не получится в принципе. соответствующего датчика в системе нет, вычисляется расход по оборотам, температуре воздуха, какая-то коррекция по всасываемому объему вводится, коэффициент соотношения топливо/воздух (который не обязан в действительности быть равным заданному)и т.д. то есть точность в любом случае по-моему будет не лучше ± 10%

Зачем так сложно: есть время впрыска, расчитано ЭБУ на основании приведенных Вами выше данных и уже известно.

и производительность форсунок... - а тут без калибровки не обойтись ибо производительность форсунок это константа и зависит только от конкретного типа форсунки.

[shamigulov]

насколько я понимаю совсем правильно не получится в принципе. соответствующего датчика в системе нет, вычисляется расход по оборотам, температуре воздуха, какая-то коррекция по всасываемому объему вводится, коэффициент соотношения топливо/воздух (который не обязан в действительности быть равным заданному)и т.д. то есть точность в любом случае по-моему будет не лучше ± 10%

Зачем так сложно: есть время впрыска, расчитано ЭБУ на основании приведенных Вами выше данных и уже известно.

Так (или примерно так - я в подробностях еще не разбирался) считается в программе

Будь ласка Увійдіть або Зареєструйтесь щоб побачити посилання.

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

и производительность форсунок... - а тут без калибровки не обойтись ибо производительность форсунок это константа и зависит только от конкретного типа форсунки.

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

[mich_ya]

Вот-вот-вот. И как же ее узнать, эту производительность форсунок?

В обычных БК она выставляется коэффициентом от какой то заложенной величины. Коэф. подбирается статистическим методом.

Если выбор не предусмотрен, то следует подобрать цифру Производительности, откатать ее статистически и вшить намертво в МК... но это будет справедливо только для конкретного авто.

Собственно так же сделано на ВАЗах - водитель изменить уже ничего не может...

[Igr44]

В связи с принятым решением вопрос для обсуждения - что выводить на дисплейчик?

Может сделать выбор что выводить в каждую строчку?!

Девайс - это все-таки микроконтроллер, а не компьютер. Как показывает предыдущий опыт, реализация различных меню выбора, с соответствующим ветвением алгоритма работы устройства (ведь для всех вариантов выбора надо предусмотреть свои куски алгоритма, которые пойдут в прошивку) оказывается очень прожорливой в плане объема программы. Написать-то это можно, но прога потом в МК не поместится - надо будет либо более продвинутый МК ставить, что дорого, либо переписывать наиболее "прожорливые" куски программы на ассемблере, чего не хотелось бы по причине большой трудоемкости такого программирования и желания оставить проект свободным для доработки желающими. Разбираться в чужом ассемблере слишком муторно, тогда уж проще свою программу написать.

вот наконец добрался до компа.

Давай по порядку.

у нас две строки по 8 знакомест

условно разделяем все показания на три- четыре группы отображаемых параметров

1. ХХХ-скорость ХХХХ-суточный пробег,

+ХХ- температура ХХХ- напряжение бортсети

[Igr44]

2. показания связанные с расходом:

ХХ.Х л\100 км ХХХХ время в пути

ХХ- моментальный расход ХХХ израсходовано л. со сброса показаний

[Igr44]

Да короче будет схема, можно набросать проект в протеусе , а потом уже смотреть что и как и куда .

[shamigulov]

Вот-вот-вот. И как же ее узнать, эту производительность форсунок?

В обычных БК она выставляется коэффициентом от какой то заложенной величины. Коэф. подбирается статистическим методом.

Если выбор не предусмотрен, то следует подобрать цифру Производительности, откатать ее статистически и вшить намертво в МК... но это будет справедливо только для конкретного авто.

Собственно так же сделано на ВАЗах - водитель изменить уже ничего не может...

Вот все-таки более надежный, чем "статистический", способ, взятый из упомянутой ранее программы:

1.Определяем объем воздуха, всасываемый цилиндрами за одну секунду V=1.5*RPM/(2*60) , где 1,5 - объем двигателя, RPM - обороты, 2 - делим на два потому как один раз за два оборота всасывается, 60 - переводим обороты из мин в сек.

2. Корректируем объем V' = V*korr , где korr - эмпирический (по всей видимости) коэффициент, зависящий от оборотов, в программе прописан просто массивом поправок в зависимости от RPM (это на мой взгляд, самое "узкое" место в расчетах - именно оно будет давать погрешность, про которую я писал раньше). Korr изменяется от 0,5 до 0,9.

3. Уравнение Менделеева-Клапейрона (не зря же его в школе изучали, вот пригодилось ) позволяет определить массу всасываемого за один раз воздуха M=P*V'/(R*T)*0.029 , Р - давление (дает датчик), R - универсальная газовая постоянная (в справочнике по физике ), Т - температура воздуха на всосе (дает датчик, не забыть перевести в Кельвины), 0,029 - молярная масса воздуха.

4. Определяем массу всасываемого топлива MG = M/14.7 14.7 - коэффициент соотношения воздух/топливо. Почему 14,7 - не знаю, в программе так написано (еще одно слабое место - вклад в погрешность. мне кажется эбу это соотношение меняет в процессе управления двигателем - корректирует по показаниям лямбда-датчика. хотя может я ошибаюсь)

5. Делим полученное значение на массу одного литра бензина (плотность другими словами, только выраженную в кг/л. здесь тоже будет погрешность на холодном двигателе - из-за температурной зависимости плотности, на прогретом плотность вроде должна стабилизироваться) и получаем моментальный расход топлива в л/с . Умножаем на 3600, получаем л/час. Делим на скорость в км/ч (с датчика скорости) и получаем моментальный расход топлива в л/км.

Ну а дальше делаем все, что хотим: считаем в л/100км, средний по времени или расстоянию расход и т.д.

Мне кажется не сложно - пояснений здесь больше, чем формул. И надежнее, чем по времени форсунки.

[Igr44]

Дружище, ничего всасывать и подсчитывать всосанное не нужно, все проще.

[Vlad_cache]

shamigulov, на каком МК предполагается делать? Вышеприведенный расчет на восьмибитнике займет около 3 кб памяти из-за даблов и делений вещественных чисел плюс еще массивы. Отношение воздуха к топливу 14,7 - это идеал. Но оно не всегда такое. Смесь обогощается, например, при прогреве. Наверное, более точный метод будет предложенный Игорем или Мишей.

Змінено 11 листопада 2011 користувачем Vlad_cache

[Igr44]

по моментальному расходу. Мы знаем статическую производительность форсунки, нам только нужно измерить время на которое она открывается, после этого усредненные данные умножаем на 4 ( по колличеству цилиндров) и усредняем данные за 4-8 плюхов этой форсунки

[Igr44]

расход на 100 км. пути тоже довольно просто это то же самое только накопительные данные поделенные на пробег от сброса до сброса одометра. В этом показания первых десяти километров пробега вообще нету смысла отображать.

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

[shamigulov]

Да короче будет схема, можно набросать проект в протеусе , а потом уже смотреть что и как и куда .

Ну да, в протеусе и набросаю (уже набросано, но не все). Но в протеусе отлаживать не получается - нет, естественно, модели К-линии. Есть неплохая модель COM-порта с физическим выходом на реальный порт компа (что вообще здОрово!) но все-таки RS-232 не совсем К-лайн. Окончательно отлаживать приходилось в машину таскать.

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

[Igr44]

Какая модель К линии? Зачем?

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