Комментарии 42
Лично я предпочёл бы хорошо описанный бинарный протокол с дополнительной библиотекой на Питоне для «поиграться» (туда же можно будет сразу добавить простеньких визуализаций входящих данных). Кроме того, думаю, будет полезным в дополнение к протоколу «запрос-ответ» добавить ещё режим работы «постоянная посылка измерений», можете, например, ознакомиться с протоколом RPLIDAR. Ну и про контрольные суммы сообщений разумеется не забудьте.
Уверен, многие согласятся, что качественно описать и оформить протокол (с навигацией по разделам и с примерами) — это труд не сильно легче самой реализации протокола.
Если создание качественного описания мы воспринимаем как неизбежное, то с примерами сложнее.
О питонах известно лишь, что они обитают в тропических лесах восточного полушария… И зачем им ультразвук?
А если серьёзно, то мы бы не отказались от помощи в создании примеров работы с модулем используя разные средства. Хоть Питон, хоть Ардуино, хоть МикроПаскаль.
Если создание качественного описания мы воспринимаем как неизбежное, то с примерами сложнее.
О питонах известно лишь, что они обитают в тропических лесах восточного полушария… И зачем им ультразвук?
А если серьёзно, то мы бы не отказались от помощи в создании примеров работы с модулем используя разные средства. Хоть Питон, хоть Ардуино, хоть МикроПаскаль.
Лучше реализовать оба протокола — и текстовый и бинарный, с возможностью переключения.
Назовите же сумму!
Конечно два протокола удобнее. А если бы ещё и за разумные деньги купить устройство — всё пошло бы быстрее.
После того как я начал работать с GSM-модемами, я понял, что текстовые протоколы в автоматической обработке — полный отстой :) Нет, я и раньше это подозревал, но вот тут прочувствовал в полной мере :) Так что я за бинарный :)
Но в дополнение к нему можно внести и текстовый, потом когда появится время.
Но в дополнение к нему можно внести и текстовый, потом когда появится время.
а что не понравилось?
мне казалось, что минималистичный текстовый автоматизируется\разбирается\передается ненамного хуже бинарного, зато гораздо удобнее «смотрится вручную».
мне казалось, что минималистичный текстовый автоматизируется\разбирается\передается ненамного хуже бинарного, зато гораздо удобнее «смотрится вручную».
а что не понравилось?
Громоздкость его обработки. Получив структурированный бинарный пакет можно просто наложить на него указатель соответствующей структуры — и все данные как на ладони. А текст приходится парсить, определять тип сообщения строковыми сравнениями, преобразовывать числовые величины из строк в числа и т.д. Особенное зло — асинхронные сообщения, вываливаемые в канал связи :)
ну, понятно, что я не про JSON\yaml, а про что-то уровня CSV (и форматирования а-ля дат\времен\координат).
Если к вам в середину одного бинарного пакета асинхронно «приедет» другой бинарный пакет — тоже ничего хорошего.
Единственные два минуса текстового — это преобразования чисел из строк и бОльший размер (опять же — из-за символьного представления). Но это не настолько уж и критичные минусы ИМХО.
Если к вам в середину одного бинарного пакета асинхронно «приедет» другой бинарный пакет — тоже ничего хорошего.
Единственные два минуса текстового — это преобразования чисел из строк и бОльший размер (опять же — из-за символьного представления). Но это не настолько уж и критичные минусы ИМХО.
я не про JSON\yaml, а про что-то уровня CSV (и форматирования а-ля дат\времен\координат).
Так и я про простые на первый взгляд протоколы типа системы AT-команд :)
Если к вам в середину одного бинарного пакета асинхронно «приедет» другой бинарный пакет — тоже ничего хорошего.
Во-первых, такого просто не может случиться при прямом канале данных, а во-вторых в бинарных протоколах обычно предусматривается контроль целостности данных :)
так а что мешает добавить контроль целостности (base64\hex-поле) в текстовой?
при неизменной длинне сообщений (например при выравнивании нулями) можно также ориентироваться на служебные символы (те же разделители), т.к. их отсутствие\смещение — признак «порчи пакета»
при неизменной длинне сообщений (например при выравнивании нулями) можно также ориентироваться на служебные символы (те же разделители), т.к. их отсутствие\смещение — признак «порчи пакета»
Да можно, конечно, кто же спорит. Я ведь и не утверждаю, что текстовые протоколы неработоспособны, я говорю лишь о том, что для автоматической обработки они подходят гораздо хуже бинарных. Особенно в микроконтроллерных системах.
Текстовые протоколы имеет смысл делать для отладки или взаимодействия с человеком, но как рабочие при взаимодействии с микроконтроллерами — это отстой :)
Текстовые протоколы имеет смысл делать для отладки или взаимодействия с человеком, но как рабочие при взаимодействии с микроконтроллерами — это отстой :)
В микроконтроллерных системах вообще любые подобные протоколы подходят плохо.
Там хорошо подходит модель с прерываниями и регистрами, по которой подавляющее большинство современных чипов и работает: дёрнулась ножка — проверил регистр статуса — прочитал регистр состояния.
Там хорошо подходит модель с прерываниями и регистрами, по которой подавляющее большинство современных чипов и работает: дёрнулась ножка — проверил регистр статуса — прочитал регистр состояния.
Ну почему, работа в формате «запрос/команда-ответ/подтверждение» вполне неплохо работают и на микроконтроллерах. По крайней мере у меня было несколько реализованных проектов с подобными протоколами общения между модулями, все очень неплохо ложилось в линейную программу без всяких RTOS. Естественно, с использованием прерывания на том интерфейсе, который отвечал за канал данных.
Сейчас вот делаю девайс, который должен время от времени отправлять данные на сервер через модем и принимать от него запросы, команды, обновление прошивки и т.п. Тоже набросал типовой бинарный протокол с фиксированными заголовками, данными переменной длины и гарантированной доставкой пакетов. Все отлично работает, не напрягая микроконтроллер функциями типа strstr() и scanf() :)
По поводу «дернул ножкой» — да, я хотел написать, что этому измерителю не помешал бы выход прерывания, но не стал расписывать. Например, микроконтроллер дал ему команду измерить и занялся дальше своими делами, а модуль притянул этот свой выход к земле («занято»). Как только измерение закончено, модуль отключает притягивание этого выхода к земле («свободно»), запуская в микроконтроллере прерывание. Ну или микроконтроллер сам время от времени проверяет уровень этого выхода модуля и если обнаруживает что там единица, запрашивает у модуля готовые данные. Распространенное решение :)
Сейчас вот делаю девайс, который должен время от времени отправлять данные на сервер через модем и принимать от него запросы, команды, обновление прошивки и т.п. Тоже набросал типовой бинарный протокол с фиксированными заголовками, данными переменной длины и гарантированной доставкой пакетов. Все отлично работает, не напрягая микроконтроллер функциями типа strstr() и scanf() :)
По поводу «дернул ножкой» — да, я хотел написать, что этому измерителю не помешал бы выход прерывания, но не стал расписывать. Например, микроконтроллер дал ему команду измерить и занялся дальше своими делами, а модуль притянул этот свой выход к земле («занято»). Как только измерение закончено, модуль отключает притягивание этого выхода к земле («свободно»), запуская в микроконтроллере прерывание. Ну или микроконтроллер сам время от времени проверяет уровень этого выхода модуля и если обнаруживает что там единица, запрашивает у модуля готовые данные. Распространенное решение :)
наложить на него указатель соответствующей структуры — ну это пока там нет полей переменной длины: строк, массивов и т.п
Само собой. Но в бинарных данных все это решается гораздо проще, чем в текстовых.
habr.com/ru/users/alexzeed
Откуда в простой железяке появятся случайные данные? Это-же не радиомодуль, это девайс с жёсткими фиксированными таймингами. Есть окно на отправку импульса, есть окно на приём. Мешать их нельзя, всю служебную информацию можно оправлять в каждом пакете с данными — там времени и места вагон.
Другое дело что ультразвуковой дальномер с одним излучателем/приёмником — это как-бы вчерашний день. Да, комплектующие свежие, точность чуть выше, но результат как у 100500 аналогичных устройств.
Имея два приёмника можно обнаруживать несколько объектов на линии горизонта — несколько самых громких и ближних. А если три приёмника — то уже в плоскости.
А три приёмника + три излучателя — возможность просвечивать интересующие вас участки пространства. На этом этапе однотоновая посылка становится мало информативной. А разбор ответа требует современных быстрых мк.
В этом случае заголовок бинарного пакета определяет его свойства — можно обрабатывать на лету.
Откуда в простой железяке появятся случайные данные? Это-же не радиомодуль, это девайс с жёсткими фиксированными таймингами. Есть окно на отправку импульса, есть окно на приём. Мешать их нельзя, всю служебную информацию можно оправлять в каждом пакете с данными — там времени и места вагон.
Другое дело что ультразвуковой дальномер с одним излучателем/приёмником — это как-бы вчерашний день. Да, комплектующие свежие, точность чуть выше, но результат как у 100500 аналогичных устройств.
Имея два приёмника можно обнаруживать несколько объектов на линии горизонта — несколько самых громких и ближних. А если три приёмника — то уже в плоскости.
А три приёмника + три излучателя — возможность просвечивать интересующие вас участки пространства. На этом этапе однотоновая посылка становится мало информативной. А разбор ответа требует современных быстрых мк.
В этом случае заголовок бинарного пакета определяет его свойства — можно обрабатывать на лету.
У модема проблема не в текстовости, а в полной асинхронности — когда у тебя ответ на запрос приходит через неизвестный промежуток времени, а иногда вместо него вообще приходит какой-нибудь RING.
Да, и я так и не придумал как малой кровью на 100% побороть это :) Когда, например, принимаемые бинарные данные обрываются текстовым сообщением «CLOSED» :)
Немало крови попило и то, о чем Вы пишете — когда ответ на запрос приходит не в виде:
а в виде:
Или вообще:
Немало крови попило и то, о чем Вы пишете — когда ответ на запрос приходит не в виде:
<ответ>
OK
а в виде:
OK
(прошло какое-то время)
<ответ>
Или вообще:
OK
(прошло какое-то время)
<какое-то левое асинхронное сообщение>
<ответ>
Для применённого транзистора экспериментально получена характеристика вносимого затухания, в зависимости от напряжения на затворе. На основе этой характеристики, и указанной пользователем параметров среды, рассчитывается таблица значений, которая посредством DMA отправляется в ЦАП микроконтроллера.
Вы как-то учитывали разброс параметров транзистора и зависимость от температуры?
Спасибо за вопрос. Сейчас температура не учитывается вообще никак. Она, действительно, ощутимо влияет на параметры транзистора на границе открытия. К счастью, это всё можно учесть в прошивке. Темодатчики встроены в корпуса микроконтроллера и гироскопа/акселерометра.
Да, но есть еще производственный разброс. Надеюсь вы проверили на нескольких экземплярах. Лучше было бы завести управление через real time обратную связь на МК как то, что бы вообще не зависеть от параметров транзистора. Вдруг текущий снимут с производства.
Вы описали идеальный случай. Я мог бы сказать, что у нас не осталось свободных каналов АЦП и т.д. и т.п. Но в реальности, высокая точность регулировки усиления не сильно тут важна, и мы не заботимся об этом сознательно, упрощая и ускоряя процесс разработки. Достаточно преодолеть порог открытия транзистора, и работать в пределах его линейного режима с небольшой погрешностью в итоговом коэффициенте усиления.
Некоторые комментаторы к предыдущей заметке рекомендовали ВАРУ. Да, применение ВАРУ оказалось очень уместным. Теперь, в первые мгновения после посылки зондирующего импульса, есть возможность сделать коэффициент усиления минимальным и увеличивать его с течением времени.
Есть другой вариант — менять мощность выхлопа в ультразвук. Мы в дальномере с диапазоном 300...6000 мм, например, подаём на излучатель 5 импульсов, смотрим зону до 2000 мм, если там ничего нет — подаём 15 импульсов, смотрим 2000...4000 мм, потом 25 и 4000...6000.
И это помогает не столько с зашкаливанием на отражении от близких объектов, сколько с уменьшением собственного звона излучателя.
Повышающий преобразователь позволяет сделать наш излучатель чуть «громче». Можно регулировать напряжение питания выходного каскада с 5 до 16 Вольт
Можно проще — LC-контур из излучателя и индуктивности, возбуждаемый драйвером, вполне себе сам себе повышающий преобразователь, на котором можно развить 10-15 В. Очень дёшево и практично, минус — с температурой ёмкость излучателя меняется.
LC-контур из излучателя и индуктивности это не очень хорошее решение, поскольку сделать так, чтобы его частота совпадала с частотой резонанса излучателя почти невозможно (в частности из-за температурных уходов). А излучатель, даже специально задемпфированный, это довольно добротная штука.
Есть другой вариант — менять мощность выхлопа в ультразвук. Мы в дальномере с диапазоном 300...6000 мм, например, подаём на излучатель 5 импульсов, смотрим зону до 2000 мм, если там ничего нет — подаём 15 импульсов, смотрим 2000...4000 мм, потом 25 и 4000...6000.
Этот метод рабочий, но, к сожалению, понижает полезную частоту обновления данных на выходе. Более того, большое количество импульсов в пачке снижает разрешение (детализацию). Например, было проверено, что два импульса в пачке при сканировании обычной стеклянной бутылки на расстоянии 40см дают отчётливую картину отражения сигнала от передней и задней стенок бутылки. Если увеличить количество импульсов до, примерно, десяти, то эти два отражения сливаются в одно.
Думаю, что увеличение именно мощности излучения позволит не терять в разрешении на более дальних дистанциях. Хотя понимаю, что бесконечно повышать мощность нельзя. Наступит момент, когда излишняя мощность будет просто съедаться кавитацией.
Про добротность хотел добавить.
Добротность нашего излучателя в воде, к счастью, никакая ))) Излучатель согласован неплохо, звон практически отсутствует. Большая часть энергии уходит в воду.
Можно проще — LC-контур из излучателя и индуктивности, возбуждаемый драйвером, вполне себе сам себе повышающий преобразователь, на котором можно развить 10-15 В.
Как я заметил ранее, добротность излучателя крайне мала, так что резонансная система вряд ли будет эффективной.
Ну и когда я заявлял о диапазоне 5-16 Вольт, то речь шла о напряжении питания драйвера первичной обмотки повышающего трансформатора. На самом пьезоэлементе (подключен ко вторичке транса) амплитуда превышает 500 Вольт.
Про использование Mavlink не думали?
А Wake протокол не рассматривали? Вроде достаточно простой.
p.s. Не совсем по теме, но ни у кого не завалялся код асинхронного чтения com порта на Си и winapi(да, пока нужны свои велосипеды для понимания)? Застрял на этом месте, нет стабильного приёма.
p.s. Не совсем по теме, но ни у кого не завалялся код асинхронного чтения com порта на Си и winapi(да, пока нужны свои велосипеды для понимания)? Застрял на этом месте, нет стабильного приёма.
В протоколе, использующем UART:
— передача текста использует XON/XOFF (0x11;0x13)
— для передачи бинарных данных потребуется еще два провода/сигнала RTx;CTx, либо конвертировать bin<->hex
— передача текста использует XON/XOFF (0x11;0x13)
— для передачи бинарных данных потребуется еще два провода/сигнала RTx;CTx, либо конвертировать bin<->hex
Когда в прошлой жизни в моей конторе делали усилитель с ВАРУ (назывался ЛУВР — линейный усилитель с временной регулировкой), то в нем в обратную связь был включен ЦАП, который, в свою очередь, управлялся данными с ППЗУ с выборкой по временному регистру. Точность была очень высокой.
Ещё как вариант можно было сделать I2C потенциометр, который работал бы как аттенюатор для ослабления промежуточного сигнала.
По габаритам занял бы столько же места.
По управлению может было бы и проще. Тут надо экспериментировать.
Так как Вы транзистор в линейном режиме используете, у Вас h21 будет влиять на работу.
Я правильно понимаю, что от прибора к прибору значения напряжения, подаваемые с DAC на затвор транзистора немного разные?
По габаритам занял бы столько же места.
По управлению может было бы и проще. Тут надо экспериментировать.
Так как Вы транзистор в линейном режиме используете, у Вас h21 будет влиять на работу.
Я правильно понимаю, что от прибора к прибору значения напряжения, подаваемые с DAC на затвор транзистора немного разные?
Даже в мыслях не было ставить компонент, сложнее транзистора. Точность аттенюации здесь не важна особо. Ну будет не в 10 раз сигнал ослабляться, а в 9, или в 11 раз, не страшно. Главное, чтоб вся амплитуда выходного сигнала умещалась в диапазон измерения АЦП. Лучше, когда мы имеем небольшой коэффициент усиления, но при этом не упускаем детали, которые были бы не видны, если был бы сплошной зашкал.
Понравилось решение с планарным трансформатором.
Делал подобный вариант, только у меня набор был из 4-х плат.
Не расскажете вкратце, можно ссылку, по какому принципу проводили расчёт?
Делал подобный вариант, только у меня набор был из 4-х плат.
Не расскажете вкратце, можно ссылку, по какому принципу проводили расчёт?
С трансформатором история такая:
В первую очередь, выбирался сердечник. Выбор происходил из самых маленьких и доступных к заказу.
Во вторую очередь, исходя из требований производства печатных плат были нарисованы дорожки вторичной обмотки с максимально возможным заполнением трёх слоёв платы. На первичку остался один слой. Количество витков первички — 1.5. Эта цифра была определена экспериментальным путём, на основе опытов с трансформатором предыдущей версии.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Модуль подводного ультразвукового дальномера. Часть вторая