А со штатным парктроником все это работать не будет?
Например БМВ, на датчиках по 2 контакта

СМ. выше...

Это надо у автора спросить...

Будет, если сможете считать протокол. Для того нужно
1. Понять как идет сигнал данных
2. Подобрать у меня платку и сигнал ввести в нее
3. Обновить прошивку

Корейские парктроники, массовые. Их выпускают десятками, сотнями миллионов, и есть гарантия, что всегда к ним запасные головы можно найти. Решение Robby BMW хорошо тем, что использует по сути только массовые, очень распространненые компоненты. Потому, есть определенная уверенность, что например что и через 3-5 лет владельцы самого парктроника смогут его без нервов починить.

И еще несколько слов в защиту корейских парктроников. Там применена современная элементная база, современные скоростные интегральные схемы. Низкая стоимость обусловлена в первую очередь массовостью производства (при больших заказах ИС стоят очень дешево). Какой-то гигантской разницы в качестве образцов за 3 и 1 тыс рублей я не увидел, более того, иногда она явно скажем не в пользу более дорогих.

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

Привет усем, А почему бы не использовать "заводские" датчики, генератор УЗ и шести-восимиканальный АЦП , и в комп.... Эт. рябят, хотел вообщето спросить, там на датчик два или три провода идёт? или есть ли фоты датчика покрупнее, а то я их даже вруках не держал :dntknw:

на разъеме датчика 2 контакта

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

А на схему Робби я в принципе поглядывал - меня сильно не устроило, что надо где-то заказывать какую-то микросхему с прошивкой и потом ее куда-то тулить рядом с тем микроконтроллером, что я использую для работы с переферией. Надо что-то поменять - опять к роби... Посему купил первый попавшийся парктроник с выносным блоком индикации и решил для него программу на мк сам написать. В результате оказалось, что ничего особо писать и не надо - 67 строк кода на каждый парктроник.

Ритм вряд ли откроет прошивки для парктроников, тем самым в этом плане от корейцев не отличается. Тогда для каждого человека выбирать, наш парктроник - за 2500 руб, который я не видел на московских рынках, либо корейский, который на каждом углу и выпускается миллионными тиражами, за 1000. Никаких методик тестирования мы еще не придумали обьективных, все крайне субьективно.

Только не подумайте, что я против Ритма. Наоборот, мы все тут - парктронико строители, и чем лучше решение мы предложим, тем лучше всем. Обидно, что китайцы могут, а мы нет ..

Главное, что бы решения, которые российские разработчики предлагают, отличались качественно в лучшую сторону.

Я так и не нашел парктроник, который приспосабливается к наклонным плоскостям, снегу или кенгурятникам. А это, уже не 67 строк кода.
Это смена кодовых последовательностей УЗ, разные алгоритмы излучения и приема.

Меня тоже. Есть серьезные недостатки, которые вылились в то, что под вариант Дже-Дая пришлось резать плату.

Добавлю, что прошивку никто не открывает, ни Робби, ни Вы, правда? То есть, нет отличий в этом плане.

Мы в своем проекте столкнулись с очередной стенкой. В процессе внедрения I2C что то изменилось в коде или конфигурации, и парктроник стал выкидывать куски кода. Такое ощущение, что USB модуль вызывает прерывания, либо, что самое страшное, пробой памяти. Что плохо, нет консистентности, т.е. все образцы немножко уплывают друг от друга, нет повторяемости. Видимо, то ли кварцы с допуском по частоте, то ли конденсаторы. Боремся.

Dont get me started.

Если всмотреться в схему корейцев, то
1. Все головы у них промаркированы по гнездам (А,B,C,D, ..)
2. На излучающих контурах частоты подстроены под каждую голову.

Скажу сразу, я специалист в области теории графов, а не электрических цепей или микроконтроллеров. Потому, отчасти мое мнение базируется на том что я слышу от коллег, может немного упрощенное.

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

В идеале, нужно использовать нечто более эффективное, скорее схему как в УЗИ. На стандартных головах вполне можно организвать не что вроде ультразвукового визора, когда головы попеременно излучают кодовые посылки с меняющейся частотой, а потом они же их и принимают, и при помощи фурье выцепляют гармоники и искажения.

А это, уже новейший многомерный сонар. Этой технологии ни у кого нет. Я оцениваю стоимость разработки пилота в 300-400 тысяч долларов (ничто по сравнению с бюджетами корейских компаний), но это будет реально мировой хит.

Так что, уважаемые одноклубники, тема очень широкая.