Русский
Русский
English
Статистика
Реклама

Разработка для интернета вещей

Интернет вещей по-русски. Канальный уровень OpenUNB. Общие положения и адресация устройств

05.02.2021 12:22:10 | Автор: admin

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


Так как канальный уровень OpenUNB довольно сложен, я решил разбить его на подсистемы и описывать их в отдельных статьях. Кстати, приведу список всех наших статей об OpenUNB:



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


Канальный уровень отвечает за механизм управления доступом устройств к радиоканалу (Media Access Control, MAC) и механизм управления логической связью (Logical Link Control, LLC) между устройствами и сервером сети.


Канальный уровень определяет:


  1. механизм множественного доступа устройств к радиоканалу;
  2. механизм повторных передач пакетов;
  3. формат пакетов канального уровня и алгоритм их формирования;
  4. схему адресации устройств;
  5. процедуру активации (аутентификации и регистрации) устройств на сервере;
  6. механизм криптографической защиты передаваемых данных (шифрование, контроль целостности и подлинности).

Сегодня мы рассмотрим первые четыре пункта списка.


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


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


Формат пакета OpenUNB по уровням:


image


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


В эти шесть байт входят адрес (DevAddr) и проверочное слово (MIC). Обе эти части имеют одинаковый размер (три байта) и простые, но тщательно отточенные разработчиками свойства.


Слово DevAddr это временный адрес устройства. В лирическом отступлении можно отметить, что мало можно найти протоколов IoT, в которые внедрена концепция временных адресов, хотя в сотовой связи она присутствует начиная со стандартов 2G. В OpenUNB временный адрес (меняется каждые 4 часа) формируется криптографически из базового ключа K0, привязанного к DevID, назначение которого имеет необыкновенную гибкость. Во-первых, DevID может не быть уникальным. Пользователь даже может назначить DevID случайным образом. Уникальность DevID придаст назначение соответствующего ему базового секретного ключа K0. Во-вторых, нет даже требований к длине DevID. Стандарт требует иметь его длину не менее 4 байт, но рекомендует длину 16 байт. В-третьих, такая гибкость приводит к возможности назначать DevID в разных сетях децентрализовано, не сверяясь друг с другом.


Если говорить точно, временный адрес DevAddr вырабатывается так:


$ DevAddr = MSB24 (ECB (Ka, 0x01 || Ne || 0^{n-32})),$


где Ne номер эпохи (время), а Ka ключ активации, который получается так:


$ Ka = CTR (K0, Na || 0^{n/2-16}, 0^k),$


где Na номер активации, а K0 базовый секретный ключ.


Процедуры ECB и CTR здесь это криптопреобразования "режим простой замены" и "режим гаммирования", соответственно. Эти процедуры определены в стандартах шифрования ГОСТ.


Таким образом, если считать криптопреобразования стойкими, а ключ K0 секретным, связь между DevID и DevAddr экономически оправданным способом установить не получится. Поэтому третья сторона не может сопоставить пакеты в эфире с конкретным устройством IoT, не зная ключ K0. Какой еще протокол IoT может похвастаться таким удивительным свойством?!


Слово MIC, проверочное слово, уникально. Оно имеет по меньшей мере две ипостаси: это имитовставка и слово контроля целостности в одном лице. За счет этого двойного назначения получается немалая экономия в объеме данных, а значит и в энергии, потребляемой устройством. Есть еще третья функция MIC, скрытая от неискушенного читателя. Это конкретизация соответствия DevAddr и DevID. Очевидно, ввиду малости длины DevAddr, это поле не будет уникальным для всех DevID, по крайней мере это не гарантируется криптопреобразованиями. Но существует связь DevAddr и MIC, которая определяется секретным ключом K0 и другими параметрами. Если говорить точно, то чудо-слово MIC получается так:


$MIC = CMAC24 (Km, P),$


где значение вектора P зависит от длины блока n и длины поля MACPayload. Пусть len
однобайтная целочисленная беззнаковая переменная, равная длине полезных данных
MACPayload в битах (переменная len может принимать значения 16 или 48), тогда:


если len = 48 и n = 64, то


$P = DevAddr || MACPayload || Nn || 0^{2n-len-48} || len;$


в остальных случаях


$P = DevAddr || MACPayload || Nn || 0^{n-len-48} || len.$


Процедура CMAC24 здесь это криптопреобразование "режим выработки имитовставки" согласно ГОСТ.


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


Про DevID

Идентификатор устройства DevID записывается в энергонезависимую память устройства, а также хранится на сервере сети. Идентификатор DevID должен иметь длину не менее 4 байт, а его формат может быть различным (например, в разных сетях может использоваться свой формат идентификаторов). Рекомендуется использовать идентификаторы DevID длиной не менее 128 бит.


Устройства, работающие в разных сетях, могут иметь одинаковые идентификаторы DevID. Таким образом, назначение идентификаторов DevID в каждой сети может осуществляться независимо. Например, если идентификаторы DevID назначают операторы сети, то им не требуется договариваться друг с другом об уникальности идентификаторов DevID для устройств из разных сетей. Рекомендуется, чтобы устройства, работающие в одной сети, имели уникальные идентификаторы DevID. Например, их может централизованно назначать оператор сети. Однако допустимо, чтобы устройства, работающие в одной сети, имели совпадающие идентификаторы DevID. Например, пользователи могут сами назначать устройствам случайные идентификаторы DevID и сообщать их на сервер сети при активации устройства. Алгоритм разрешения ситуаций, когда несколько устройств из одной или разных сетей имеют одинаковые идентификаторы DevID, представлен в стандарте.


Про DevAddr

Временный адрес устройства DevAddr имеет фиксированную длину 3 байта. Значение временного адреса устройства DevAddr изменяется в процессе работы устройства и передается в пакетах канального уровня:


  • начальное значение временного адреса DevAddr0 = CRC24 (DevID). Этот адрес передается только в служебных пакетах активации, которые отправляются при активации устройства для его аутентификации и регистрации на сервере сети;
  • для всех последующих пакетов, передающих полезные данные уровня приложений, устройство использует временный адрес DevAddr, который пересчитывается каждую эпоху (раз в EPOCH_DURATION) с помощью функции криптографического преобразования.

Важно отметить, что используемая схема вычисления временных адресов DevAddr не гарантирует их уникальность. Разрешение возможных коллизий временных адресов разных устройств осуществляется на сервере сети при расшифровании принятых пакетов на этапе проверки имитовставки MIC.


Временные адреса позволяют решить технические и организационные вопросы, иногда нерешаемые. В обычных системах IoT адреса назначаются централизованно, что дает исполнителю этой несложной функции особую роль в системе и увеличенное влияние. Это также делает необходимым внедрение процедур, которые могут быть неудобными для исполнения маленькими организациями и частными лицами. OpenUNB позволяет избежать этих неудобств.


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


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


Пока писалась эта статья, пришла отличная новость: стандарт опубликован на сайте Сколтеха. Теперь полная картина не ускользнет от вас.

Подробнее..

Интернет вещей по-русски. Процедура активации OpenUNB

28.02.2021 12:13:00 | Автор: admin

Односторонний характер протокола OpenUNB накладывает отпечаток на все процедуры протокола. Разработчики OpenUNB, стремясь разработать защищенный протокол, создали на первый взгляд довольно сложную процедуру вхождения устройства в сеть активацию. Давайте разберем ее в деталях.


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


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


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


В OpenUNB активация устройства производится пользователем. Также необходим доверенный канал между пользователем и сервером сети. Схема взаимодействия представлена ниже:


image


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


В стадии "запрос на активацию" пользователь должен по служебному каналу отправить на сервер запрос на активацию, в котором передается идентификатор DevID активируемого конечного устройства. Если активация возможна, то сервер сообщает об этом. Далее пользователь делает "запуск процедуры активации на устройстве". Это может быть пакет по радио-интерфейсу или другому, удобному. Это также может быть нажатие кнопки "активация" или просто включение питания устройства. После этого события устройство передает "служебный пакет активации", в котором содержится номер текущей активации.


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


Рассмотрим подробно процедуру со стороны устройства и со стороны сервера.


Со стороны устройства процедура выглядит так:


  1. проверяется текущее значение счетчика активаций Na. Если счетчик активаций уже достиг максимально возможного значения, то данное устройство больше не может использоваться, и выключается;
  2. увеличивается значение счетчика активаций: Na = Na + 1;
  3. вырабатывается ключ активации Ka;
  4. вырабатывается ключ расчета имитовставки Km для эпохи Ne = 0;
  5. формируется служебный пакет активации, в поле MACPayload которого содержится текущее значение счетчика активаций Na, а в качестве адреса указывается DevAddr0 = CRC24(DevID). При этом поле MACPayload передается в открытом виде (не шифруется), а поле имитовставки MIC рассчитывается на ключе Km для номера Nn = 0. Сформированный служебный пакет активации должен быть отправлен MAX_PKT_TX_NUM раз подряд для повышения вероятности его доведения;
  6. устройство считает активацию успешно завершенной и может передавать пакеты полезных данных.

Напомним формат пакета OpenUNB:
image


Сервер по приему пакета активации ищет адрес из пакета в списке адресов активированных устройств. Для каждого из найденных совпадений:


  1. сохраняется полученное значение счетчика активаций устройства Na. Если для данного устройства ранее уже осуществлялась успешная активация, то сервер должен дополнительно проверить, что текущее значение Na больше чем значение Na, полученное при предыдущей успешной активации. Если эта проверка завершается неуспешно, то сервер переходит к следующему найденному устройству;
  2. вырабатывается ключ активации Ka;
  3. вырабатывается ключ расчета имитовставки Km для эпохи Ne = 0;
  4. для пакета проверяется совпадение имитовставки MIC на ключе Km для номера Nn = 0.

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


Детали работы процедур активации OpenUNB смотрите в первоисточнике на сайте Сколтеха.


Реализованные процедуры активации и другие процедуры безопасности доступны в исходниках здесь.


Наш бессменный мастер Интернета вещей deef137 всегда на связи и готов помочь с вопросами по коду.

Подробнее..

Интернет вещей по-русски. Безопасность в OpenUNB

08.03.2021 14:16:44 | Автор: admin

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


Для иллюстрации актуальности я приведу в пример протокол CRISP, кстати, отечественной разработки. Наличие такой разработки, доведенной уже до статуса методических рекомендаций Технического комитета по стандартизации "Криптографическая защита информации", подтверждает практическую непригодность обычных "тяжелых" протоколов безопасности для Интернета вещей. Они оказываются слишком ресурсоемкими.


Различных радио-протоколов Интернета вещей сейчас наплодилось огромное множество, но в сфере LPWAN не везде разработчики протокола передачи берут на себя тяжелую ношу защиты информации. Можно долго спорить, нужно ли вообще включать защиту в радио-протокол LPWAN, а не перекладывать ее на вышележащие уровни, но если предложенная схема хороша, то стоит надеяться на большую вероятность внедрения стандарта в индустрию. Главный тезис: вообще без защиты в Интернете вещей сейчас уже нельзя. И она должна быть на уровне.


Так же рассуждали и разработчики OpenUNB, ставя во главу угла энергоэффективность и встроенную безопасность информации. Тем, кто еще ничего не знает про OpenUNB, я советую прочитать предыдущие статьи на эту тему:



а также изучить первоисточник на сайте Сколтеха.


Сегодня мы рассмотрим механизм криптографической защиты передаваемых данных (шифрование, контроль целостности и подлинности).


Чтобы обеспечить базу безопасности, у каждого устройства и сервера должно быть что-то общее, секретное, которое никто не знает. В OpenUNB это секретный ключ шифрования K0, имеющий длину k, равную 128 или 256 бит. Весь остальной протокол должен быть сделан так, чтобы этот базовый, основной ключ не стал бы известен никому никаким образом, а информация при этом была защищена. Поэтому базовый ключ претерпевает такое множество преобразований в своем стремлении встретиться с информацией.


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


В недрах устройства и сервера OpenUNB есть счетчик активаций Na и счетчик эпох Ne, которые остаются примерно одинаковыми в процессе работы системы. Сначала вырабатывается ключ активации:


$ Ka = CTR (K0, Na || 0^{n/2-16}, 0^k).$


Потом уже по ключу активации вырабатываются рабочие ключ шифрования Km и ключ имитозащиты Ke:


$ Km = CTR (Ka, 0x02 || Ne || 0^{n/2-32}, 0^k),$


$ Ke = CTR (Ka, 0x03 || Ne || 0^{n/2-32}, 0^k).$


Для криптографических преобразований разработчики OpenUNB рекомендуется использовать блочный шифр Магма, который имеет длину блока n = 64 бита и длину ключа k = 256 бит, определенный в стандарте ГОСТ Р 34.12-2015.


Шифрование выглядит так:


$ EncryptedMACPayload = CTR (Ke, Nn || 0^{n/2-16}, MACPayload),$


где Nn номер пакета, а выработка имитовставки так:


$MIC = CMAC24 (Km, P),$


где значение вектора P зависит от длины блока n и длины поля MACPayload. Пусть len
однобайтная целочисленная беззнаковая переменная, равная длине полезных данных
MACPayload в битах (переменная len может принимать значения 16 или 48), тогда:


если len = 48 и n = 64, то


$P = DevAddr || MACPayload || Nn || 0^{2n-len-48} || len;$


в остальных случаях


$P = DevAddr || MACPayload || Nn || 0^{n-len-48} || len.$


Процедура CMAC24 здесь это криптопреобразование "режим выработки имитовставки" согласно ГОСТ.


Далее эти поля вставляются на свои места. Напомним схему формирования пакета:
image


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


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


Как всегда, исходники крипто-преобразований от deef137 доступны на Github.

Подробнее..

Топ-50 мировых лидеров Интернета вещей 2021 гаджеты, софт и сервисы

29.04.2021 00:23:42 | Автор: admin

Персональный компьютер Lenovo ThinkCentre M75n на процессоре AMD Ryzen 5 PRO

Журнал Computer Reseller News (CRN) ежегодно составляет рейтинг Internet of Things 50, выбирая полсотни самых крутых игроков индустрии на данный момент.

Свежий рейтинг 2021 года составлен по пяти категориям:


10 самых крутых производителей оборудования


По прогнозу Gartner, количество устройств IoT в мире вырастет до 5,8 млрд на конец текущего года. Очевидно, производителям сейчас нелегко в условиях глобального дефицита микросхем на всех рынках.

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

  • Advantech (Тайвань), специализированное оборудование: от киосков самообслуживания до систем машинного зрения для заводов
  • AMD, линейка встроенных процессоров Ryzen Embedded V2000
  • Cisco Systems (США), расширение функциональности AWS IoT Core
  • Dell Technologies
  • Hewlett Packard Enterprise
  • Intel, функция Intel Time Coordinated Computing в последних CPU, а также линейка процессоров Atom x6000E
  • Lenovo, компьютер ThinkCentre M75n IoT (на КДПВ), встроенные компьютеры ThinkEdge SE30 и SE50
  • Nvidia, система-на-кристалле Jetson Xavier NX
  • Qualcomm, модем Qualcomm 212 LTE для сетей NB-IoT
  • Supermicro, платформа Intelligent Retail Edge


10 самых крутых софтверных компаний


  • Akamai, сервис IoT Edge Connect на базе фирменной CDN
  • Amazon Web Services, ряд новых сервисов, в том числе управляемый сервис AWS IoT SiteWise для сбора и мониторинга данных с промышленного оборудования, а также AWS Snowcone и Amazon Monitron
  • Edgeworx, платформа ioFog для деплоя микросервисов на различные типы устройств в различных сетях (Kubernetes для IoT), а также видеокамера Darcy с машинным зрением и автоматической проверкой наличия масок на людях, среди прочих функций
  • EDJX, глобальная инфраструктура IoT в масштабе планеты
  • IOTech (Великобритания), опенсорсная платформа EdgeXpert
  • Kloudspot, корпоративная система наблюдения QuickStart (Situational Awareness and Intelligence Platform)
  • Microsoft, покупка стартапа CyberX (безопасность IoT), расширение функций Azure IoT, система Azure Digital Twins для цифрового моделирования объектов реального мира
  • Nubix, встроенные приложения с поддержкой контейнеров на устройствах под Linux с ОС реального времени
  • Pelion, дочерняя компания Arm, софт для управления инфраструктурой устройств IoT через контейнеры Kubernetes
  • Zededa, запуск легаси в VM рядом с новыми приложениями в контейнерах, оркестрация, опенсорсная операционная система EVE-OS


10 самых крутых компаний в области связи и подключения устройств


  • Aeris Communications, платформа Aeris Connectivity Platform
  • BehrTech (Канада), протокол дальней радиосвязи MIOTY
  • Celona, приватные мобильные сети LTE и 5G
  • Eseye, технология AnyNet+ SIM для незаметного переключения между мобильными сетями


  • Infiot, платформа Intelligent Edge как альтернатива VPN и SD-WAN
  • NetFoundry
  • Senet, провайдер LPWAN
  • Sierra Wireless, системный интегратор для развёртывания корпоративных сетей IoT
  • Verizon
  • Windstream


10 самых крутых компаний в промышленном секторе


  • FogHorn, инновационный стартап внедряет различные системы ИИ в промышленное производство
  • Hitachi Vantara, платформа Lumada IoT
  • KMC Controls, платформа KMC Commander IoT для сбора, визуализации и анализа информации с сенсоров и устройств, установки уведомлений и предупреждений
  • Litmus Automation, платформа Litmus Edge собирает данные с 250 типов устройств, последняя версия Litmus Edge 3.0 поддерживает аналитику, цифровые двойники объектов и алгоритмы машинного обучения
  • PTC, технологии IoT и дополненной реальности разрабатываются в альянсе с Rockwell Automation и Fujitsu
  • Radix IoT, управление производством на основе данных
  • Samsara
  • Schneider Electric (Франция), платформа EcoStruxure Power IoT
  • Siemens (Германия), огромное количество аппаратных и программных продуктов для IoT, таких как настенный тачскрин KNX Touch Control TC5 для управления умной квартирой (освещение, кондиционер, вентиляция, жалюзи), а также ряд промышленных систем
  • Software AG (Германия), новое приложение TrendMiner (в каталоге SAP) для промышленной аналитики на умных фабриках


10 самых крутых компаний в безопасности


  • Armis (Евгений Дибров), система Armis Asset Management для изучения всех устройств, подключённых к сети, и оценки рисков
  • Claroty
  • GlobalSign, платформа IoT Identity Platform обеспечивает защиту сетей IoT с поддержкой шифрования, аутентификации и авторизации. Работает на инфраструктуре публичных ключей с сертификатами от центра сертификации GlobalSign. Управление удостоверениями устройств на протяжении всего жизненного цикла, в том числе автоматическая подготовка, выпуск, продление и вывод из эксплуатации в конце срока службы


  • Karamba Security (Израиль), платформа XGuard Monitor
  • Medigate, защищённая аналитическая платформа для учреждения здравоохранения
  • Ockam, система безопасности с поддержкой криптографии и блокчейна
  • Ordr, мониторинг подключённых устройств, система Systems Control Engine с элементами машинного обучения
  • ReFirm Labs, платформа Binwalk проверяет уязвимости во всех прошивках всех устройств
  • Sepio Systems, защита сети от подозрительных устройств и нежелательных подключений извне
  • Vdoo (Израиль), поиск и устранение уязвимостей в устройствах IoT, проверка на соответствие стандартам безопасности.





Подробнее..

ESP32-C3 первое знакомство. Заменим ESP8266?

12.02.2021 18:18:50 | Автор: admin

Новая игрушка

В ноябре 2020 года Espressif анонсировала новую SoC под названием ESP32-C3. Они разослали несколько инженерных прототипов для тестирования и первого ознакомления.

Так довелось, что мне попался один из них на руки и я успел немного поиграться с ним. Надеюсь, мой краткий опыт будет интересен сообществу, так как тут есть на что посмотреть и ESP32-C3 имеет хороший шанс получить свою нишу в мире встраиваемых систем, так и в области DIY. Меня как раз больше интересует подход со стороны DIY, поэтому статья будет больше с этим уклоном.

В чём разница?

ESP32-C3 пытается занять нишу между ESP32/ESP32-S и нашим старым другом ESP8266. Даже больше хочет вытеснить ESP8266, чем быть дополнением к линейке ESP32.

Не знаю что там будет с ценами, но переход на RISC-V, упрощение периферии и прочее может сделать ESP32-C3 достаточно привлекательным, что бы он смог заменить ESP8266 полностью. В итоге мы получим достойную замену старичку, с которым мы вместе с 2014 года.

В таблице ниже я привёл основные отличия ESP32-C3 от предыдущих ESP32 и ESP32-S2. Так же у Espressif недавно был анонсирован ESP32-S3 с двумя ядрами, но я пока не буду его приводить ниже в силу отсутствия его в широкой продаже.

ESP32

ESP32-S2

ESP32-C3

CPU

Xtensa LX6

Xtensa LX7

RISC-V (RV32IMC)

Частота CPU

160 / 240 MHz

160 / 240 MHz

160 MHz

Количество ядер CPU

2 / 1

1

1

ULP CPU

ULP-FSM

ULP-RISC-V

ULP-FSM

-

SRAM

520 KB

320 KB

400 KB

RTC SRAM

16 KB

8 KB

8 KB

WiFi

802.11bgn

150 Mbit

802.11bgn, 802.11mc

150 Mbit

802.11 bgn, 802.11mc

150 Mbit

Bluetooth

4.2 BR/EDR BLE

-

Bluetooth 5

GPIO

34

43

22

12-bit ADC

1

18 каналов

2

20 каналов

2

6 каналов

8-bit DAC

2

2

-

Touch sensor

10

14

-

SPI

4

4

3

I2S

2

1

1

I2C

2

2

1

UART

3

2

2

SDIO

1

-

-

Ethernet MAC

1

-

-

PWM

16

8

6

USB OTG

-

1

-

Потребление

До 240 мА

До 310 мА

До 325 мА

Modem sleep

27 - 68 мА

12 - 19 мА

15 - 20 мА

Light sleep

0,8 мА

0,45 мА

0,13 мА

Deep sleep

0,01 - 0,15 мА

0,02 - 0,19 мА

0,005 мА

Корпус

48 выводов

56 выводов

32 вывода

Как ESP8266, но не все выводы такие же

DevKit плата

ESP32-C3 приехал ко мне в виде платы ESP32-C3-DevKitM-1, на которой установлен модуль ESP32-C3-Mini-1 со встроенной 4 МБ флеш-памятью.

Так же на этой плате стоит USB-Serial конвертер CP2102 для подключения и прошивки по USB. На GPIO подключен RGB светодиод WS2812.

Сам модуль ESP32-C3-Mini-1 физически по размеру заметно меньше того же ESP-12E на базе ESP8266. И в то же время ESP32-C3 имеет намного больше возможностей.

"Engineering Sample Notes"

С платой была одностраничное приложение с некоторыми пометками.

Например, там написано, что потребление на DevKit'е ещё не достаточно оптимизировано и потому не рекомендуется для оценки в Deep-sleep режиме.

Так же сказано, что в данной версии чипа поддержка USB Serial/JTAG отсутствует, но она будет присутствовать в финальной версии.

Текущая версия ESP-IDF в процесс работы по добавлению поддержки ESP32-C3. Работа в этом направлении ведётся в ветках "master" и "release/v4.3".

Поддержка ESP-IDF

ESP-IDF является официальным фреймворком для разработки под ESP32. Сама среда поддерживает всю линейку ESP32. Большинство примеров можно собрать под Xtensa LX6/LX7, так и под RISC-V. Переключение сводится к одной команде "idf.py set-target esp32c3", которая выставляет riscv32-esp-elf- и прочие параметры в sdkconfig. Теперь после компиляции у нас готова прошивка для нового ESP32-C3.

Предварительно надо подготовить окружение в зависимости от ОС: Windows, Linux или macOS.

git clone --recursive https://github.com/espressif/esp-idf.gitcd esp-idf# Linux/macOS./install.sh# Windowsinstall.ps1

Установочный скрипт скачает компиляторы и дополнительные пакеты для ESP-IDF. После этого надо импортировать окружение для начала работы:

# Linux/macOS. ./export.sh# Windowsexport.bat

Рекомендую для проверки собрать "hello world":

cd examples/get-started/blink# По-умолчанию настроено для ESP32, но если надо собрать прошивку для ESP32-S2idf.py set-target esp32s2# Или для ESP32-C3idf.py set-target esp32c3# Сборка, прошивка, USB консольidf.py build flash monitor

Не все примеры собираются под ESP32-C3, но Espressif активно работает над ESP-IDF для поддержки этого чипа.

CoreMark

Ради интереса запустил CoreMark бенчмарк для оценки производительности нового RISC-V ядра и сравнил эти данные с предыдущим ESP32 (к сожалению, у меня нет ESP32-S2 для более широкого сравнения).

Ниже приведены попугаи для разной частоты процессора и для общего ознакомления добавлены значения при компиляции с выключенными оптимизациями (-O0):

CoreMark 1.0

GCC

Частота CPU

ESP32-C3

388

GCC8.4.0 -O3

160 МГц

98

GCC8.4.0 -O0

160 МГц

ESP32 (одно ядро)

313

GCC8.4.0 -O3

160 МГц

77

GCC8.4.0 -O0

160 МГц

469

GCC8.4.0 -O3

240 МГц

115

GCC8.4.0 -O0

240 МГц

Я сделал измерения ESP32-C3 на 80 МГц, но значения получились ровно в два раза ниже, что и предполагалось и поэтому в таблице не привожу.

В попугаях RISC-V получился примерно на 24% быстрее. Конечно, обычные задачи, которыми мы загружаем такие микроконтроллеры будут сильно отличаться от синтетических бенчмарков, но было интересно посмотреть.

Надо так же не забывать, что ESP32 поддерживает работу на частоте 240 МГц, а у ESP32-C3 максимальная частота только 160 МГц. Так же ESP32 имеет два ядра, которые можно задействовать в зависимости от задач.

Но повышенная частота 240 МГц так же скажется на потреблении устройства. То есть, ESP32-C3 за каждый попугай будет просить меньше электронов (я не измерял потребление, но есть несколько замеров других наблюдателей).

ESP RainMaker

Вместе с этой новой платой Espressif продвигает платформу ESP RainMaker. Это некая среда, которая позволяет быстро создавать концепты и прототипы для IoT устройств.

На ESP32-C3-DevKitM-1 плате уже была прошивка ESP RainMaker, с которой можно получить общее представление об этом платформе.

Идея примерно такова:

На плате настроен обычный бинарный переключатель. При подключении платы через USB консоль мы получаем QR код, который надо отсканировать в приложении ESP RainMaker (доступно для Android и iOS) для первоначальной конфигурации настроек WiFi и добавлении этого устройства в приложение.

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

ESP RainMaker SDK позволяет создавать разнообразные устройства, не только бинарный переключатель как в примере. Это может быть датчик измерения температуры или влажности, LCD экран, несколько выключателей сразу или много разных устройств вместе сразу. В последнем случае одна плата будет показана как несколько устройств в приложении.

Для того, что бы поиграться с ESP RainMaker не обязательно ждать когда можно купить ESP32-C3. Сама платформа замечательно работает на ESP32 и ESP32-S2. Для сборки прошивки достаточно иметь настроенный ESP-IDF:

git clone --recursive https://github.com/espressif/esp-rainmaker.gitcd esp-rainmaker/examples/switch# По-умолчанию настроено для ESP32, но если надо собрать прошивку для ESP32-S2idf.py set-target esp32s2# Или для ESP32-C3idf.py set-target esp32c3# Сборка, прошивка, USB консольidf.py build flash monitor

В консоле появится QR код и дальше уже всё в приложении.

Выводы

Большее количество микроконтроллеров для фанатов DIY всегда позитивно, так как при большем выборе можно подобрать более подходящий МК и плату в зависимости от того, что более важно в новом проекте.

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

Отдельное спасибо Espressif за то, что сделали WiFi доступным для встраиваемых устройств 7 лет назад. А там и другие производители подтягиваются. Мы только в плюсе.

Подробнее..

Пайка, C, светодиоды часовой стрим Геннадия Крэйла Круглова

12.03.2021 10:04:49 | Автор: admin

Управлять светодиодом это счастье. Ещё большее счастье смотреть на него в микроскоп. Даже просто зажечь светодиод уже приносит радость. Но готов поспорить эта задача окажется сложнее, чем вы думали.

Привет, меня зовут Крэйл. Я разработчик аппаратной части Яндекс.Станции и большой любитель светодиодов. Сегодня решил вспомнить, как целый час паял, рисовал схемы и программировал микроконтроллеры на YaTalks, и поделиться записью стрима с сообществом Хабра.

О чём я рассказываю в видео

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

А как управлять яркостью? Менять напряжение/ток обычно неудобно, поэтому все используют ШИМ. Воспользуемся ей и мы с помощью STM32 и C++. Но и тут не всё просто. Линейное изменение мощности нелинейно воспринимается глазом нужна коррекция.

Следующий шаг: делаем экран из светодиодов. Несколько сотен каналов! Как управлять яркостью каждого из них? Варианта два: мало проводов плюс динамическая индикация или много проводов и статическая. Что лучше, что хуже, почему, как всё это работает и как выглядит живьём и на осциллографе. Только суровый практический опыт с лампочками, микроскопом и шутками-прибаутками.

Полная запись пайки

Подробнее..

Через тернии к звёздам или LILYGO TTGO T-Internet-POE ESP32 LAN8270A

15.03.2021 10:06:02 | Автор: admin
image
Попалась мне на глаза плата LILYGO TTGO T-Internet-POE ESP32 LAN8270A и конечно я не мог пройти мимо такой интересной новинки: ESP32, LAN8270A, POE, SD карта, Wi-Fi+Ethernet Было интересно пощупать это произведение сумрачного китайского гения своими руками и протестировать в реальной работе, ведь TTX платы сулили очень интересные перспективы для использования в IoT, DIY и вообще в области Wi-Fi+Ethernet и на что фантазии хватит.

Но, как всегда, путь от рекламных проспектов на сайтах продавцов и производителя до запуска платы и проведения на ней тестов оказался очень непростым и тернистым. Далее предлагаю вашему вниманию отчёт о моих увлекательных изысканиях по этой теме.

Камень в огород LILYGO


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

Хорошим примером тут может служить LILYGO TTGO T-Internet-POE ESP32 LAN8270A (далее для краткости будем называть эту плату T-Internet-POE). Производитель сделал интересную плату, но не сделал больше ничего:

  • нет нормальной распиновки контроллера
  • нет принципиальной электрической схемы
  • нет вменяемого описания применения платы и типовых паттернов её использования
  • нет технических пояснений по работе отдельных составляющих платы
  • нет примеров кода (есть 1 (!) скетч на отвали, мальчик, не мешай работать)
  • нет сайта с документацией
  • нет форума с грамотными и мотивированными модераторами
  • нет популярных и мотивирующих статей для тех, кто интересуется этим контроллером, но не знает (не понимает) где он мог бы его применить для своих целей
  • и нет ещё множества вещей, которые должны были бы быть

Короче, нет вообще ничего и каждый, кто рискнёт купить T-Internet-POE, должен быть безупречным воином DIY, иначе у него нет ни одного шанса выстоять в этой битве с LILYGO. Много ли среди нас таких?

И как при таком подходе к делу они вообще умудряются что-то продавать? И насколько выросли бы их продажи, если бы они на минутку отложили в сторону паяльник и вспомнили о своих покупателях?

Вопросы риторические, но так или иначе далее мне придётся проделать всю работу за технический и маркетинговый отделы LILYGO.

В чём фишка?


Говоря простыми словами, на этой плате удалось более-менее удачно объединить в одном устройстве ESP32 (Wi-Fi), Ethernet, POE и ещё добавить к этому торту вишенку в виде microSD картридера. Из одного только сочетания этих составляющих сразу вытекает множество интересных вариантов применения этой платы:

  • работа по Wi-Fi с резервом в виде Ethernet канала
  • работа по Ethernet с резервом в виде Wi-Fi подключения
  • обслуживание одновременно и Wi-Fi и Ethernet линков
  • роутер между Wi-Fi и Ethernet в обе стороны
  • веб-сервер на два интерфейса
  • разные веб-сервера на разных интерфейсах
  • питание (удалённого) контроллера по POE

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

Как вы видите, сфера применения этой платы в IoT и DIY ограничена только вашей фантазией и вашими потребностями и в целом T-Internet-POE как устройство смотрится очень многообещающе.

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

Технические характеристики


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

  • ESP32-WROOM (4 МБ)
  • LAN8720A (Ethernet PHY)
  • POE 802.3af
  • microSD картридер
  • 12 GPIO пинов для внешних подключений

О чём навскидку нам говорит такая конфигурация? О том, что при использовании этой платы в качестве веб-сервера, файлы можно хранить как на microSD карте памяти, так и во внутренней памяти модуля ESP32 (или и там и там сразу).

При этом 12 свободных GPIO производят двойственное впечатление с одной стороны это уже кое-что и значительно лучше чем на ESP8266, а с другой стороны после проектов на Mega 2560 с её десятками GPIO, 12 пинов смотрятся очень и очень скромно и сильно ограничивают возможности разработки тут нужно будет либо изобретать какие-то расширители портов, либо делать тандемные сборки с другими контроллерами.

Варианты контроллера


При ближайшем рассмотрении оказывается, что под одним названием существуют два разных контроллера один на ESP32-WROOM, а второй на ESP32-WROVER-B, что сходу и не разглядишь на вид платы практически одинаковые и можно играть в игру найди 10 отличий.

image

Мне достался контролер на ESP32-WROOM, поэтому дальнейшее повествование будет относится к нему.

Программатор


Инженеры LILYGO так далеко оторвались от своих пользователей, что их решения не всегда можно понять. К таким решениям относится создание ими отдельной платы программатора на чипе CP2104 для контроллера T-Internet-POE.

Зачем? Зачем нужен отдельный программатор, когда этот узел можно было интегрировать на саму плату контроллера или попросту использовать стандартные USB-TTL переходники (как делают все остальные производители железа)? Ответ, видимо, знают только разработчики LILYGO (но простим им этот маленький креатив).

image

Но мало того, что разработчики LILYGO сделали непонятную вещь, они ещё и умудрились сделать её криво:

  • во-первых они применили горячо любимые народом пины с шагом 2,0 мм
  • во-вторых они предусмотрели установку разъёма на обратную (!) сторону платы

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

В результате получился какой-то странный монстр. И всё бы ничего, если бы проблема ограничивалась только эстетической составляющей, но тут вылезают более серьёзные проблемы:

  • если устанавливать и крепить плату в нормальном положении, то пины программатора оказываются снизу платы и к ним невозможно подключиться без демонтажа контроллера;
  • если работать с платой без крепления то разъёмы с шагом 2,0 не обеспечивают должной жёсткости и вся конструкция грозит развалиться в любой момент и всё вокруг позамыкать.

В качестве нивелирования этого косяка разработчиков, можно порекомендовать припаивать линейку пинов с верхней стороны платы и сделать (или купить, если он продаётся) 6-пиновый 2,0 мм гибкий переходник.

Распиновка


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

image

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

Всего на ESP32 имеется 40 пинов (D0D39) из них 14 пинов

D6D11, D20, D24, D28-D31, D37, D38

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

Пины подключения Ethernet чипа LAN8720A


D18 ETH_MDIO_PIN
D19 ETH_TX_D0
D21 ETH_TX_EN
D22 ETH_TX_D1
D23 ETH_MDC_PIN
D25 ETH_RX_D0
D26 ETH_RX_D1
D27 ETH_RX_CRS

причём, D18 и D23 устанавливаются в скетче, а остальные 6 пинов чипа LAN8720A являются стандартными и задаются в библиотеке.

Поскольку производитель постеснялся предоставить принципиальную схему контроллера, то я здесь могу только привести аналогичную типовую схему подключения физики Ethernet на LAN8720A.

image

К LAN8720A также относится пин тактирования, который на плате T-Internet-POE подключён к D17 (тоже выбирается в скетче):

D17 ETH_CLOCK

и пин сброса

D5 NRST

microSD картридер


microSD картридер подключён на HSPI:

D2 SD_MISO
D12 SD_CS
D14 SD_SCLK
D15 SD_MOSI

и в случае своего использования забирает свободные для внешних подключений и выведенные на плату пины D2, D14, D15. Вопрос что выгоднее использовать картридер и потерять 3 из 12-и свободных пинов или сохранить 3 лишних GPIO и отказаться от картридера сродни вопросу что лучше: слон или конь? и вам каждый раз придётся отвечать на него при использовании платы T-Internet-POE.

Прочие пины


У нас остаются пины D0 (ETH_CLOCK, не задействован в этом качестве) и D1 (TX0) и D3 (RX0).

Свободные пины


Теперь переходим к самому интересному описанию свободных пинов, выведенных на плату контроллера.

Первой идёт группа D34, D35, D36, D39, работающая только на вход. Лучше конечно на вход, чем вообще ничего, но при таком дефиците GPIO было бы гораздо лучше, если бы эти четыре пина были полноценными GPIO.

И затем 8 полноценных GPIO, которые вы можете использовать в своих проектах. Тут нужно помнить, что хоть эти пины и являются полноценными GPIO, но некоторые из них работают весьма своеобразно (например меняют потенциал на старте контроллера и т.п.). Поэтому прежде, чем к ним что-то подключать, нужно специально выяснять и уточнять эти моменты.

D2 (SD_MISO)
D4
D12
D14 (SD_SCLK)
D15 (SD_MOSI)
D16
D32
D33

Как говорится, вот тебе, мой юный друг программирования и микроконтроллеров, 8 GPIO и ни в чём себе не отказывай.

POE


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

Здесь реализована полноценная поддержка стандарта POE 802.3af с развязкой и управлением питанием на чипе SI3404.

Меня дистанционная запитка контроллера не очень интересует, поэтому этот аспект работоспособности T-Internet-POE я не тестировал, но, судя по всему, с POE здесь проблем нет.

Программная поддержка


Как вы сами понимаете, работать с T-Internet-POE можно при помощи любых программных сред, имеющих представление об этом железе, в том числе в нативном SDK (и вероятно это наиболее правильный вариант), но мы попытаемся выяснить, что можно выжать из этой железки при помощи Arduino IDE.

В качестве программной среды для экспериментов использовались Arduino IDE версии 1.8.5 и ESP32-Arduino версии 1.0.5 (последняя сборка на момент написания статьи).

Сам процесс установки поддержки ESP32 в Arduino IDE я описывать не буду потому, что этому вопросу посвящено огромное количество материалов в интернете, во всех нюансах описывающих этот процесс.

Упомяну здесь только один момент: плюс ко всему, чего не имеет этот контроллер, он ещё не имеет и нативной поддержки в ESP32-Arduino версии 1.0.5. Поэтому в качестве контроллера в менеджере плат выбирался ESP32 DEV Module с настройками:

Flash Mode: DIO
Flash Size: 4MB (32 Mb)
Partition Scheme: 4MB (1,2MB/1,5MB)

Стандартный скетч


Ниже приведён скетч, которым нас порадовал производитель платы. Там особенно комментировать нечего, он просто инициализирует Ethernet интерфейс и посылает запросы к серверу в интернете.

Полный код скетча от производителя платы
/*    This sketch shows how to configure different external or internal clock sources for the Ethernet PHY*/#include <ETH.h>#include <SPI.h>#include <SD.h>#define SD_MISO         2#define SD_MOSI         15#define SD_SCLK         14#define SD_CS           13/*   * ETH_CLOCK_GPIO0_IN   - default: external clock from crystal oscillator   * ETH_CLOCK_GPIO0_OUT  - 50MHz clock from internal APLL output on GPIO0 - possibly an inverter is needed for LAN8720   * ETH_CLOCK_GPIO16_OUT - 50MHz clock from internal APLL output on GPIO16 - possibly an inverter is needed for LAN8720   * ETH_CLOCK_GPIO17_OUT - 50MHz clock from internal APLL inverted output on GPIO17 - tested with LAN8720*/// #define ETH_CLK_MODE    ETH_CLOCK_GPIO0_OUT          // Version with PSRAM#define ETH_CLK_MODE    ETH_CLOCK_GPIO17_OUT            // Version with not PSRAM// Pin# of the enable signal for the external crystal oscillator (-1 to disable for internal APLL source)#define ETH_POWER_PIN   -1// Type of the Ethernet PHY (LAN8720 or TLK110)#define ETH_TYPE        ETH_PHY_LAN8720// IC-address of Ethernet PHY (0 or 1 for LAN8720, 31 for TLK110)#define ETH_ADDR        0// Pin# of the IC clock signal for the Ethernet PHY#define ETH_MDC_PIN     23// Pin# of the IC IO signal for the Ethernet PHY#define ETH_MDIO_PIN    18#define NRST            5static bool eth_connected = false;void WiFiEvent(WiFiEvent_t event){    switch (event) {    case SYSTEM_EVENT_ETH_START:        Serial.println("ETH Started");        //set eth hostname here        ETH.setHostname("esp32-ethernet");        break;    case SYSTEM_EVENT_ETH_CONNECTED:        Serial.println("ETH Connected");        break;    case SYSTEM_EVENT_ETH_GOT_IP:        Serial.print("ETH MAC: ");        Serial.print(ETH.macAddress());        Serial.print(", IPv4: ");        Serial.print(ETH.localIP());        if (ETH.fullDuplex()) {            Serial.print(", FULL_DUPLEX");        }        Serial.print(", ");        Serial.print(ETH.linkSpeed());        Serial.println("Mbps");        eth_connected = true;        break;    case SYSTEM_EVENT_ETH_DISCONNECTED:        Serial.println("ETH Disconnected");        eth_connected = false;        break;    case SYSTEM_EVENT_ETH_STOP:        Serial.println("ETH Stopped");        eth_connected = false;        break;    default:        break;    }}void testClient(const char *host, uint16_t port){    Serial.print("\nconnecting to ");    Serial.println(host);    WiFiClient client;    if (!client.connect(host, port)) {        Serial.println("connection failed");        return;    }    client.printf("GET / HTTP/1.1\r\nHost: %s\r\n\r\n", host);    while (client.connected() && !client.available());    while (client.available()) {        Serial.write(client.read());    }    Serial.println("closing connection\n");    client.stop();}void setup(){    Serial.begin(115200);    WiFi.onEvent(WiFiEvent);    SPI.begin(SD_SCLK, SD_MISO, SD_MOSI, SD_CS);    if (!SD.begin(SD_CS)) {        Serial.println("SDCard MOUNT FAIL");    } else {        uint32_t cardSize = SD.cardSize() / (1024 * 1024);        String str = "SDCard Size: " + String(cardSize) + "MB";        Serial.println(str);    }    pinMode(NRST, OUTPUT);    digitalWrite(NRST, 0);    delay(200);    digitalWrite(NRST, 1);    delay(200);    digitalWrite(NRST, 0);    delay(200);    digitalWrite(NRST, 1);    ETH.begin(ETH_ADDR, ETH_POWER_PIN, ETH_MDC_PIN, ETH_MDIO_PIN, ETH_TYPE, ETH_CLK_MODE);}void loop(){    if (eth_connected) {        testClient("baidu.com", 80);    }    delay(10000);}


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

Походу получается, что ответ от LILYGO изучать программирование и создавать ПО самостоятельно (или искать готовые прошивки, хотя это и не спортивно).

Интерфейсы и пинг


Для сетевых профессионалов (и примкнувших к ним) скажу пару слов о скорости работы по интерфейсам Wi-Fi и Ethernet и их отзывчивости. Тестирование проводилось в ненагруженной гигабитной сети, зашумлённость Wi-Fi диапазона специально не контролировалась.

Первый скриншот это пинг контроллера по Wi-Fi интерфейсу. Минимум 24 мс, максимум 105 мс, среднее 67 мс.

image

Второй пинг контроллера по Ethernet интерфейсу. Минимум 0 мс, максимум 9 мс, среднее 2 мс.

image

Как вы видите, пинг по проводному Ethernet кардинально меньше, чем по Wi-Fi (что ожидаемо). Насколько хороши или плохи эти цифры предоставляю судить читателям самостоятельно, меня они вполне устраивают для моих целей.

Тестирование


Тестировать такую систему, как T-Internet-POE на скетчах, подобных предложенному производителем это несерьёзно, поэтому для тестирования контроллера применялась специализированная версия AMS, адаптированная специально для этой платы. Учитывая, что это сервер, который использует полноценные HTML, CSS, Javascript, Ajax, графические файлы и библиотеки, то успешная работа такого сервера на T-Internet-POE будет свидетельствовать о правильно спроектированном железе и возможности его использования в реальных проектах.

Примечание: тестирование производилось на внутренней, не публичной версии AMS для T-Internet-POE. Публикация и распространение этой версии не планируется, возможно это будет сделано позже, после соответствующих доработок.

Тест 1. Запускаем AMS сервер на T-Internet-POE


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

Косяк номер 1


В процессе этой работы стали вылезать косяки самого контроллера T-Internet-POE и первое, что было выявлено это то, что контроллер отказывается прошиваться при вставленной microSD карте памяти. Не помогает ничего ни замена USB порта, ни питание от отдельного блока, ни нажимание кнопок, ни замена карты контроллер упорно не желает прошиваться при вставленной карте памяти.

Глюк это конкретного экземпляра или родовой дефект всех контроллеров T-Internet-POE сказать трудно (имея в своём распоряжении один экземпляр), можно только констатировать 100-процентную повторяемость и воспроизводимость проблемы.

Что это значит для нас? В практическом плане это значит, что на контроллере T-Internet-POE фактически нет картридера картридер, который блокирует прошивку контроллера это не картридер, а баг.

Что же делать? Остаётся только использовать 1,5 МБ SPIFFS, имеющийся на модуле ESP32. Да, это не очень много, но в принципе 1,5 МБ памяти для IoT устройства это более-менее приемлемо в большинстве случаев.

Косяк номер 2


Ок, от картридера мы отказались, теперь нам нужно подружиться с SPIFFS. Вроде бы задача несложная и даже привычная, но и тут нас ждёт засада: по какой-то причине утилита ESP32FS отказывается нормально работать на этом контроллере (в этой конфигурации). Перенос файлов в память модуля ESP32 приводит к последующей ошибке монтирования SPIFFS диска.

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

Описание самого процесса адаптации кода под новый контроллер я опускаю, поскольку это потребовало бы составления антологии наподобие полного собрания сочинений В. И. Ленина и сразу перехожу к демонстрации факта успешной работы AMS сервера на T-Internet-POE (а значит и работоспособности самой платы T-Internet-POE).

Загрузка страницы по Wi-Fi интерфейсу.

image

Загрузка страницы по Ethernet интерфейсу.

image

Выигрыш по скорости примерно в 4 раза, естественно, в пользу Ethernet. Здесь нужно ещё иметь в виду, что речь идёт о неоптимизированном коде и после проведения соответствующих работ результаты должны значительно улучшиться.

image

Работа сервера по Ethernet интерфейсу на LILYGO TTGO T-Internet-POE ESP32 LAN8270A.

Тест 2. Работа на двух интерфейсах


Тут мне придётся немного поработать разрушителем легенд. В интернете ходят упорные слухи, что одновременная работа Wi-Fi и Ethernet на связке ESP32 и LAN8270A невозможна. Это не так AMS сервер прекрасно работает на двух интерфейсах одновременно и отлично обслуживает запросы по Wi-Fi и Ethernet. Никаких проблем с зависаниями или перезагрузками ESP32 нет.

image

Вот это уже интересный результат, который открывает заманчивые перспективы: поскольку мы имеем собственный сервер, то можем как угодно управлять обслуживанием интерфейсов, например, по Wi-Fi отдавать одни сайты с одним контентом, а по Ethernet другие сайты с другим контентом. Образно говоря, бабушке по Ethernet отдавать сайт с кулинарными рецептами, а внуку по Wi-Fi сайт с избранными статьями из БСЭ.

Тест 3. Бан по одному из интерфейсов


Теперь давайте попробуем на практике реализовать идею с различным обслуживанием интерфейсов веб-сервером. В качестве примера попробуем реализовать отказ в обслуживании для подключений по одному из интерфейсов (Ethernet).

image

Клиент, подключённый к нашему контроллеру по Ethernet интерфейсу получил отказ в обслуживании.

Резервирование интерфейсов


Сама идея резервирования интерфейсов лежит на поверхности и так и просится для реализации. Подобных сценариев существует множество, например, у вас есть IoT контроллер, который подключён к локальной сети по Ethernet. В случае аварийной ситуации, при пропадании проводного линка, контроллер автоматически подключается к резервному беспроводному роутеру и продолжает свою работу.

Сетевой роутинг


Имея в своём распоряжении два рабочих сетевых интерфейса можно как угодно маршрутизировать пакеты в сети. Никто также не мешает в схему маршрутизации по Wi-Fi и Ethernet добавить маршрутизацию данных по nRF24 или LoRa или по любой другой беспроводной сети. Таким образом можно сделать любой роутер для вашей IoT системы.

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

Итоги


Теперь давайте подведём итоги этого небольшого исследования: в общем, несмотря на некоторые косяки и детские болезни, контроллер LILYGO TTGO T-Internet-POE ESP32 LAN8270A мне понравился это отличный инструмент для построения IoT систем, особенно если вы обладаете соответствующей квалификацией и не лишены фантазии и креативного подхода к своему творчеству.

Плюсы и минусы LILYGO TTGO T-Internet-POE ESP32 LAN8270A.

Плюсы:
  • Это работает!
  • Законченное интегрированное решение Wi-Fi + Ethernet + POE + GPIO
  • Хорошая работа без зависаний и перезагрузок (проблем при тестировании выявлено не было)
  • Возможность одновременной работы по двум интерфейсам

Минусы:
  • Тотальное отсутствие документации, примеров и пояснений
  • Относительно высокий порог входа
  • Детские болезни и мелкие косяки в реализации
Подробнее..

BLE шлюз из Xiaomi Gateway DGNWG05LM без BLE

26.03.2021 20:17:43 | Автор: admin

(eu version lumi.gateway.mieu01)

В этом посте я расскажу как можно собирать данные BLE и передавать через MQTT в системы умного дома, например в HomeAssistant.

Как все начиналось?

Эта история началась в прошлом году: у меня появился несколько таких шлюзов. В то время было несколько статей по получению root доступа, интеграции miio в HA и по прошивке чистого openwrt на шлюз. Толчком к развитию стал сезон распродаж в разных магазинах, где стоимость шлюза стремилась к нулю, и многие энтузиасты получили интересную железку.

Первым большим делом для меня было заставить работать zigbee2mqtt с чипом и прошивкой находящимся в шлюзе. И пока я допиливал интеграцию в zigbee-herdsman, ребята в чатике @xiaomi_gw_hack занимались добавлением поддержки в openwrt периферии, которая была в шлюзе (светодиоды RGB, динамик, датчик света, wi-fi модуль).

Отдельное спасибо @lenz1986, @Alx2000y, @belokobylskiy!

Было обнаружено, что в wifi модуле rtl8723bs европейской версии шлюза есть встроенный bluetooth с поддержкой BLE.

Но в стоковой системе на шлюзе нет никаких следов bluetooth. И лишних uart, по которому можно было бы с ним работать тоже. @lenz1986 провел раскопки

Несколько плат очень помогли разобраться в внутреннем мире шлюзаНесколько плат очень помогли разобраться в внутреннем мире шлюзаВот как плата выглядит без процессора )Вот как плата выглядит без процессора )

Он вызвонил контакты, и обнаружил что на плате разведены все 4 UART от процессора. Один из которых вел на uart от bluetooth части модуля wifi rtl8723bs. Потом он добавил поддержку этого uart в DTB, где описываются вся периферия устройства для openwrt и нашел подходящие драйвера. За что @lenz1986 огромное спасибо!

модуля

Внимание! Все действия я описываю и делаю на базе openwrt прошивки для шлюза. Установить ее можно по воздуху просто подключившись по uart к шлюзу. (спасибо @divanikus)

Подробнее описано на https://openlumi.github.io/

Bluetooth инициализируется через rtk_hciattach при запуске шлюза. После загрузки мы получаем такую картину hciconfig

Я знаю 2 пути, как можно включить bluetooth адаптер.

  • Руками hciconfig hci0 up

  • изменив параметр AutoEnableконфиге /etc/bluetooth/main.confна true

Я выбираю второй. Интерфейс запущен. Для проверки можно запустить скан hcitool lescan

Работа с BLE

Мои знания по BLE были на нуле, и чтобы было проще разобраться я искал что-то готовое по типу zigbee2mqtt. Перепробовал несколько решений на Node.Js, в том числе пакеты для node-red. Остановился на проекте EspruinoHub. (хоть и код там не супер современен и технологичен, но зато работает)

После запуска с отсылкой данных в локальный mqtt сервер, в CLI и web интерфейсе уже показались распарсенные данные с части датчиков LYWSDCGQ (круглые гигротермографы) .

Раньше я их слушал на esp32 через esphome. Небольшое сравнение получаемых данных с одного термометра.Раньше я их слушал на esp32 через esphome. Небольшое сравнение получаемых данных с одного термометра.

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

пример cli интерфейса с статусом доступных устройствпример cli интерфейса с статусом доступных устройств

Многие устройства Xiaomi с bluetooth шлет BLE Advertising Packet, в большинстве случаев в нем содержится полезная нагрузка в виде измерений, которые производит устройство. Часто данные отправляются открыто, но используется шифрование с ключом.

Например для браслета MiBand данные выглядят вот так. Если есть данные о пульсе то они добавляются в конец

В устройствах xiaomi, часто используется BLE сервис fe95. В интернете есть небольшая документация по нему .На github есть множество проектов которые умеют парсить эти данные. На основе этих данных и существующей реализации espruino я немного улучшил парсинг открытых данных, но потом я нашел более красивое решение из hannseman/homebridge-mi-hygrothermograph. Мне особенно понравилась стандартизация разных событий и расшифровка исходя из данных заголовка.

Этот парсер закрыл вопрос с большинством устройств Xiaomi, отправляющих данные в fe95. Можно еще попробовать добавить некоторые типы событий (движение, дым, нажатие на кнопку), но у меня нет таких устройств под рукой.

Я добавил в EspruinoHub данный парсер, и реализовал возможность указать настройки для разных устройств. Это необходимо для устройств, которые шифруют с помощью bindKey свои пакеты. Получить bindKey можно из miHome.

MQTT Discovery - Home Assistant

Данных стало больше, но хотелось чтобы они автоматически появлялись в HomeAssistant. EspruinoHub отправляет данные которые и слышит в эфире, и не имеет на данный момент привязки к конкретным устройствам. Поэтому в момент появления данных, если они из списка поддерживаемых отправляется config устройства в топик homeassistant в mqtt и устройства появляются в системе умного дома

Добавленные и протестированные устройства.

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

LYWSDCGQ - работал "из коробки". Добавил только mqtt discovery в HA

показания перепоказания пере

LYWSD02 - температура, влажность и батарейка


Самый бюджетный датчик температуры и влажности с экраном LYWSD03MMC - температура, влажность и батарейка (нужен bindKey). Существует 2 альтернативные прошивки, они очень крутые и продвинутые. Особенно от Виктора pvvx. Рекомендую использовать именно ее. Помимо лучшего потребления она шлет данные в одном пакете, а не в трёх и имеет множество настроек.


MI SCALE - 181d v1 По крупицам из разных источников допилена реализация в которой показываются данные о - стабилизации веса (весы моргают) - убрали вес (встали с весов) - дата и время измерения. 181b v2 Работает, но не тестировал лично. Возможно нужно что-то допилить


Mi band 3 fee0 Шаги и Пульс в режиме тренировки. Чтобы браслет отправлял данные необходимо включить обнаружение в MiFit.

Как оказалось шлюз очень хорошо и далеко слышит, а эта функция включена у многих людей. Работает это и для других моделей и даже на некоторых часах например Amazfit GTS


HHCCJCY01 MiFlora, Huahuacaocao - temperature, moisture, illuminance, conductivity, battery_level

Другие устройства тоже можно попробовать подключить. Если они шлют в кодированном виде, то в mqtt об этом будет ошибка с просьбой указать bindKey в конфиг.

YEERC - я обнаружил что прошивка для esp32 tasmota сообщает, что поддерживает данный пульт. Он идет в комплекте с многими люстрами YEELIGHT, но к сожалению у меня не получилось нигде найти как получить 32 символьный bindKey для него. Сообщения нажатий я вижу, но не могу расшифровать. (Значение event закодировано и зависит от counter который увеличивается с каждым нажатием) Возможно кто-то из читателей подскажет как добыть данный ключик. Пульт можно привязать к нескольким люстрам в разное время и они будут вместе расшифровывать и отрабатывать нажатия. Скорей всего ключ там не изменяется со временем или привязкой.

Как установить EspruinoHub на шлюз Xiaomi с OpenWrt ?

Можно установить и на другие устройства с помощью git / npm, инструкция на странице проекта EspruinoHub

Установка

Мои последние наработки собраны в пакет и ставятся с помощью opkg

Необходимо подключить фид по инструкции https://openlumi.github.io/openwrt-packages/

Дальше установить собранный пакет.

opkg updateopkg install node-espruinohub

Конфигурирование

По-умолчанию он будет пытаться подключиться к локальному mqtt без авторизации. Если вы хотите подключить к внешнему брокеру mqtt, то нужно изменить конфиг в /etc/espurinohub/config.json

Внимание! у некоторых настроек в начале стоят слеши чтобы они не применялись. (конфиг в этом проекте частично сделан как пример и я не стал ничего менять)

Пример конфига можно посмотреть тут. Если вы знаете мак адреса своих устройств то рекомендую их прописать и установить"only_known_devices": true, чтобы не отправлялись данные с чужих устройств из эфира.

Для работы с HomeAssistant достаточно отправлять данные в json формате, а остальное можно выключить. По умолчанию будет отправлять в топики с группировкой по типу данных.

"mqtt_format_json": true,"homeassistant": true,"mqtt_cache_state": true

Планы

Отслеживание носимых устройств по rssi между комнатами. Для этого в конфиг я добавил возможность указать минимальный rssi в разрезе устройства и таймаут присутствия.

данные с устройств летят достаточно часто если они в зоне прямой видимости.данные с устройств летят достаточно часто если они в зоне прямой видимости.

Активные подключения: хочу попробовать управлять некоторыми устройствами по BLE, но для одновременного подключения и сканирования Bluetooth модуль и ПО могут работать нестабильно. Поэтому я пока только изучаю этот вопрос.

Альтернативные opensource проекты работающие с BLE на шлюзе

  • devbis/ble2mqtt - своя реализация на python через bleak, умеет подключаться к чайникам, но сильно грузит процессор.

  • Beetle-II/lumi - тот же парсер из hannseman/homebridge-mi-hygrothermograph, но без возможности задать индивидуальный ключ bindKey для устройства. Нет raw данных и управление через mqtt. + Умеет работать не только с BLE.

Заключение

Спасибо, что дочитали до конца!

Если у Вас есть вопросы, то можете задавать их в комментариях.

Подробнее..

MQTT-SN ESP8266

06.04.2021 00:08:46 | Автор: admin

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

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

В интернете довольно мало информации о данном протоколе, ковыряние в которой и стало основой для написание данной заметки.

Основные отличия MQTT-SN от старшего брата это уменьшение размера сообщения , в основном, за счет сокращения служебной информации, особенно интересна реализация QOS -1 - когда клиент отправляет сообщение без подтверждения о подтверждении доставки, и возможность использование отличного от TCP протокола, можно встретить реализации для UDP, UDP6, ZigBee, LoRaWAN, Bluetooth.

Не буду сильно погружаться в описание - кому интересно, можете ознакомиться со спецификацией MQTT-SN в OASIS. Приведу лишь пару схем из стандарта:

Рис.1 Архитектура MQTT-SN.Рис.1 Архитектура MQTT-SN.

Первое что бросается в глаза - наличие MQTT брокера на схеме, помимо клиентов, шлюзов и форвардер MQTT-SN (не придумал как перевести, написал по аналогии с DNS). А это значит, что для функционирования протокола сети сенсоров полноценный MQTT брокер обязателен и необходим.

Если рассмотреть функции каждого участника обмена то получается следующее:

  • MQTT-SN клиенты (как принимающие так и передающие сообщения) - подключаются к MQTT брокеру, через MQTT-SN шлюзы.

  • MQTT-SN шлюз - основная функция двусторонняя "синтаксическая" трансляция MQTT-SN MQTT.

  • MQTT-SN форвардер - если клиентам недоступен шлюз, они могут посылать и принимать сообщения через него.

  • MQTT брокер - сервер, своеобразное ядро системы, который тем и занимается что пересылает сообщения.

Рис.2 Прозрачные и агрегирующие шлюзы.Рис.2 Прозрачные и агрегирующие шлюзы.

Здесь на картинке тоже можно видеть полноценный взрослый MQTT-брокер и два режима работы MQTT-SN шлюзов:

  • В прозрачном режиме для каждого клиента шлюз устанавливает и поддерживает отдельное соединение с MQTT брокером. Это соединение зарезервировано исключительно для сквозного и прозрачного обмена сообщениями между клиентом и брокером. Шлюз выполняет трансляцию между протоколами. Ну и поскольку весь обмен сообщениями осуществляется сквозным образом, все функции и возможности, которые реализуются, могут быть использованы клиентами.

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

Ну что же - перейдем к реализации, в качестве операционной системы я использовал Ubuntu 20.04 со статическим адресом 10.10.10.10/24.

MQTT

Устанавливаем Eclipse Mosquitto:

sudo apt install mosquitto

Для тестирования нам не понадобятся какие-то настройки в отношении безопасности и т.п. Но я крайне не рекомендую так делать в производстве. Хотя если вы решили использовать MQTT/MQTT-SN на промышленном уровне все необходимые инструменты имеются. После установки давайте проверим как пересылаются сообщения - я использую Python для этого. Установим библиотеку paho-mqtt.

pip install paho-mqtt
Скрипт, передающий в топик habr сообщение Hello Habrahabr!:
import paho.mqtt.publish as publishmsg = "Hello Habrahabr!" publish.single("habr", msg, hostname="10.10.10.10", port=1883)
Скрипт, подписывается на топик habr и принимает все сообщения:
import paho.mqtt.client as mqttdef on_connect(client, userdata, flags, rc):    client.subscribe("habr/#")def on_message(client, userdata, msg):    print(msg.topic + ' ' + str(msg.payload))client = mqtt.Client()client.on_connect = on_connectclient.on_message = on_messageclient.connect("10.10.10.10", 1883, 60)client.loop_forever()

Чтобы более подробнее познакомится с MQTT очень рекомендую блог Steves Internet Guide, ну и поиск не только по хабру, конечно.

MQTT-SN

Убедившись что наш брокер работает, переходим к следующему этапу. Я буду использовать шлюз из репозитория paho.mqtt-sn.embedded-c, повторим действия для компиляции шлюза в нашей ОС.

Для начала установим необходимые пакеты для сборки:

sudo apt-get install build-essential libssl-dev

Клонируем репозиторий себе в систему, переходим в папку со шлюзом и компилируем:

git clone -b develop https://github.com/eclipse/paho.mqtt-sn.embedded-ccd paho.mqtt-sn.embedded-c/MQTTSNGatewaymake installmake clean

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

Наша простая конфигурация (для большего упрощения я убрал закомментировать строки):
BrokerName=localhostBrokerPortNo=1883BrokerSecurePortNo=8883ClientAuthentication=NOAggregatingGateway=NOQoS-1=NOForwarder=NOPredefinedTopic=NOGatewayID=1GatewayName=Paho-MQTT-SN-GatewayKeepAlive=900# UDPGatewayPortNo=10000MulticastIP=225.1.1.1MulticastPortNo=1885MulticastTTL=1

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

gateway.conf
sudo ./MQTT-SNGateway *************************************************************************** * MQTT-SN Gateway * Part of Project Paho in Eclipse * (http://personeltest.ru/away/git.eclipse.org/c/paho/org.eclipse.paho.mqtt-sn.embedded-c.git/) * * Author : Tomoaki YAMAGUCHI * Version: 1.4.0 ***************************************************************************20210404 224219.274 Paho-MQTT-SN-Gateway has been started. ConfigFile: ./gateway.conf SensorN/W:  UDP Multicast 225.1.1.1:1885 Gateway Port 10000 TTL: 1 Broker:     localhost : 1883, 8883 RootCApath: (null) RootCAfile: (null) CertKey:    (null) PrivateKey: (null)

Давайте теперь что-нибудь уже отправим нашему шлюзу, который это сообщение передаст MQTT-брокеру, для отправки будем использовать все тот же Python и MQTT-SN client for Python 3 and Micropython. В репозитории есть примеры для отправки и приема сообщений, немного подправив их, мы сможем уже отправлять и принимать сообщения как из MQTT сегмента куда-либо, так и из MQTT-SN сегмента.

mqttsn_publisher.py
from mqttsn.MQTTSNclient import Clientimport structimport timeimport sysclass Callback:    def published(self, MsgId):        print("Published")def connect_gateway():    try:        while True:            try:                aclient.connect()                print('Connected to gateway...')                break            except:                print('Failed to connect to gateway, reconnecting...')                time.sleep(1)    except KeyboardInterrupt:        print('Exiting...')        sys.exit()def register_topic():    global topic    topic = aclient.register("habr")    print("topic registered.")aclient = Client("mqtt_sn_client", "10.10.10.10", port=10000)aclient.registerCallback(Callback())connect_gateway()topic = Noneregister_topic()payload = Hello Habrahabr!pub_msgid = aclient.publish(topic, payload, qos=0)aclient.disconnect()print("Disconnected from gateway.")

Не буду здесь приводить много простого кода - если до этих пор все у вас получалось - думаю разберетесь и дальше ;)

ESP8266

Теперь пришло время настоящего веселья. Будем применять протокол, по моему мнению, на наиболее подходящих для него микроконтроллерах esp8266.

На самом деле готовых реализаций несколько и ни одна из них у меня корректно не завелась без доработки напильником. Наиболее логичной реализацией мне показалась у MQTT-SN клиента у некоего Gabriel Nikol в репозитории arduino-mqtt-sn-client на GitHub.

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

Проблема 2.Но при подписывании на топики - мы наблюдаем, что у нас к каждому сообщению добавляется 0x00, который считается признаком конца строки, но почему-то у нас во всех других способах отправки сообщений ничего подобного нет. Пробежавшись по спецификации протокола, я и правда не нашел, что у нас сообщение обязательно должно заканчиваться так - вырезаем это в отправке сообщений. Еще стали на шаг ближе! Что мы стараемся отправить, то и получаем.

Проблема 3.Для обычной реализации MQTT протокола, я использовал для передачи кватерниона массив байт - так меньше сообщение, 16 (4 числа типа float) вместо 32 (если считать один знак до и 6 после запятой). Оказалось, что в данной реализации используется символьный тип данных char, где каждый байт интерпретируется как ASCII-символ. Давайте добавим и такую возможность - отправлять массив байтов.

Проблема 4.Заметил довольно длинный временной промежуток между подключением к беспроводной сети микроконтроллера и первым соединением со шлюзом. Давайте посмотрим в чем дело. Оказывается - при подключении, наш микроконтроллер спит при первом подключении 10 секунд, на втором 20. Исправим на 50 мс для первой и соответственно 100 для второй попытки - на данном этапе я думаю этого хватит - я проблем не заметил, но на всякий случай увеличил количество попыток до 5 (разумеется для использования в реальном мире нужно пересматривать этот таймаут).

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

main.cpp
#include <I2Cdev.h>#include <MPU9250_9Axis_MotionApps41.h>#include <ESP8266WiFi.h>#include <WiFiUdp.h>#include <WiFiUdpSocket.h>#include <MqttSnClient.h>#include <ArduinoOTA.h>const char* ssid     = "habr";const char* password = "Hello Habrahabr!";MPU9250 mpu;#define SDA 4#define SCL 5IPAddress ip(10, 10, 10, 30);IPAddress gateway(10, 10, 10, 1);IPAddress subnet(255, 255, 255, 0);IPAddress gatewayIPAddress(10, 10, 10, 100);uint16_t localUdpPort = 10000;WiFiUDP udp;WiFiUdpSocket wiFiUdpSocket(udp, localUdpPort);MqttSnClient<WiFiUdpSocket> mqttSnClient(wiFiUdpSocket);const char* clientId = "thigh_l";char* subscribeTopicName = "main";char* publishTopicName = "adam/thigh_l";String messageMQTT;uint16_t packetSize;uint16_t fifoCount;uint8_t fifoBuffer[48];bool blinkState = false;bool sendQuat = false;Quaternion q;int8_t qos = 0;void mqttsn_callback(char *topic, uint8_t *payload, uint16_t length, bool retain) {  for (uint16_t i = 0; i < length; i++) {    messageMQTT += (char)payload[i];  }  if (messageMQTT == "start1"){    sendQuat = true;    messageMQTT = "";  }  else if (messageMQTT == "stop") {    sendQuat = false;    messageMQTT = "";  }}void setup_wifi() {  delay(10);  WiFi.setSleepMode(WIFI_NONE_SLEEP);  WiFi.mode(WIFI_STA);  WiFi.config(ip, gateway, subnet);  WiFi.begin(ssid, password);  while (WiFi.status() != WL_CONNECTED) {    delay(50);  }}void convertIPAddressAndPortToDeviceAddress(IPAddress& source, uint16_t port, device_address& target) {  target.bytes[0] = source[0];  target.bytes[1] = source[1];  target.bytes[2] = source[2];  target.bytes[3] = source[3];  target.bytes[4] = port >> 8;  target.bytes[5] = (uint8_t) port ;}void setup() {  Wire.begin(SDA, SCL);  Wire.setClock(400000);  Serial.begin(115200);  setup_wifi();  mpu.initialize();  mpu.dmpInitialize();  mpu.setDMPEnabled(true);  packetSize = mpu.dmpGetFIFOPacketSize();  fifoCount = mpu.getFIFOCount();  ArduinoOTA.onStart([]() {  });  ArduinoOTA.onEnd([]() {  });  ArduinoOTA.onProgress([](unsigned int progress, unsigned int total) {  });  ArduinoOTA.onError([](ota_error_t error) {    if (error == OTA_AUTH_ERROR) Serial.println("Auth Failed");    else if (error == OTA_BEGIN_ERROR) Serial.println("Begin Failed");    else if (error == OTA_CONNECT_ERROR) Serial.println("Connect Failed");    else if (error == OTA_RECEIVE_ERROR) Serial.println("Receive Failed");    else if (error == OTA_END_ERROR) Serial.println("End Failed");  });  ArduinoOTA.begin();  pinMode(LED_BUILTIN, OUTPUT);  mqttSnClient.begin();  device_address gateway_device_address;  convertIPAddressAndPortToDeviceAddress(gatewayIPAddress, localUdpPort, gateway_device_address);  mqttSnClient.connect(&gateway_device_address, clientId, 180);  mqttSnClient.setCallback(mqttsn_callback);  mqttSnClient.subscribe(subscribeTopicName, qos);}void loop() {  fifoCount = mpu.getFIFOCount();    if (fifoCount == 1024) {      mpu.resetFIFO();      }    else if (fifoCount % packetSize != 0) {      mpu.resetFIFO();      }    else if (fifoCount >= packetSize  && sendQuat) {        mpu.getFIFOBytes(fifoBuffer, packetSize);        fifoCount -= packetSize;        mpu.dmpGetQuaternion(&q, fifoBuffer);        mqttSnClient.publish((uint8_t*)&q, publishTopicName, qos);        blinkState = !blinkState;        digitalWrite(LED_BUILTIN, blinkState);        mpu.resetFIFO();      }  ArduinoOTA.handle();  mqttSnClient.loop();}

Тестирование

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

У меня есть 15 датчиков с микроконтроллерами, и в своем тестовом проекте по захвату движений я использовал MQTT, в качестве старта передачи данных использовались сообщения в топик main и у меня была проверка на изменение кватерниона (т.е. новое сообщение отправлялось, когда предыдущий кватернион отличался от настоящего примерно на 0,5). Не сложно будет изменить прошивки, чтобы для каждого микроконтроллера была своя команда старта передачи + передавать данные с частотой 50 Гц без проверки на отличия предыдущего и настоящего кватернионов.

Для этого напишем пару скриптов. Я себе представляю алгоритм тестирования следующим образом: Передаем сообщение для старта передачи с датчика, считываем среднее значение полученных сообщений в секунду, каждую секунду пишем в файл полученное количество сообщений, до запуска передачи от следующего датчика смотрим в диспетчере задач сколько потребляет трафика процесс MQTTSN-Gateway. Просто, быстро и не очень трудоемко - нужно делать, но лень. Для полномасштабного теста подожду уже готовые платки.

Рис3. Первенец с недочетамиРис3. Первенец с недочетами

Для начала решил проверить, а все ли сообщения доходят, мы то используем в качестве транспорта UDP, который не гарантирует обеспечение надежности, упорядочивания или целостности данных. На протяжении 5 минут делал следующее - скриптом захватывал все сообщения и записывал время приема в файл, параллельно другим скриптом захватывал сообщения из последовательного порта и так же записывал время приема в другой файл. Получилось больше 13200 строк и соответствие в 100%, то есть сколько контроллер отправил сообщений, столько и было получено. Диспетчер задач показывал среднюю нагрузку сетевого интерфейса на получение 24-48 Кбит/с и 170-200 Кбит/с на отдачу. При таком же тестировании но с протоколом MQTT нагрузка на сетевой интерфейс составила 48-64 и 200-300 соответственно. Можете мне не верить и проверить все сами:) Как говорится налицо преимущества, но это для одного только датчика.

Кому интересно - ссылка на этот весь говнокод репозиторий. Продолжение следует...

Подробнее..

Сетевой интерфейс для программируемого реле с поддержкой Telegram Bot и HomeKit

07.05.2021 14:19:42 | Автор: admin

Как я реализовал удаленное управление и мониторинг, для программируемого реле ПР200, используя разные сервисы (Telegram Bot, HomeKit) и протоколы (Modbus RTU, Modbus TCP, mqtt) и ESP32.

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

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

Первая версия платы на основе ESP32

Во второй версии добавлен usb порт, что позволяет загрузить прошивку без использования дополнительных проводов и преобразователей. Базовая реализация изначально задумывалась с возможностью обновления прошивки по воздуху через ОТА, а для экспериментов проще использовать microUSB.

В обновленном варианте добавил ещё и кнопки сброса и загрузки при прошивке, а так же добавил поддержку модулей ESP32-WROVER с PSRAM, это позволит использовать больше памяти и расширит возможности.

В общем, структура взаимодействия сетевой платы с программируемым реле основана на протоколе modbus rtu, а с внешним миром варианты могут быть самые разнообразные от bluetooth до TelegramBot.

TelegramBot

Именно с поддержки бота я и начал опыты, на раннем этапе получилось вот такая реализация:

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

Для универсальности взаимодействие бота с алгоритмом в приборе, использован режим чтения/записи сетевых регистров Modbus а разных форматах представления:

/R- целое 16 битное значение

/I-целое число занимающее 2 регистра

/F- число в формате float тоже 2 регистра.

После символа адрес в диапазоне 512-576, эти регистры можно читать и записывать, формат для записи /Xzzz=nnnn, для чтения достаточно отправить номер регистра в требуемом формате.

Для представления состояний регистра в битовых полях, можно отправить адрес в формате /Bzzz, ответ будет в виде 16 значения в булевом формате.

Apple HomeKit

Следующим этапом был сервис Apple HomeKit и приложение дом, как раз для управления освещением и другими точечными нагрузками он подходит лучше всего, я начал с 16 каналов, по количеству бит в регистре модбас.

После выхода обзора по такому применению,

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

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

Для быстрого добавления платы в приложение Дом, на web страницу добавлен QR код, второй вариант ввести код настройки, индивидуальный для каждой платы. Постарался упростить и минимизировать все настройки для быстрого старта.

Так же протестировал mqtt, идея задания топиков взята из версии платы для esp8266. Проверил поддержку датчиков 1-wire ds18b20, для их подключения к плате предусмотрены посадочные места под разъем, и сигнальные линии с резисторами, такой-же использовался в плате prsd на esp8266.

4 пина, два из которых +3.3v и gnd, позволяют задействовать 2 порта в качестве интерфейса 1-wire или i2c. I2C позволяет подключать всякую экзотику, которую практически невозможно состыковать в базовой поставке прибора. Например, датчик влажности/давления с I2C или RFID ридер.

Для быстрого просмотра значений регистров используется протокол Modbus TCP, запустив Modbus Poll на ПК или Virtuino/Kascada и другие приложения на Android, можно быстро организовать доступ и управление устройством с помощью телефона или планшета.

Остальные настройки WEB интерфейса представлены ниже:

WEB настройки

Для смены прошивки платы, когда она уже установлена в устройство, предусмотрен режим обновления по воздуху (OTA), для этого достаточно выбрать bin файл, после загрузки прошивки устройство перезагрузится и запустится обновленная версия. Так же можно перезагрузить плату в ручном режиме через web кнопку.

При первом старте, когда устройство не имеет настроек точки доступа и пароля и не может подключиться к сети wi-fi, плата включает режим точки доступа для подключения и ввода ssid и pass, после сохранения значений и перезагрузки если подключение к сети успешно, точка доступа выключается. Если токен Telegram bot введен, то после подключения и выхода в интернет, узнать IP адрес платы можно введя команду. Через бот можно получить и другую информацию.

Основные моменты по работе представлены в видео.

На данный момент прошивка находится в режиме доработки, демонстрационные версии будут доступны позже.

Для экономии ресурсов ESP32 в перспективе думаю разделить на версии с поддержкой того или иного функционала, памяти в esp32 хоть и больше в сравнении с esp8266, но одновременная работа всех сервисов может снизить ресурсы до критического уровня.

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

В меню бота есть возможность смотреть время бесперебойной работы в секундах, текущий и минимальный объем доступной Heap памяти, используя один и тот же токен для TelegramBot, можно читать параметры сразу с нескольких устройств, аналогично и на запись параметров. Т.е. любая команда, отправленная с телефона боту, отправляется всем устройствам с токеном, это происходит не всегда, иногда отвечает только часть устройств, и приходится делать запросы повторно. Сейчас все они не имеют привязки к имени, думаю сделать уникальные имена для отличия при запросах/ответах.

Используя несложный сетевой интерфейс с чипом ESP32, можно значительно расширить функционал программируемого реле ПР200 и в перспективе ПР103, куда можно установить сетевой интерфейс, другие модели ПР100/ПР102 потребуют внешний драйвер RS-485 для подключения снаружи, так как сетевые интерфейсы в них не съемные.

Наличие программатора на борту платы, позволяет создать собственные алгоритмы с быстрой загрузкой в устройство, необходимо лишь обеспечить обмен по протоколу Modbus на стандартных выводах UART esp32.

Подробнее..

Azure Custom Vision без Azure, или где у них маска. Как мы распознавали маску на лице (и других частях тела)

26.01.2021 14:17:08 | Автор: admin

Среди набора примеров для Azure на GitHub был найден один очень интересный: распознавание образов на Raspberry Pi, в офлайне. Авторами предлагается подготовить модель машинного обучения в одном из облачных сервисов Azure, затем перенести ее на компьютер, у которого большую часть времени нет подключения к Интернет, после чего распознавание образов будет работать автономно. Разработчики подготовили проект для двух платформ: ARM32 (собственно Raspberry Pi) и AMD64 (но без поддержки веб-камеры).


На волне коронавирусного хайпа мы решили адаптировать пример для распознавания, надета маска на человеке или нет. Сразу выяснилось, что шаги по адаптации примера не вполне очевидны. В этом материале рассмотрим последовательно, как этот пример, во-первых, модифицировать для работы со своей моделью машинного обучения, во-вторых, перенести его на платформу AMD64. Будем считать, что наш компьютер, на котором работает модель, управляет турникетом: если человек пришел в маске, турникет открывается, если нет остается закрытым.


Все сложно...


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


В Azure Computer Vision, например, даже не нужно обучать модель перед ее использованием: есть набор облачных API, уже готовый к применению. Для более сложных задач есть Azure Custom Vision, где мы сначала обучаем модель, потом ей пользуемся. Причем знание специфической математики практически не требуется, все делается прямо в браузере мышкой. Знание пары терминов из машинного обучения все-таки понадобится, чтобы понять, насколько качественно работает модель.


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


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

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


  • Для всего придется разрабатывать свой код и настраивать все вручную;
  • Непонятно, как впоследствии масштабировать решение. Что, если таких "турникетов" нужно 100 штук?

Что делать?


Итак, есть вариант "только облако", есть "совсем без облака". Оба варианта крайности. Было бы удобно взять лучшее от облачных сервисов, но "спустить их на землю". Например, однократно обучить модель на Azure Custom Vision, не углубляясь в вопросы математики, а затем использовать эту модель автономно, без подключения к Интернет.


Такое решение уже существует: Azure IoT Edge позволяет использовать предварительно экспортированную модель машинного обучения без постоянного подключения к Интернет. При этом мы получаем все преимущества и со стороны облака, и со стороны полностью наземного решения:


  • Будем передавать в облако только необходимую телеметрию;
  • Для обучения модели практически неограниченные объемы хранилища и вычислительной мощности;
  • Быстрый цикл управления, т.к. все решения принимаются локально, а не в облаке;

Azure IoT Edge и с чем его едят


Подробно мы описывали IoT Edge в этой статье. Вкратце, IoT Edge включает среду выполнения демон Linux, "внутри" которого выполняются модули, которые, в свою очередь, являются Docker-совместимыми контейнерами. Поддержка устройств IoT Edge включена в Azure IoT Hub. Среда выполнения IoT Edge единожды устанавливается на устройство, а затем набор модулей конфигурируется через облако, с портала Azure, после чего компьютер с IoT Edge может работать автономно, без подключения.


"Родной" платформой для IoT Edge по архитектурным причинам является Linux, хотя с 2019 года IoT Edge доступен и для Windows 10 Enterprise LTSC ОС для устройств специального назначения.


Модули IoT Edge могут содержать произвольный код, или в модули можно "обернуть" следующие службы Azure:



В нашем случае интерес представляет как раз Custom Vision. В этом сервисе мы подготовим модель распознавания маски и "обернем" ее в модуль.


В IoT Edge заложен механизм обмена сообщениями с между модулями и между модулями и облаком. Сами сообщения передаются в подобии текстового формата, поэтому такой механизм плохо подходит для обмена сырыми двоичными данными (картинками), поэтому в исходном примере от Microsoft для обмена картинками с камеры между модулями используется HTTP, т.е. один из обменивающихся данными модулей является web-сервером, а другой клиентом.


Пример распознавания изображений от Microsoft


Рассмотрим структуру исходного примера распознавания изображений. Рекомендую посмотреть видео, где ведущие наглядно объясняют, что и как устроено.



На схеме обработка начинается с видеопотока с обычной веб-камеры, подключенной через USB к устройству, на котором предварительно установлена среда выполнения IoT Edge.


Откуда на этом устройстве возьмется среда IoT Edge? Ее необходимо установить вручную, и после того, как она установит подключение к IoT Hub, ей можно (и нужно) управлять уже с IoT Hub. Под "управлением" я также подразумеваю установку модулей.


Модули устанавливаются по команде с IoT Hub. Причем на IoT Edge "спускается" не сам модуль, а как бы ссылка на его скачивание. Механизм устроен так, что предварительно модули нужно выложить в Container Registry (это специальный репозиторий для хранения модулей).


Модули после установки взаимодействуют, как показано на следующей схеме, взятой из того же примера:



  • Camera: модуль захвата видео с камеры. Видео "нарезается" на картинки (не кадры! Из десятка кадров в обработку может уйти только один) и по HTTP передается в следующий модуль;
  • AI: модуль, содержащий обученную модель машинного обучения. Модель работает с отдельными изображениями, а не с видеопотоком, именно поэтому видео "нарезается" на картинки. Модель машинного обучения предварительно должна быть подготовлена в сервисе Custom Vision;
  • Display: модуль, отображающий результаты распознавания. Конкретно в рассматриваемом примере предлагается отличить банан от яблока, соответственно, на экране будет либо картинка яблока, либо банана (либо ничего).

Помимо всего прочего, телеметрия отсылается непосредственно в IoT Hub.


Если мы хотим использовать какую-то свою модель с данным примером, в описании к нему нам предлагается просто заменить модель на свою. Мы в Кварта Технологии проверили этот сценарий, но из-за ограниченности ресурсов Raspberry Pi работало такое решение ну очень медленно, так что на практике пользоваться им было очень неудобно.


Соответственно, для этого примера напрашивается более мощная платформа. AMD64 уже поддерживается, вот только в такой конфигурации реальная веб-камера почему-то не предусмотрена и предлагается пользоваться ее эмуляцией за счет зацикленного куска видео, на котором есть и яблоко, и банан. Это нас точно не устроит, поэтому во что бы то ни стало будем подключать "живую" веб-камеру, пользуясь кодом от ARM32.


Есть еще одна проблема. У компьютера на базе AMD64 нет "экранчика" SenseHat, как в Raspberry Pi, поэтому так элегантно, как на SenseHat, результат распознавания уже не отобразить, и придется придумывать что-то свое.


Обучение модели (Custom Vision)


Заходим на Custom Vision (понадобится подписка Azure) и нажимаем New Project.


  • Name вводим произвольное имя;
  • Description произвольное описание;
  • Resource нажимаем Create new и создаем новый ресурс типа Cognitive Services;
  • Classification Types выбираем Multilabel, так как мы будем определять не только наличие/отсутствие маски, но и где именно она надета на лице или на теле (гуглим "бикини из масок")
  • Domains General (compact).

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


  • Люди в маске на лице, размечаем тегом MaskOnFace;
  • Люди в маске не на лице ("бикини из масок"), размечаем тегом MaskNotOnFace на волне маскобикини-хайпа используем и такой случай, чтобы наша модель машинного обучения не пропускала хитрых фитоняш в маскобикини через турникет (наверное, стоящий на входе в фитнес-клуб, где они качаются);
  • Люди без масок, изображения масок без людей, не размечаем тегами (Negative).

Картинки можно найти в интернете или пофоткать всех знакомых.


Нажимаем кнопку Train, далее Advanced training и ждем, пока модель обучается. После чего на вкладке Performace можно посмотреть параметры качества функционирования модели.


Здесь важно, собственно, понимать эти параметры качества ну хотя бы в общих чертах.


Значение Probability Threshold это вероятность назначенного тега, в зависимости от которой рассчитываются параметры качества функционирования модели. Значение Probability Threshold = 90% означает, что правильными предсказаниями будут считаться теги, вероятность которых оказалась выше 90%. Думаю, эта фраза требует пояснения. Вообще, в машинном обучении ответы обычно не дискретные (да/нет), то есть модель не может "ответить" на вопрос "на лице ли у человека маска" просто "да" или "нет". Грубо говоря, будет что-то типа "маска на лице с вероятностью 89%". Проблема в том, что для расчета параметров качества модели нужны как раз те самые дискретные "да" или "нет". И вот если параметр этот самый Probability Threshold установлен 90%, то ответ "маска на лице с вероятностью 89%" превратится в дискретное "нет", а ответ "маска на лице с вероятностью 91%" превратится в дискретное "да".


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


  • Параметр Recall (полнота) означает способность алгоритма обнаруживать заданный класс вообще;
  • Параметр Precision (точность) способность отличать этот класс от других классов.

Чем больше каждое из значений тем лучше.


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


Модель следует опубликовать (Publish), а затем экспортировать (Export Dockerfile Linux). Полученный файл далее будет использоваться в модуле IoT Edge.


Подготовка наземной платформы


Из-за архитектурных особенностей примера нам понадобится платформа (а именно процессор) с поддержкой AVX инструкций (узнать, поддерживает ли платформа AVX инструкции, можно, выполнив команду grep avx /proc/cpuinfo) это потребуется для корректной работы библиотеки tensorflow. Если вы хотите использовать платформу без поддержки AVX, потребуется пересобрать библиотеку, что выходит за рамки данной статьи. Упростим себе жизнь и возьмем платформу с соответствующей поддержкой. Мы использовали Intel NUC на базе Core i5.


В качестве ОС будем использовать Ubuntu 20.04 LTS. Сложность заключается в том, что инструкций для установки IoT Edge для данной версии нет (слишком свежая по мнению Microsoft?), поэтому о процессе настройки расскажем достаточно подробно.


Вначале установите саму ОС с графическим окружением, затем откройте командную строку для установки Edge. По умолчанию все команды выполняются в домашнем каталоге (~).


Установим необходимые утилиты:


sudo apt-get updatesudo apt-get install wget nano

Устанавливаем конфигурацию репозитория:


wget https://packages.microsoft.com/config/ubuntu/20.04/prod.listmv prod.list microsoft-prod.list

Копируем полученный файл в директорию sources.list.d, чтобы ОС "видела" репозитории Microsoft:


sudo cp ./microsoft-prod.list /etc/apt/sources.list.d/

Загружаем и устанавливаем публичный ключ Microsoft GPG:


wget https://packages.microsoft.com/keys/microsoft.asccat microsoft.asc | gpg --dearmor > microsoft.gpgsudo cp ./microsoft.gpg /etc/apt/trusted.gpg.d/

Устанавливаем ПО для контейнеризации (обратим внимание на первую команду ее обязательно нужно выполнить, так как мы добавили новые репозитории и apt еще "не в курсе"):


sudo apt-get updatesudo apt-get install moby-engine

Устанавливаем демон IoT Edge:


sudo apt-get install iotedge

И с удивлением обнаруживаем, что такого пакета в добавленных выше репозиториях нет (это касается только нашей Ubuntu 20.04 на момент публикации статьи), поэтому вместо следования документации пойдем своим путем. Можем добавить репозитории от более ранней версии Ubuntu (18.04 что, строго говоря, не очень хорошая идея) или установить пакеты вручную (правда, опять же, от более ранней версии). Пойдем вторым путем и установим нужные пакеты с GitHub. Ищем Latest release и устанавливаем его при помощи dpkg. Нам также понадобится libssl определенной версии:


wget http://archive.ubuntu.com/ubuntu/pool/main/o/openssl1.0/libssl1.0.0_1.0.2n-1ubuntu5_amd64.debsudo dpkg -i libssl1.0.0_1.0.2n-1ubuntu5_amd64.debwget https://github.com/Azure/azure-iotedge/releases/download/1.0.10.4/libiothsm-std_1.0.10.4-1_ubuntu16.04_amd64.debsudo dpkg -i libiothsm-std_1.0.10.4-1_ubuntu16.04_amd64.debwget https://github.com/Azure/azure-iotedge/releases/download/1.0.10.4/iotedge_1.0.10.4-1_ubuntu16.04_amd64.debsudo dpkg -i iotedge_1.0.10.4-1_ubuntu16.04_amd64.deb

Среда выполнения IoT Edge установлена, но она пока не подключена к Azure. Чтобы это сделать, наберем команду:


sudo nano /etc/iotedge/config.yaml

И в открывшемся файле увидим, что для подключения к Azure необходимо указать значение device_connection_string в разделе provisioning. Для того, чтобы получить это значение, зарегистрируем наш экземпляр IoT Edge в Azure.


Настройки в Azure


Все экземпляры IoT Edge подключаются к IoT Hub, который мы сейчас и создадим на портале Azure. Если у вас нет подписки создайте пробную.


Сама процедура создания IoT Hub и регистрации IoT Edge подробно описана в документации. Особого смысла перепечатывать ее здесь не вижу, поэтому предлагаю вам повторить то, что в ней описано:



В результате ваше устройство IoT Edge будет подключено к созданному IoT Hub, а также будет подготовлен репозиторий контейнеров.


Разработка


Внутри IoT Edge нашего решения будут исполняться сразу три модуля:


  • Модуль захвата изображения с камеры. Работает напрямую с веб-камерой, подключенной по USB. Отдает картинку на следующий модуль по HTTP;
  • Модуль машинного обучения, распознающий изображения и классифицирующий их (в маске/без маски/маска не на лице). Получает картинку по HTTP, отдает результат распознавания в следующий модуль путем обмена сообщениями;
  • Модуль отображения (веб-сервер). Отдает по запросу веб-страницу, на которой можно увидеть видео с камеры и результат распознавания.

Схема коммуникаций между модулями показана ниже:



Перед тем, как приступить к разработке, нам потребуется загрузить и установить соответствующие инструменты.


Важно! Последующие действия нужно выполнять на компьютере с Windows 10, а не на устройстве с IoT Edge.

  • Загрузите и установите Visual Studio Code. Разработку также можно вести и в Visual Studio;
  • Установите расширение Azure IoT Edge Extension. После установки на открывшейся странице нажмите Select IoT Hub, пройдите аутентификацию и выберите созданный ранее IoT Hub;
  • Установите расширение Azure IoT Tools;
  • Установите Python 3.8.3. При установке отметьте опцию Add Python to PATH подробнее здесь в секции Task 4;
  • Перейдите в Панель управления, затем Программы и компоненты, и убедитесь, что включена вся группа Hyper-V и Контейнеры. Если нет отметьте их, нажмите OK и при необходимости перезагрузите компьютер;
  • Установите Docker for Windows подробнее там же в секции Task 5;
  • Установите клиент Git для Windows последней доступной версии.

Важно! В случае проблем с виртуализацией Docker выполните команду в командной строке администратора: bcdedit /set {current} hypervisorlaunchtype Auto и перезагрузите компьютер.

Важно! Включение Hyper-V сделает неработоспособной виртуализацию VirtualBox. Для того, чтобы быстро восстановить работоспособность VirtualBox, можно выполнить команду в командной строке администратора: bcdedit /set {current} hypervisorlaunchtype off, но при этом "сломается" Hyper-V и Docker.

Получите исходный код примера, выполнив команду:


git clone https://github.com/Azure-Samples/Custom-vision-service-iot-edge-raspberry-pi.git

Рекомендую также переключиться на коммит, который был использован для модификации примера:


git checkout 6b3540f9b31121321f9e75d8df0ed86397c9324f

В Visual Studio Code откройте папку с примером (File Open Folder) и ознакомьтесь с его структурой. Вы увидите три модуля, о которых мы говорили выше. Если при открытии среда предложит установить дополнительные расширения, сделайте это.


Модификация примера


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


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


Итак, поехали.


.env


Необходимо установить параметры реестра (репозитория) контейнеров, взятые с портала Azure:


  • CONTAINER_REGISTRY_ADDRESS="имя_реестра_контейнеров.azurecr.io"
  • CONTAINER_REGISTRY_USERNAME="имя_пользователя"
  • CONTAINER_REGISTRY_PASSWORD="пароль"

deployment.template.json


  • modules camera-capture env RESIZE_WIDTH установить 640, RESIZE_HEIGHT установить 480
  • modules camera-capture settings image установить ${MODULES.CameraCapture.amd64}
  • modules sensehat-display env THRESHOLD value установить 0.9
  • modules sensehat-display settings image установить ${MODULES.SenseHatDisplay.amd64}, createOptions удалить содержимое HostConfig и установить "PortBindings": { "8000/tcp": [ { "HostPort": "8000" } ] }
  • modules image settings image установить ${MODULES.ImageClassifierService.amd64}

deployment.template_AMD64


Данный файл следует удалить с файловой системы.


СameraCapture\amd64.Dockerfile


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


CameraCapture.py


Поскольку мы перенесли решение на более мощную платформу (по сравнению с Raspberry Pi), уменьшим временной интервал, за который накапливаются кадры для анализа. Для этого ищем строку time.sleep(1.0) и заменяем 1.0 на 0.1.


ImageClassifierService\amd64.Dockerfile


Здесь потребуется подобрать версии библиотек для AMD64. Модифицированный файл можно найти в приложенном архиве.


labels.txt


Данный файл содержит метки, которые получает каждое изображение. Эти метки должны соответствовать меткам из сервиса Custom Vision, поэтому содержимое файла должно быть следующим:


MaskNotOnFaceMaskOnFace

model.pb


Двоичный файл модели из Custom Vision следует заменить существующий на подготовленный нами ранее.


SenseHatDisplay\amd64.Dockerfile


Такого файла в примере нет, нам нужно его создать.


SenseHatDisplay модуль отображения результата распознавания. Но на нашей платформе AMD64 никакого шилда SenseHat нет, поэтому из данного модуля весь код, взаимодействующий, собственно, с SenseHat, уберем, и будем реализовывать простейший веб-сервер на Python, который сможет прямо в браузере показывать результат распознавания.


Файл можно найти в приложенном архиве.


SenseHatDisplay\module.json


В раздел platform нужно внести изменения, а именно добавить amd64:


"amd64": "./amd64.Dockerfile",

SenseHatDisplay\app (директория)


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


  • custom.js
  • index.htm
  • jquery.js
  • style.css
  • DisplayManager.py
  • MessageParser.py

Веб-сервер достаточно "хитрый". Он отдает клиенту страницу, в которой выполняются сразу две важных вещи:


  • Отображается видеопоток от модуля захвата изображения с камеры: его можно увидеть прямо с компьютера с IoT Edge, зайдя браузером на адрес http://127.0.0.1:5012;
  • Отображается результат распознавания от модуля классификатора по адресу http://127.0.0.1:8000/status.

Подчеркну, что фактически получаются два веб-сервера один с видеопотоком, второй с результатом распознавания. Причем страницу, с которой идет обращение к этим серверам, отдает второй сервер. Сама эта страница доступна по адресу http://127.0.0.1:8000.


Сборка


Для сборки потребуется подключение к Интернет.


  • В VS Code выберите View Command Pallette Azure IoT Edge: Set Default Target Platform for IoT Edge Solution и в появившемся списке выберите amd64;
  • Там же выберите команду Azure IoT Edge: Build and Push IoT Edge Solution. Все должно собраться с первого раза и загрузиться в реестр контейнеров, но этого еще недостаточно для попадания на устройство IoT Edge;
  • Разверните решение на IoT Edge, кликнув правой кнопкой на файл config/deployment.json и выбрав Create Deployment for Single device, затем выберите ваше устройство, указав его имя;
  • На развертывание потребуется некоторое время (не забудьте подключить к платформе веб-камеру!). Можете кликнуть на ваше устройство правой кнопкой мыши в расширении IoT Edge Extension и выбрать Start Monitoring D2C Message, тем самым наблюдать телеметрию.

Момент истины


На нашем IoT Edge устройстве логинимся в UI и прямо браузером заходим на веб-страницу по адресу http://localhost:8000, где наблюдаем веб-страницу, как на картинке. Надеваем маску и смотрим в камеру, система определяет, что маска на нас.



Дело за малым подключить исполнительное устройство, которое открывает наш условный турникет.


К огромному сожалению, моделей в маскобикини, чтобы проверить срабатывание тега MaskNotOnFace, у нас не нашлось, но на тестовых картинках все работало хорошо.


Если что-то пошло не так...


Если модули собрались и отлажены, а устройство в сети, вмешательство на стороне IoT Edge не требуется. Но иногда на этапе запуска возникают проблемы (так я, например, узнал, что без AVX инструкций и/или пересборки библиотеки tensorflow модуль классификатора не работает). IoT Edge предлагает разные способы диагностики. Подробно о них можно прочитать здесь. Самое главное, что может пригодиться:


  • Получить список модулей и их статус: iotedge list. В примере на рисунке видно выполняющиеся модули и их аптайм (более недели);
  • Журнал модуля: iotedge logs имя_модуля. Позволяет понять, что конкретно происходит с модулем.

Обновление модулей


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


Что дальше?


Дальше можно отключить компьютер с IoT Edge от Интернета и убедиться, что все работает так же хорошо.


При всем перечисленном мы, конечно, не рассмотрели всех возможностей IoT Edge, например, мы никак не обработали телеметрию на облаке, а могли бы вести, например, журнал "проходов через турникет" и считать какую-нибудь статистику и даже сохранять ее локально при помощи SQL Edge, а затем синхронизировать с облаком.


Мы также совсем не рассмотрели возможности управления устройством IoT Edge с портала Azure, так как это было незначимо для темы данной статьи.


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


Мы убедились, что при помощи сервисов Azure можем комбинировать все плюсы как облачной, так и наземной разработки, и при этом получать решение, которое без проблем будет работать автономно.


Если у вас еще остались вопросы по облачным технологиям Microsoft и Интернету вещей обращайтесь к нам в Кварта Технологии.


Файлы к статье можно скачать по ссылке.


Автор статьи Сергей Антонович, ведущий инженер Кварта Технологии. Связаться с ним можно по адресу sergant (at) quarta.ru.

Подробнее..

Системы контроля управления доступом в IoT умеем, знаем, практикуем

27.01.2021 14:17:26 | Автор: admin

И снова привет, мир!

В прошлой статье про IoT-елочку в голосовании многие отметили, что интересна тема управления устройствами в зависимости от количества человек в помещении. Это довольно масштабная задача, и мы предлагаем разделить ее решение на несколько этапов. Сегодня поговорим о системе контроля управления доступом (СКУД), которая, будучи подключенной к платформе интернета вещей Rightech IoT Cloud (далее по тексту - платформа), является базовым элементом в системе подсчета количества человек в офисе. Мы уже поверхностно освещали этот кейс в одной из статей, но сегодня рассмотрим этот проект более подробно и погрузимся в особенности исполнения.

СКУД?

Система контроля и управления доступом, СКУД (англ. Physical Access Control System, PACS) совокупность программно-аппаратных средств контроля и управления, главная цель которой - ограничение и регистрация входа-выхода объектов (людей, транспорта) на заданной территории через точки прохода: двери, ворота, КПП.

С чего все началось

Задача обеспечить контроль за входом-выходом в офисе возникла еще в те времена, когда у нас был выход на крышу с отличным видом на Москву, и поэтому часто приходили люди, не являющиеся нашими сотрудниками. Тогда мы решили принять какие-то меры по безопасности и установить СКУД.

Архитектура

Система открытия дверей по карте

В качестве модуля, отвечающего за обработку информации по считыванию бесконтактных карт, выбрали GATE-8000.

Основные достоинства контроллера:

  • формирование и хранение необходимой информации о факте открытия двери по карте и времени прохода человека в офис;

  • возможность автономной работы и защиты от зависания;

  • хранение 16 тысяч ключей и 8 тысяч событий;

  • простое подключение и управление;

  • российский производитель, хорошая документация с описанием работы контроллера.

Внешний вид платы с контроллеромВнешний вид платы с контроллером

Основной принцип работы: контроллер обрабатывает информацию, поступающую со считывателя, и с помощью встроенного реле коммутирует исполнительное устройство - электромагнитный замок двери.

Система взаимодействия с платформой

После того, как контроллер установили в систему по общей схеме подключения, а карты записали в память, мы уже обезопасили себя от прохода в офис посторонних. А дальше возник вопрос, как подключить этот контроллер к платформе Rightech ioT Cloud. Ведь очень здорово иметь а) графический интерфейс, в котором можно полистать историю всех проходов, б) возможность отправки команд на открытие двери удаленно, не отходя от рабочего места, например, для гостей или доставщика еды.

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

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

Аппаратная часть

Для начала нужно было выбрать устройство, которое будет всегда в активном состоянии с включенной программой-агентом в непосредственной близости от платы СКУД. Из многообразия микрокомпьютеров первое что попало под руку выбор пал на Raspberry Pi.

Дальше возник вопрос, как подсоединить GATE-8000 к Raspberry - то есть как подключить последовательный интерфейс RS485 от GATE к USB от микрокомпьютера. Начались поиски переходника USB-RS485. Первый вариант, который мы испробовали, - Espada за 200 рублей. Надежда на то, что маленький хлипкий китайский переходник заработает, была небольшой. Он и не заработал. Вместо нужных данных приходило что-то похожее по виду и размеру, но всё же не то. В чем было дело: в отсутствии гальванической развязки, невозможности поддерживать скорость 19200 bps или же просто в некачественной элементной базе, - загадка. Но после обращения к производителю GATE-8000, мы получили рекомендацию на более дорогой (в 10 раз) и громоздкий (но аккуратный и корпусированный) переходник Z-397, который заработал тут же как надо.

Программная часть

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

  1. Что нужно - взаимодействие с GATE-8000 для отправки команд и получения данных.

    Как решим - изучим протокол GATE, напишем сериализатор и десериализатор данных, подключим библиотеку для работы с последовательным портом.

  2. Что нужно - взаимодействие с платформой для получения команд и отправки данных.

    Как решим - выберем для общения протокол MQTT, в коде воспользуемся готовой библиотекой Paho MQTT.

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

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

1) задавать всю логику работы в агенте;

2) использовать внешние запросы (от платформы).

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

Всегда ли нужно выносить логику работы с устройства?

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

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

Карта памяти контроллера? WTF?

Под картой памяти контроллера (термин из протокола) имеется в виду таблица с описанием заполнения регистров памяти, а не микрофлешка =).

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

1) найден ключ в банке ключей (банк ключей - еще один блок в распределенной памяти контроллера);

2) состоялся проход (если он, конечно, состоялся).

Ниже представлен фрагмент кода на С++, реализующий метод одного цикла чтения буфера.

bool SerialPortInlet::readBufferCycle(unsigned short& bottom, unsigned short const& top, unsigned char& u_lowerBound,    unsigned char& l_lowerBound, std::vector<unsigned char>& readBuffer, std::string& result){// Подсчет байтов, которые необходимо считатьunsigned short byteCountTmp = top - bottom;BOOST_LOG_SEV(log_, logging::info) << "Need read " << byteCountTmp << " byte";unsigned char byteCount;// За один цикл нельзя прочитать более 12 событий (96 байт)byteCount = byteCountTmp > 0x60 ? 0x60 : (unsigned char)byteCountTmp;BOOST_LOG_SEV(log_, logging::info) << "Read " << +byteCount << " byte";// Описываем тело командыstd::vector<unsigned char> body = {0x02, 0xA0, byteCount, u_lowerBound, l_lowerBound};std::vector<unsigned char> command;// Получаем полный текст командыgenerateComplexCommand(command, Command::BYTE_CODE_READ, body);// Если не удалось по каким-то причинам отправить команду (например, конечное устройство не подключено), возвращается falseif (!sendCommand(command, result)){    return false;}// Иначе отправляем ответ с устройства на парсинг по событиямSerialPortType::Answer answerEvents;if(!Parsers::parserAnswer(log_, result, answerEvents, Command::BYTE_CODE_READ)){    BOOST_LOG_SEV(log_, logging::error) << "Failed parse buffer reading";    return false;}readBuffer.insert(readBuffer.end(), answerEvents.body.begin(), answerEvents.body.end());// Сдвигаем нижнюю границу буфера для чтения следующих событийbottom = bottom + byteCount;u_lowerBound = (unsigned char)(bottom >> 8) ;l_lowerBound = (unsigned char)bottom;return true;}

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

Байтстаффинг?

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

Пример байтстаффинга из документацииПример байтстаффинга из документации

Полная структурная схема разработанной системы выглядит так.

Работоспособность всех устройств было очень удобно проверять с помощью графического последовательного терминала СuteCom. После успешного тестирования программа была поставлена на автозапуск, а Raspberry отправилась жить на потолке рядом с платой СКУДа.

Один делает, другой смотрит, третий фотографирует, огнетушитель придерживает дверь - настоящая командная работа =)Один делает, другой смотрит, третий фотографирует, огнетушитель придерживает дверь - настоящая командная работа =)

Работа на платформе Rightech IoT Cloud

Модель

Основные данные с контроллера - это события, на платформу они приходит в формате JSON и включают в себя поля

  • eventTime - время наступления события;

  • eventCode - код события;

  • keyNumber - номер карты сотрудника (поле может быть пустым, если событие вызвано не картой).

Модель устройства выглядит следующим образом.

Посмотреть оригинал >>>

Возможные события:

  • нажата кнопка звонка;

  • неопознанный ключ на входе;

  • неопознанный ключ на выходе;

  • ключ найден в банке ключей при входе;

  • ключ найден в банке ключей при выходе;

  • открывание оператором по сети;

  • дверь заблокирована оператором;

  • дверь оставлена открытой после входа;

  • дверь оставлена открытой после выхода;

  • проход состоялся на вход;

  • проход состоялся на выход;

  • перезагрузка контроллера.

Объект

Интерфейс объекта полностью формируется согласно разработанной модели.

Интерфейс истории журнала объектаИнтерфейс истории журнала объекта

Посмотреть оригинал >>>

Интерфейс командИнтерфейс команд

Ура, теперь, собравшись на кухне офиса в ожидании пиццы на праздник, можно никуда не идти, а просто открыть мобильное приложение и нажать кнопку открытия двери для курьера!

Автомат

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

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


Посмотреть оригинал >>>

Здесь виден цикл <чтение>-<запись новой границы буфера>-<ожидание таймера> (сейчас события считываются каждые 30 секунд).

  1. В состоянии Read events читаем новые события.

  2. В состоянии Clear buffer записываем новую границу.

  3. В состоянии Await timer ожидаем начала нового цикла.

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

Дальнейшее использование собранных данных

Данный проект нашел свое продолжение в интеграции с нашей внутренней CRM системой, в которой на вкладке информации о сотрудниках всегда видны актуальные сведения о том, кто находится или отсутствует в офисе.

Также отображается время входа/выхода из офиса, считается суммарное количество часов в месяц.

Посмотреть оригинал >>>

В мессенджер Slack каждый день пишется о том, что офис открыт, когда приходит первый человек, взявший ключи на ресепшене.

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

Посмотреть проект, в котором есть пример настройки взаимодействия и получения данных с платформы >>>


Теперь мы знаем немного больше о том, как может работать СКУД в IoT-проектах. В следующих материалах рассмотрим, как рассчитать на базе полученной информации количество человек в офисе и какие практические применения есть у этой идеи.

Подробнее..

СВЧ конденсаторы 0402 ATC 600L vs. Johanson Technology R07S

04.03.2021 14:05:18 | Автор: admin

Выбор СВЧ конденсатора не всегда очевиден, т.к. требует детального сравнения. Ошибка в этом вопросе может привести либо к неоправданному удорожанию устройства, либо к его недостаточной надежности. В данной статье как раз и проведен сравнительный анализ по нескольким параметрам многослойных СВЧ конденсаторов двух известных брендов: ATC и Johanson Technology, и даны общие рекомендации по выбору между ними.

1. Общие характеристики

Параметр

ATC

Johanson Technology

Диапазон емкостей, пФ

0.1 27

0.1 33

Рабочее напряжение, В

200

50, 200 и 250

Диапазон температур

-55+125 град. С

-55+150 С

Наработка на отказ

2000 ч. @ +125 С и 2x WVDC

1000 ч. @ +125 С и 2x WVDC

ТКС

0+/-30 ppm

0+/-30 ppm

Добротность

>2000@1 МГц

>10000@1 МГц

Старение

нет

нет

Пьезоэффект

нет

нет

Влагоустойчивость

85C, 85% RH, at rated WVDC, 1000 hours

40C, 85% RH, 1.5 WVDC, 240 hours

Конденсаторы ATC соответствуют или превосходят требования стандартов EIA-198, MIL-PRF-55681, MIL-PRF-123.

По диапазону рабочих напряжений компания Johanson Technology предоставляет более гибкий выбор. На 50 В выпускаются конденсаторы 30, 33 пФ, которых нет в линейке ATC. Остальные конденсаторы выпускаются в двух вариантах: 50 и 200/250 В

2. Отклонения емкости от номинала

Код

A

B

C

D

F

G

J

K

M

ATC, Отклонение, +/-

0.05 пФ

0.1 пФ

0.25 пФ

0.5 пФ

1 %

2 %

5 %

10 %

20 %

Johanson, Отклонение, +/-

0.05 пФ

0.1 пФ

0.25 пФ

0.5 пФ

1 %

2 %

5 %

10 %

3. Эффективное последовательное сопротивление (ESR)

Рис. 1 ESR для конденсаторов ATC

Рис. 2 ESR для конденсаторов Johanson Technology

Для частоты 1 ГГц ESR конденсаторов ATC лежит в пределах 0.07-0.09 Ом, а конденсаторов Johanson Technology лежит в пределах 0.07-0.1 Ом, т.е. они практически равны.

Но для частоты 2 ГГц ESR конденсаторов ATC лежит в пределах 0.12-0.14 Ом, а конденсаторов Johanson Technology лежит в пределах 0.14-0.18 Ом. Т.е. у конденсаторов ATC ESR примерно на 15-30% лучше.

Надо полагать, что на более высоких частотах разница еще более существенная. Но на частотах <1 ГГц ESR конденсаторов этих двух серий отличается незначительно.

4. Добротность

Рис. 3 Добротность конденсаторов Johanson Technology

Для конденсаторов ATC аналогичный график не приведен. Указано лишь, что она >2000 @ 1 МГц.

5. Частота последовательного резонанса (SRF)

Рис. 4 SRF для конденсаторов ATC

Рис. 5 SRF для конденсаторов Johanson Technology

Как видно из приведенных выше графиков, собственная частота последовательного резонанса у конденсаторов ATC несколько выше: 12ГГц @ 1 пФ против 9ГГц @ 1 пФ и 4 ГГц против 3-х ГГц для 10 пФ.

Возможно, эта разница связана с материалом печатной платы, на которой проводилось тестирование. Для ATC это RO4350 толщиной 10 mil ; для Johanson Technology RO4003 толщиной 16 mil.

6. Максимальный допустимый ток

Рис. 6 Максимальный допустимый ток для конденсаторов Johanson Technology

Аналогичные данные для конденсаторов ATC не приведены.

Таким образом, конденсаторы ATC обладают более высокой надежностью и лучшим ESR на частотах выше 2 ГГц. На частотах ниже 1 ГГц конденсаторы Johanson Technology не уступают им по параметрам и существенно дешевле. Что существенно для таких массовых приложений как IoT.

Подробнее..

Что такое энергоэффективность LPWAN. Проживет лиNB-IoTустройство 10 лет от батарейки?

04.04.2021 06:16:15 | Автор: admin

Привет, всем уважаемым читателям Хабра!

Я, Шептовецкий Александр, в последнее время профессионально занимаюсь различными вопросами эффективности работы различныхLPWANсистем интернета вещей и хотел бы выступить на данной площадке в качестве эксперта в этой области.

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

Хочу анонсировать серию статей, в которых попытаюсь внести дополнительную ясность в ключевые особенности работыLPWAN систем, энергоэффективность, дальность, время работы от одной батарейки, пропускная способность, безопасность и многое другое. Постараюсь быть максимально объективным.

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

Как померить энергоэффективность

При описанииLPWANсистем постоянно используется слово энергоэффективность, что же оно означает и можно ли ее померить?

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

Посмотрим, как определяется понятие энергоэффективность в рекомендациях международного союза электросвязи. В разделе общие положения МСЭ-T L.1310 определено, что показатель энергоэффективности обычно определяется как отношение между функциональной единицей и энергией, требуемой для вырабатывания функциональной единицы.

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

Энергоэффективность - величина обратно пропорциональная энергии, затраченной на передачу одного сообщения.

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

Рисунок 1. Позиционирование LPWANРисунок 1. Позиционирование LPWAN

В интернете постоянно попадается картинка из трех кругов со следующим комментарием: Любые существующие беспроводные технологии передачи данных обладают такими характеристиками какдальность, скорость иэнергоэффективность. Причем одновременно можно соответствовать лишь 2-м из3-х..

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

Энергоэффективность х Площадь покрытия х Скорость =Constant

LPWANдатчики как правило питаются от 3,6 В литиевой батарейки, энергию которой принято определять в милиампер-часах (мАЧ), поэтому, удобнее всего энергию сообщения будет считать в микроампер-часах (мкАЧ). Например, на стандартное короткое сообщение LoRaWAN, длительностью 1,6 секунд расходуется 20 мкАЧ энергии батарейки, что позволяет в предельном случае отправить до 100 тысяч сообщений от стандартной батарейки емкостью 2000 мАЧ. УSigFoxс энергетикой дело обстоит хуже, там сообщение повторяется три раза и длится в эфире 6,2 секунд и потребляет 78 мкАЧ (реальные испытания компанией Rohde & Schwarz показали, что в реальности потребление даже выше - 106 мкАЧ, можно убедиться в этом в отчете). Это значит, что если энергия тратится только на передачу регулярных сообщений, то батарейка уSigFoxразрядится в 3,8 раза быстрее, чем уLoRaWAN устройства! Эта разница существенна! Там, где одно устройство проработает от одной батарейки более трех лет, другое не проживет и года!

Энергоэффективность нельзя сравнивать для систем с разной дальностью работы. Попробуем, например, оценить энергоэффективность датчика сBluetoothканалом.BLEмаячок мощностью 0dBmс короткими сообщениями тратит на передачу с периодом 1 раз в секунду около 7 мкА, это говорит о его беспрецедентной энергоэффективности. От литиевой батарейки 1000 мАЧ он проработает до 15 лет, и передаст более 470 миллионов сообщений, потратив на каждое только 2,1 нАЧ!

Bluetoothможет передать от одной батарейки в десятки тысяч раз больше сообщений, чемLoRaWANилиSigFox

Теперь посмотрим наNB-IoT.

ЭнергоэффективностьNB-IoT

В первую очередь прояснить вопрос энергоэффективностиNB-IoTменя заставило распространенное утверждение, что NB-IoT -LPWANрешение от сотовых операторов полностью вытеснит другиеLPWANрешения, которые работают в безлицензионном диапазоне частот, такие какLoRaWAN,SigFoxи т.п. Давайте посмотрим, как обстоит дело с ключевымLPWANпараметром - энергоэффективностью NB-IoT.

Требования стандарта 3GPPрассчитаны на то, что NB-IoT устройства работать от батарейки десять лет. К сожалению, реальных практических исследований в этой области очень мало. Я обратился к некоторым производителямGPSтрекеров в России, которые реально используют NB-IoT и получил ответ, что по их данным: "NB-IoT действительно обеспечивает большую зону покрытия, но добиться значительного уменьшения потребления связи для передачи коротких сообщений им не удается", по их опыту потребление 2Gмодуля, в среднем, менее чем в 2 раза превышает потребление NB-IoT модуля. То есть NB-IoT получается выигрывает по энергетике у решений 2G не более чем в 2 раза. Выдающимся этот результат явно не назовешь, почему так получилось?

Для прояснения этого вопроса пришлось изучить последние зарубежные исследования в этой области, и вот краткий результат. В отличие от большинства своих конкурентов, NB-IoT появился не с чистого листа, он является модификацией LTE, из которой он наследует многие особенности, определяющие его критические характеристики - энергопотребление, надежность и другие.

Результаты исследования NB-IoT показывают, что его производительность - с точки зрения энергии, в идеальном случае - сопоставима с LoRaWAN. В реальности же наблюдается очень высокий разброс характеристик расхода энергии на одно сообщение от конечного устройства ( данные взяты из публикации Exploring the Performance Boundaries of NB-IoT).

Рисунок 2. разброс энергии на передачу данных в зависимости от режима работыРисунок 2. разброс энергии на передачу данных в зависимости от режима работыРисунок 3. Соотношение сигнал/шумРисунок 3. Соотношение сигнал/шум

ЭнергоэффективностьNB-IoTобеспечивается установкой соответствующих параметров конечного устройства и установками операторов сети для режима сохранения энергииPSM. На рисунках 2 и 3 ( данные взяты из публикации Exploring the Performance Boundaries of NB-IoT) приведены примеры разброса энергии, затраченной конечным устройством в зависимости от устройств в сетях разных операторов и при разных уровнях принимаемого сигнала.

Нельзя забывать, что вNB-IoT энергия тратится не только на саму передачу информации, но и на некоторые другие специфические процедуры, присутствующие в протоколах сотовой связи и унаследованные от LTE и 5G, такие как присоединение и синхронизация с сетью, обмен ключами и шифрование данных.

Вопросы дополнительного потребления NB-IoT устройств подробно рассмотрены в отчетеNarrowband IoT Device Energy Consumption Characterization and Optimizations.

Структура безопасности, используемая в NB-IoT, унаследована от сетей 4G и 5G и обеспечивает процессы фактической аутентификации между устройством и сетью, установление контекста безопасности устройства (SC), который должен быть использован в последующих сообщениях для обеспечения целостности и конфиденциальности данных.

Рисунок 4. Доля времени, потраченного на различные операции в рабочем состоянии (кроме IMSI шифрования).Рисунок 4. Доля времени, потраченного на различные операции в рабочем состоянии (кроме IMSI шифрования).

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

УстройстваNB-IoTпотребляют энергию в любом из трех состояний: легкий сон, глубокий сон и работа.Состояния легкого и глубокого сна соответствуют состояниям ожидания и PSM 3GPP, когда устройство потребляет мало энергии или почти не потребляет.Рабочее состояние это состояние, во время которого устройство генерирует данные и общается с сетью и потребляет энергию на процесс установления соединения (RA), процесс присоединения, обмен данными (включая любые требуемые запросы на планирование, прием контрольных данных, шифрование / дешифрование), IMSI дешифрование и активное ожидание. При этом надежные механизмы шифрования могут быть очень энергозатратными и существенно повлияют на время автономной работы устройства.

Потребление энергии в рабочем состояние может быть на порядки больше, чем два других состояния. Фактически потребление энергии для передачи данных и прием на порядки ниже, чем при оперативном выполнении функций RA, Attach и Active Waiting.

Кроме того, NB-IoT определяет три возможных уровня связи, нормальный, надежный и экстремальный, в которых используют разные количество повторов (до 128 и 2048 повторов для восходящей и нисходящей линии связи соответственно).

На рисунке 5 приведены расчеты потребления конечных устройств для 10 лет непрерывной работы взятые из отчетаNarrowbandIoTDeviceEnergyConsumptionCharacterizationandOptimizations. Следует отметить, что у стандартной литиевой батарейки емкостью 1 000 мАЧ соответствует энергии около 12 КДж.

Рис 5. Энергия на периодическую передачу данных в зависимости от качества покрытия (normal, robust, extreme).Устройство A - GPy от Pycom, B - BC95 от Quectel, C - SARA-N2 от Sodaq.Рис 5. Энергия на периодическую передачу данных в зависимости от качества покрытия (normal, robust, extreme).Устройство A - GPy от Pycom, B - BC95 от Quectel, C - SARA-N2 от Sodaq.

Графики на рисунке 5 показывают очень большой разброс потребления в зависимости от качества покрытия сети и типаNB-IoTустройства. Действительно, если устройство передает один раз в сутки и находится в зоне качественного приема, то его потребление за 10 лет может составить от 5,5 до 55 кДж - в зависимости от установок сети, типа и качества программы устройства. Это соответствует емкости литиевой батарейки 3,6 вольт от 460 до 4 600 мАЧ. Как видим, условие десяти лет работы от батарейки выполняется, но! только в идеальных условиях! В зоне среднего уровня качества связи для передачи сообщений раз в сутки потребуется уже емкость батарейки от 1 700 до 6700 мАЧ. При этом, для передачи сообщений раз в час в течение 10 лет в зоне среднего качества покрытия понадобится неимоверно большая литиевая батарейка емкостью до 150 000 мАЧ.

Сравнение энергоэффективностиNB-IoTс безлицензионными системами получается явно не в пользуNB-IoT. Только в идеальных условиях: условиях высокого качества приема, правильно установленных оператором параметров сети, можно добиться результата не хуже, чем у безлицензионных решений. В зоне среднего качества покрытия ситуация будет другой, она отражена в таблице ниже:

Параметр

NB-IoT

LoRaWAN

SigFox

Энергозатраты на сообщение с полезной нагрузкой 2 байта*

400 мкАЧ

29 мкАЧ

128 мкАЧ

Количество сообщений от литиевой батарейки емкостью 2 АЧ

5 000

70 000

15 600

Срок жизни КУ на передачу раз в 10 минут от батарейки 2АЧ

1,1 мес

1,3 года

3,5 мес

Срок жизни КУ на передачу раз в час от батарейки 2АЧ

6,8 мес

7,8 лет

1,8 лет

*- дляNB-IoTвзята оценка энергозатрат на одно сообщение в режиме передачи раз в час в условиях среднего качества покрытия по результатам исследований в работе NarrowbandIoTDeviceEnergyConsumptionCharacterizationandOptimizations, для лучшего типа конечного устройства (устройство С). Методика расчета значений энергоэффективности безлицензионных решений, отраженных в таблице, будет приведена в следующей статье.

Выводы:

  • Энергоэффективность различных LPWAN проще измерять в милиджоулях или микроампер-часах, затраченных на передачу одного стандартногосообщения.

  • Время работы от одной батарейки у различныхLPWANсистем может отличаться в разы и определяется количеством переданных сообщений (как правило это десятки-сотни тысяч сообщений от батарейки).

  • Датчики на NB-IoT будут обладать очень большим разбросом потребления в зависимости от производителя, рабочей сети и условий эксплуатации. Один и тот-же датчик в одних условиях проживет 10 лет, а в других не протянет и пару месяцев.

Получается, что датчики NB-IoT, несмотря на то, что они работают на выделенных частотах, в реальных условиях массового применения будут проигрывать в энергетике малопотребляющим LPWAN решениям, работающим в безлицензионном диапазоне частот.

Подробнее..

Создание своей оценочной платы для микроконтроллеров

16.04.2021 02:15:22 | Автор: admin

Заказывая много оценочных плат из Китая, я и подумать не мог что всюду будет брак, недоработки и подделка. Всё это ужасно путало в изучении и порой было тяжело понять то ли мой код кривой, то ли контроллер. Примерно в это же время я нашёл микроконтроллеры и другую рассыпуху дешевле чем в Китае при это локально в России. Я сразу загорелся тем, что бы сделать себе платы и забыть о китайских корявых blue pill.

Брак или странная задумка инженеров

Земля на ножках для прошивки висела в воздухе, после доработки всё окей.

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

Первые наброски выглядели примерно так:
v1v1

Тут я ещё не знал, что для нормальной прошивки мк нужен pull-up резистор на ногу сброса.

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

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

Детальное фото печатной платы

В итоге у меня было куча плат, с пяток контроллеров и разных вторичных компонентов, выпаянных из разных плат. Всё это вылилось в 3 рабочих прототипа.

В итоге у меня было куча плат, с пяток контроллеров и разных вторичных компонентов, выпаянных из разных плат. Всё это вылилось в 3 рабочих прототипа:

Фото ужасное, но переснять не могу уже раздал их)Фото ужасное, но переснять не могу уже раздал их)

Немного о платах

Остановился на 6 светодиодах. Всего 3 группы: питание, 4 GPIO, 1 GPIO(ШИМ) на обратной стороне. У каждой группы есть маленькая напаиваемая перемычка.

USB только питание, по входу стоит диод, защита usb выхода от обратного напряжения которое может пойти если запитать схему >5в напряжением. Стабилизатор выдерживает пиковые 16в, штатное до 14в.

Контроллер может без проблем работать и от 5в, но расчёт резисторов для светодиодов выполнял для 3.3, да и базово считаю что лучше работать с 3.3, ибо потом по привычке можно что-нибудь спалить.

Продолжаем вакханалию

Это была только половина пути, я ведь хотел много плат и очень не хотел делать их вручную.

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

И так, надо было решать как спаять всё быстро и с минимумом косяков. Трафарета у меня не было и я решил попробовать просто намазать тонким слоем паяльную пасту (благо она была).

Сказано сделано, вот что из этого вышло:

Мелкие капельки припоя что никуда не стекли прилипли прилично, далеко не с первого раза я их смог убрать, так же видно что 2 контроллера немного поплыли и встали криво. Выглядит жуть, но в целом получилось неплохо. Я делал несколько прогонов, первый мк и обвязка, остальное вторым. И по выходу получилось около 70% годных и готовых сразу без танцев плат.

Финальный результат, usb портов к этому времени не подвезли, так что без них.

Пока остановился на этом, с новой партией плат должен прийти трафарет, там уже будут другие танцы и другие бубны.

Планы у меня наполеоновские, уже нарисовал и под stm32f0 и под f1 платы, ещё есть идея создать плату на stm32f4(7) с интегрированных ethernet.

Для тех кто дочитал, спойлер след платы!

В следующей статье затрону контроллер и среды, в которых пишу. Ни пуха ни пера и не болейте!

Подробнее..

Перевод Fusion Project Teraki, Airbiquity, Cloudera, NXP и Wind River объединяют усилия, чтобы обучать ИИ в облаке

11.03.2021 18:13:13 | Автор: admin
image

Когда в наши дни автопроизводители говорят об автомобилях нового поколения, речь идет о транспортных средствах с ИИ, способных развиться от 2+ до 4 уровня автономности. Функции автоматизации езды в таких автомобилях будут управляться моделями машинного обучения и будут обновляться на протяжении всего жизненного цикла транспортного средства.

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

Но чтобы спроектировать архитектуру сетевых транспортных средств, способных развиваться от 2+ до 4 уровня, необходимо заполнить большой пробел, считает Дэниел Ричарт, соучредитель и генеральный директор Teraki. Дэниел отмечает, что есть большая разница между концептуальной моделью, работающей в лаборатории и реальным умным автомобилем подключенным к сети, способным работать в масштабируемых E/E архитектурах в рамках экономичной производственной модели.

В феврале 2021 компания Teraki представила свой Fusion Project, разрабатываемый совместно с Airbiquity, Cloudera, NXP Semiconductors и Wind River уже почти год. Эти пять компаний разработали пре-интегрированное аппаратное и программное решение, которое позволит автопроизводителям эффективно собирать, анализировать и управлять данными о подключенных транспортных средствах для непрерывной разработки, развертывания и развития их функций.

Фил Мэгни, основатель и президент VSI Labs, охарактеризовал Fusion как хорошую эталонную архитектуру для передачи данных из облака в машину при разработке, развертывании и поддержке систем помощи водителю и ADAS на основе ИИ.

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

Пять партнеров


В рамках проекта Fusion, Airbiquity отвечает за управление ПО по беспроводному подключению (OTA). Cloudera предоставляет независимые от облака инструменты для машинного обучения, NXP Semiconductors поставляет платформы для обработки данных с транспортных средств (Bluebox и Goldbox), а Teraki занимается краевыми вычислениями. Роль Wind River разработка интеллектуального ПО для систем краевых вычислений.

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

Одна из серьезных проблем, с которыми сегодня сталкиваются автопроизводители, это обработка данных от множества датчиков внутри беспилотных транспортных средств. Средний набор датчиков генерирует от 5 до 20 терабайт данных в день и так для каждого транспортного средства. Ограниченная возможность получать данные с автомобилей в реальном времени создает очевидную проблему. Еще одним препятствием является невозможность объединить все типы данных для построения моделей машинного обучения. Что еще более важно, управление данными в жизненном цикле машинного обучения раздроблено на этапы приема, обучения моделей и развертывания алгоритмов.

Решения Teraki созданы для управления данными для моделей машинного обучения с учетом различных требований. Мэгни объяснил: Все начинается с понимания что именно нужно искать и обработки данных с датчиков для обучения моделей. Решение от Teraki также претендует на эффективность и позволяет сжимать пакеты данных для отправки в облако с целью тренировки моделей машинного обучения.

Год назад, когда корреспонденты EE Times впервые встретились с Teraki на выставке CES 2020, Ричарт сказал, что технологии его компании будут сосредоточены на самой большой проблеме автопроизводителей: нехватке мощности автомобильных процессоров для обработки и отправки огромных объемов данных в облако для обучения моделей ИИ.

Решив эту задачу за год, компания Teraki, базирующаяся в Берлине, объединила экосистему партнеров и собрала технологии, необходимые для разработки решений на основе машинного обучения в облаке. Их усилия были направлены на разработку систем краевых вычислений для обработки данных с датчиков и их упаковки для дальнейшей пересылки, заметил Мэгни. Также есть проблемы в сетевом взаимодействии такие как ограниченная пропускная способность, ими занимается наш партнер, NXP.

По мнению Ричарта, самое важное достижение его проекта в том, что ему удалось разработать первый алгоритм ИИ (система удержания полосы движения), непрерывно улучшавшийся в результате обмена данными между автомобилем и облаком. Нам удалось обучить модель ИИ, которая изначально достигала 90-95% точности. Позднее нам удалось повысить точность до 98%.

Также он подчеркнул, что вся суть проекта в том, что теперь OEM-производители могут повышать точность своих моделей до 99+ процентов, постоянно дообучая модели и используя предпочтительный для них набор датчиков. Наше решение может применяться к абсолютно любым моделям. Мы дали OEM-производителям возможность быстро обучать системы ИИ, причем они могут внедряться в реальное промышленное оборудование, а не в специфические и дорогостоящие лабораторные образцы.

image

Герт-Ян ван Нунен, коммерческий директор Teraki, добавил, что Fusion дает OEM-производителям возможность обучать свои собственные модели ИИ и снова владеть интеллектуальной собственностью, избавившись от зависимости от других компаний. Взгляните на Mobileye, сказал он. Отметив, что решения Mobileye представляют собой черный ящик, из которого OEM-производители получают только высокоуровневую информацию, ван Нунен сказал: Мы предоставляем открытую систему, которая возвращает интеллектуальную собственность в руки OEM-производителей.

Создан ли Fusion для того, чтобы дать всем OEM-производителям возможность заниматься разработкой собственных стеков для беспилотной езды?, сказал Мэгни. С точки зрения OEM-производителей, существует множество возможностей для разработки собственных стеков. Однако, он предупредил: Эта область становится все более многочисленной, поскольку растет интерес к оптимизированным решениям, которые могут быть масштабированы от ADAS до беспилотной езды.

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




image

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

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

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

Если вам интересно попробовать свои силы в решении тех задач, которые у нас есть, пишите в личку.



О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

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

Подробнее..

Опыт написания IDL для embedded

24.02.2021 08:04:01 | Автор: admin

Предисловие

Я при работе с микроконтроллерами часто сталкивался с бинарными протоколами. Особенно, когда есть несколько контроллеров. Или же используется bluetooth low energy и необходимо написать код для обработки бинарных данных в характеристике. Помимо кода всегда требуется понятная документация.

Всегда возникает вопрос - а можно ли описать как-то протокол и сгенерировать на все платформы код и документацию? В этом может помочь IDL.

1. Что такое IDL

Определение IDL довольно простое и уже представлено на wikipedia

IDL, илиязык описания интерфейсов(англ.Interface Description LanguageилиInterface Definition Language)язык спецификацийдля описанияинтерфейсов, синтаксически похожий на описание классов в языкеC++.

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

Бонус также является - генерация документации, структур, кода.

2. Мотивация

В процессе работы я попробовал разные кодогенераторы и IDL. Среди тех, что попробовал были - QFace (http://personeltest.ru/aways/github.com/Pelagicore/qface), swagger (Это не IDL, а API development tool). Также существует коммерческое решение проблемы: https://www.protlr.com/.

Swagger больше подходит к REST API. Поэтому сразу был отметён. Однако его можно использовать если применяется cbor (бинарный аналог json с кучей крутых фич).

В QFace давно не было коммитов, хотелось некоторых "наворотов" для применения в embedded, возникли сложности при написании шаблона. Он не ищет символы сам, не умеет считать поля enum-ов.

Бесплатные решения было найти сложно, чтобы можно было комфортно использовать при разработке бинарных протоколов.

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

2.1 Обзор QFace

IDL, которая являлась источником вдохновения, имеет простой синтаксис:

module <module> <version>import <module> <version>interface <Identifier> {    <type> <identifier>    <type> <operation>(<parameter>*)    signal <signal>(<parameter>*)}struct <Identifier> {    <type> <identifier>;}enum <Identifier> {    <name> = <value>,}flag <Identifier> {    <name> = <value>,}

Для генерации используется jinja2. Пример:

{% for module in system.modules %}    {%- for interface in module.interfaces -%}    INTERFACE, {{module}}.{{interface}}    {% endfor -%}    {%- for struct in module.structs -%}    STRUCT , {{module}}.{{struct}}    {% endfor -%}    {%- for enum in module.enums -%}    ENUM   , {{module}}.{{enum}}    {% endfor -%}{% endfor %}

Концепция интересная. Можно было просто "подпилить" для комфорта "напильником", что конечно и сделал мой коллега. Но мне показалось интересным взять библиотеку sly и просто написать IDL с нужными фичами.

3. Обзор sly

Почему именно sly - библиотека очень проста для описания грамматики.

Сначала надо написать лексер. Он токенизирует код чтобы далее было проще обрабатывать парсером. Код из документации:

class CalcLexer(Lexer):    # Set of token names.   This is always required    tokens = { ID, NUMBER, PLUS, MINUS, TIMES,               DIVIDE, ASSIGN, LPAREN, RPAREN }    # String containing ignored characters between tokens    ignore = ' \t'    # Regular expression rules for tokens    ID      = r'[a-zA-Z_][a-zA-Z0-9_]*'    NUMBER  = r'\d+'    PLUS    = r'\+'    MINUS   = r'-'    TIMES   = r'\*'    DIVIDE  = r'/'    ASSIGN  = r'='    LPAREN  = r'\('    RPAREN  = r'\)'

Нужно наследовать класс Lexer, в переменную tokens - добавить свои использованные токены. Само определение токенов делается в теле класса - достаточно просто описать регулярное выражение, соответсвующее токену.

Парсер - делает работу по преобразованию набора токенов по определенным правилам. С помощью его и осуществляется основная работа. В случае компиляторов - преобразование в байт-код/объектный файл итд. Для интерпретаторов - можно сразу выполнять вычисления. При реализации кодогенератора - можно преобразовать в дерево классов.

Также парсер задается очень простым способом (пример из документации):

class CalcParser(Parser):    # Get the token list from the lexer (required)    tokens = CalcLexer.tokens    # Grammar rules and actions    @_('expr PLUS term')    def expr(self, p):        return p.expr + p.term    @_('expr MINUS term')    def expr(self, p):        return p.expr - p.term    @_('term')    def expr(self, p):        return p.term    @_('term TIMES factor')    def term(self, p):        return p.term * p.factor    @_('term DIVIDE factor')    def term(self, p):        return p.term / p.factor    @_('factor')    def term(self, p):        return p.factor    @_('NUMBER')    def factor(self, p):        return p.NUMBER    @_('LPAREN expr RPAREN')    def factor(self, p):        return p.expr

Каждый метод класса отвечает за парсинг конкретной конструкции. В декораторе @_ указывается правило, которое обрабатывается. Имя метода sly распознает как название правила.

В этом примере сразу происходят вычисления.

Подробнее можно прочитать в официальной документации: https://sly.readthedocs.io/en/latest/sly.html

4. Процесс создания

В самом начале программа получает yml файл с настройками. Затем при помощи sly преобразовывает код в древо классов. Далее выполняются вычисления и поиски объектов. После вычисления - передается в jinja2 шаблон и дерево символов.

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

Вначале определили, что модуль состоит из списка термов:

    @_('term term')    def term(self, p):        t0 = p.term0        t1 = p.term1        t0.extend(t1)        return t0

Затем определим, что терм состоит из определений структуры, энумератора или интерфейса разделенные символом ";"(SEPARATOR):

   @_('enum_def SEPARATOR')    def term(self, p):        return [p.enum_def]    @_('statement SEPARATOR')    def term(self, p):        return [p.statement]    @_('interface SEPARATOR')    def term(self, p):        return [p.interface]    @_('struct SEPARATOR')    def term(self, p):        return [p.struct]

Здесь терм сразу паковался в массив для удобства. Чтобы список термов (term term правило) работал уже сразу с листами и собрал в один лист.

Ниже представлен набор правил для описания структуры:

    @_('STRUCT NAME LBRACE struct_items RBRACE')    def struct(self, p):        return Struct(p.NAME, p.struct_items, lineno=p.lineno)    @_('decorator_item STRUCT NAME LBRACE struct_items RBRACE')    def struct(self, p):        return Struct(p.NAME, p.struct_items, lineno=p.lineno, tags=p.decorator_item)    @_('struct_items struct_items')    def struct_items(self, p):        si0 = p.struct_items0        si0.extend(p.struct_items1)        return si0    @_('type_def NAME SEPARATOR')    def struct_items(self, p):        return [StructField(p.type_def, p.NAME, lineno=p.lineno)]    @_('type_def NAME COLON NUMBER SEPARATOR')    def struct_items(self, p):        return [StructField(p.type_def, p.NAME, bitsize=p.NUMBER, lineno=p.lineno)]    @_('decorator_item type_def NAME SEPARATOR')    def struct_items(self, p):        return [StructField(p.type_def, p.NAME, lineno=p.lineno, tags=p.decorator_item)]    @_('decorator_item type_def NAME COLON NUMBER SEPARATOR')    def struct_items(self, p):        return [StructField(p.type_def, p.NAME, bitsize=p.NUMBER, lineno=p.lineno, tags=p.decorator_item)]

Если описать простым языком правила - структура (struct) содержит поля структур (struct_items). А поля структур могут определяться как:

  • тип (type_def), имя (NAME), разделитель (SEPARATOR)

  • тип (type_def), имя, двоеточие (COLON), число (NUMBER - для битфилда, означает количество бит), разделитель

  • список декораторов (decorator_item), тип, имя, разделитель

  • список декораторов, тип, имя, двоеточие (COLON), число (NUMBER - для битфилда), разделитель

Новшество относительно QFace (однако есть в protlr) - была введена возможность описывать специальные условные ссылки на структуры. Было решено назвать эту фичу - alias.

    @_('DECORATOR ALIAS NAME COLON expr struct SEPARATOR')    def term(self, p):        return [Alias(p.NAME, p.expr, p.struct), p.struct]

Это было сделано чтобы поддерживалась следующая конструкция:

enum Opcode {    Start =  0x00,    Stop = 0x01};@alias Payload: Opcode.Startstruct StartPayload {...};@alias Payload: Opcode.Stopstruct StopPayload {...};struct Message {    Opcode opcode: 8;    Payload<opcode> payload;};

Данная конструкция обозначает, что если opcode = Opcode.Start (0x00) - payload будет соответствовать структуре StartPayload. Если opcode = Opcode.Stop (0x01) - payload будет иметь структуру StopPayload. То есть создаем ссылку структуры с определенными условиями.

Следующее что было сделано - отказался от объявления модуля. Показалось это избыточным так как - имя файла уже содержит имя модуля, а версию писать бессмысленно так как есть git. Хороший протокол имеет прямую и обратную совместимость и в версии нуждаться не должен. Был выкинут тип flag так как есть enum, и добавил возможность описания битфилдов. Убрал возможность определения сигналов так как пока что низкоуровневого примера, демонстрирующего пользу, не было.

Была добавлена возможность python-подобных импортов. Чтобы можно было импортировать из другого модуля только конкретный символ. Это полезно для генерации документации.

Для вычислений был создан класс - Solvable. Его наследует каждый объект, которому есть что посчитать. Например, для SymbolType (тип поля класса или интерфейса). В данном классе этот метод ищет по ссылке тип, чтобы добавить его в поле reference. Чтобы в jinja можно было сразу на месте обратиться к полям enum или структуры. Класс Solvable должен искать во вложенных символах вычислимые и вызывать solve. Т.е. вычисления происходят рекурсивно.

Пример реализации метода solve для структуры:

    def solve(self, scopes: list):        scopes = scopes + [self]        for i in self.items:            if isinstance(i, Solvable):                i.solve(scopes=scopes)

Как видно, в методе solve есть аргумент - scopes. Этот аргумент отвечает за видимость символов. Пример использования:

struct SomeStruct {i32someNumber;@setter: someNumber;void setInteger(i32 integer);};

Как видно из примера - это позволяет производить поиск символа someNumber в области видимости структуры, вместо явного указания SomeStruct.someNumber.

Заключение

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

В папке examples/uart - находится пример генерации заголовков, кода и html документации. Пример иллюстрирует типичный uart протокол с применением новых фич. Подразумевается, что функции типа put_u32 итд - определит сам пользователь исходя из порядка байт и архитектуры MCU.

Ознакомиться подробнее с реализацией можно по ссылке: https://gitlab.com/volodyaleo/volk-idl

P.S.

Это моя первая статья на Хабр. Буду рад получить отзывы - интересна ли данная тематика или нет. Если у кого-то есть хорошие примеры кодо+доко-генераторов бинарных протоколов для Embedded, было бы интересно прочитать в комментариях. Или какая-то успешная практика внедрения похожих систем для описания бинарных протоколов.

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

Подробнее..

Батарейки больше не нужны. 5G сигналы как источник беспроводной энергии для IoT

25.04.2021 14:23:00 | Автор: admin

IoT уже вышли за пределы домов отдельно взятых людей и начали завоевывать города. От концепции умного дома мы перешли к умному городу. Интернет вещей или IoT для краткости это экосистема, состоящая из интеллектуальных устройств с подключением к Интернету, которые используют встроенные процессоры, датчики и коммуникационное оборудование для сбора, отправки и обработки данных, которые они получают из своей среды.
Интернет вещей приведёт к появлению большего количества взаимосвязанных умных городов, мест, управляемых данными в реальном времени. Города будут способствовать автономным транспортным средствам обмениваться данными с интеллектуальными устройствами людей, а их интеллектуальные устройства будут подключены к их домам, а их дома будут подключены к остальной части города, используя данные в реальном времени для улучшения качества жизни его жителей. К 2025 году планируется установить 40 миллиардов устройств IoT.

Чтобы Интернет вещей работал стабильно, нам нужен 5G. Это основа для реализации всего потенциала IoT. Но IoT это не только быстрая загрузка данных, высокоскоростная связь, низкая задержка трафика, но и повсеместное покрытие всей обслуживаемой территории сети. А так как дальность действия сигнала 5G от источника сигнала максимум сотни метров, то для покрытия сети понадобятся МНОГО-МНОГО антенн 5G. Группа учёных из Джорджии в целях экономии решили использовать такое изобилие антенн не только для подключения к сети девайсов IoT, но и для их электропитания. Нововведение может помочь устранить зависимость мира от аккумуляторов для зарядки устройств, предоставив альтернативу с использованием избыточной емкости 5G.



Незримый ЛЭП


5G был разработан для молниеносной связи с малой задержкой. Для этого были приняты частоты миллиметрового диапазона, что позволило Федеральной комиссии связи США достичь беспрецедентно высоких плотностей излучаемой мощности. Сами того не зная, архитекторы 5G создали таким образом беспроводную электросеть, способную питать устройства на дальностях, намного превышающих возможности любых существующих технологий. Однако этот потенциал может быть реализован только в том случае, если удастся обойти фундаментальный компромисс в области сбора беспроводной энергии.

Группа исследователей из Технологического института Джорджии разработала инновационную небольшую выпрямляющую антенну, напечатанную на 3D-принтере, которая может собирать электромагнитную энергию из сигналов 5G и использовать ее для питания устройств IoT.
Как говорят учёные, гибкая выпрямляющая антенна на основе линзы Ротмана, другими словами, ректенна, может выполнять сбор сигналов миллиметровой волны в диапазоне 28 ГГц. Линза Ротмана является ключевой для сетей формирования луча и часто используется в системах радиолокационного наблюдения, чтобы видеть цели в нескольких направлениях без физического перемещения антенной системы. Однако для получения энергии, достаточной для питания устройств, необходимы антенны большего размера, которые, к сожалению, имеют суженное поле зрения, и это ограничивает их использование.

Но чтобы собрать достаточно энергии для питания маломощных устройств на больших расстояниях, требуются антенны с большой апертурой. Проблема с большими антеннами в том, что у них сужается поле зрения. Это ограничение препятствует их работе, если антенна широко разнесена от базовой станции 5G.

Мы решили проблему возможности смотреть только с одного направления с помощью системы, которая имеет широкий угол обзора, говорит старший научный сотрудник Алин Эйд (Aline Eid) из лаборатории ATHENA, созданной в Школе электротехники и компьютерной инженерии Джорджии.


(a) Двойное комбинирование (RF + DC), обеспечиваемое использованием линзы Ротмана между антеннами и выпрямителями, (b) график смоделированных максимальных коэффициентов решетки и углового покрытия для линз Ротмана разных размеров и изображение изготовленная структура линзы Ротмана.

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

Благодаря этому нововведению мы можем получить большую антенну, которая работает на более высоких частотах и может принимать энергию с любого направления. Он не зависит от направления, что делает его более практичным, отметил Джимми Хестер (Jimmy Hester), старший советник лаборатории, технический директор и соучредитель Atheraxon, дочернего предприятия Технологического института Джорджии, разрабатывающего технологию радиочастотной идентификации (RFID) 5G.

Вся электромагнитная энергия, собираемая антенными решётками с одного направления, объединяется и подается в один выпрямитель, что увеличивает его эффективность.


(a) График смоделированных и измеренных коэффициентов отражения на выходе луча 4 в плоских и изогнутых условиях и (b) Графики максимальных коэффициентов решетки и угловых направлений отверстий P1, P3 и P5 луча в зависимости от частоты.

Все дело в физике


Люди прежде уже пытались собирать энергию на высоких частотах, таких как 24 или 35 гигагерц, говорит Эйд. Но такие антенны работали только в том случае, если они находились в прямой видимости от базовой станции 5G. До сих пор не было возможности увеличить угол обзора.

Работая так же, как оптическая линза, линза Ротмана обеспечивает одновременно шесть полей зрения в виде формы паука. Изменение формы линзы приводит к изменению угла кривизны со стороны порта луча и со стороны антенны. Это позволяет структуре отображать набор выбранных направлений излучения на связанный набор портов луча. Затем линза используется в качестве промежуточного компонента между приёмными антеннами и выпрямителями для сбора энергии 5G.


(a) Схема суммирования мощности на основе линз Ротмана и (b) изображение установки, используемой для измерения угловой характеристики ректенны.

К конструкции добавляются антенные подрешётки, выпрямители и сумматоры постоянного тока, чтобы продемонстрировать сочетание большого углового покрытия и чувствительности к включению как в плоских, так и в изогнутых условиях и возможность сбора на расстоянии до 2,83 м в тестовом состоянии и свыше 180 м с использованием современных выпрямителей (позволяющих собирать мощность постоянного тока в 6 мкВт при 75 дБм).

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

На демонстрациях технология позволила добиться 21-кратного увеличения собираемой мощности по сравнению с аналогами при сохранении идентичного углового покрытия.


(a) Изображение гибкой ректенны на основе линзы Ротмана, помещенной в цилиндр радиусом 1,5 дюйма, (b) измеренная суммарная мощность в зависимости от углов падения для разной кривизны, установка для испытаний на дальние расстояния.

Эта надёжная система может открыть дверь для новых пассивных RFID-меток большого радиуса действия с питанием от 5G миллиметрового диапазона для носимых и повсеместных приложений IoT. Исследователи использовали собственное аддитивное производство для печати харвестеров миллиметрового диапазона размером с ладонь на множестве повседневных гибких и жестких подложек. Возможность 3D-печати сделает систему более доступной для широкого круга пользователей.

Дело в том, что 5G будет везде, особенно в городских районах. Вы можете заменить миллионы или десятки миллионов батарей беспроводных датчиков, особенно для умных городов и умных приложений , говорит Эммануил Тенцерис (Emmanouil Tentzeris), профессор электроники в Школе электротехники и компьютерной инженерии.

Тенцерис предсказывает, что следующим крупным приложением для телекоммуникационной отрасли станет технология Powera-as-a-Service (PaaS), точно так же, как передача данных вытеснила голосовые звонки в качестве основного источника дохода.

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


Эта работа была поддержана Исследовательской лабораторией ВВС США и Национальным научным фондом (NSF) программа Emerging Frontiers in Research and Innovation. Работа была частично выполнена в Технологическом институте электроники и нанотехнологий Джорджии, который входит в Национальную координированную инфраструктуру нанотехнологий (NNCI), которая поддерживается NSF (грант ECCS-1542174).





На правах рекламы


Воплощайте любые идеи и проекты с помощью наших VDS с мгновенной активацией на Linux или Windows. Сервер готов к работе через минуту после оплаты!

Подробнее..

Recovery mode Вебинар Создавайте больше деталей за меньшее время, отслеживая полезное время работы станков

26.01.2021 18:12:26 | Автор: admin

Приглашаем всех желающих посетить бесплатный вебинар. Мероприятие пройдет 2 февраля в 11:00 по московскому времени.

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

Что вы узнаете на вебинаре:

  • Как система мониторинга может защитить ваши инвестиции и повысить время полезной работы оборудования

  • Как сократить машинное время, сохранив количество и качество выпускаемой продукции

  • Как опыт использования мониторинга станков повлиял на компании: ЗАО РЗЗ, ПАО Дальприбор, ТОО Казцинк

  • Наш опыт решения проблем на производстве: онлайн-подключение к действующему заводу

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

Регистрация: https://winnum.timepad.ru/event/1538757/

Подробнее..

Перевод Почему Qualcomm стремится к доминированию на рынке мониторинга водителей (DMS)

02.02.2021 08:07:36 | Автор: admin
image

На CES 2021 стало ясно, что салонные системы ИИ становятся трендом в автомобильной индустрии. Такое положение дел серьезно повлияет на рынок систем мониторинга водителей и Qualcomm стремится к доминированию на этом рынке.

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

Я выделила четыре стратегии развития автомобильных систем мониторинга водителей: цифровые панели/информационно-развлекательные системы, помощь водителям при езде по трассам, выход на китайский рынок и сотрудничество с NCAP. Это первая из двух статей, в которых я расскажу о каждой из этих стратегий, предложу свои оценки процесса разработки, опишу ключевые проблемы и представлю ключевых поставщиков решений на этом рынке.

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

Цифровая панель/информационно-развлекательная система


image

Цифровые панели и информационно-развлекательные системы станут сердцем революционных решений для салонных систем ИИ, которые вот-вот обрушатся на автомобильную промышленность. Грядет захватывающая битва между Qualcomm и Nvidia за создание пользовательского интерфейса, который к середине десятилетия станет стандартам для всех автопроизводителей. Представьте, что все, что вам нравилось в интерфейсе смартфонов (насыщенные контентом экраны высокой четкости) будет встроено в ваш автомобиль. Наконец-то.

Накул Дуггал поведал о масштабах автомобильной экосистемы от Qualcomm во время своей презентации на Reuters Automotive Summit. Вы можете посмотреть презентацию полностью, а вот скриншот с ключевой информацией.

image

На этом слайде представлены почти все Tier-1 производителеи, продукты которых используются в салонных и автомобильных решениях: Alps Alpine, Aptiv, Bosch, Continental, Denso, Garmin, Harman, LG, Mobis, Panasonic и Visteon.

Справа мы также можем увидеть, что Qualcomm сотрудничает с Amazon и Google почти наверняка с целью интеграции Alexa Auto и Android Automotive OS. Также Qualcomm сотрудничает с Blackberry для интеграции платформы QNX Car в свои информационно-развлекательные системы.

Компания Seeing Machines представлена как эксклюзивный поставщик систем мониторинга водителя для автомобильных решений от Qualcomm. Думаю, причина этого партнерства явное лидерство Seeing Machines в области автомобильных систем мониторинга водителей. Seeing Machines добилась заметного прогресса в работе над надежностью оптики и доказала качество своих алгоритмов компьютерного зрения, начав с наименее гостеприимной транспортной области: грузовых автомобилей в горнодобывающей промышленности.

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

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

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

Автопроизводители, которые хотят конкурировать с Tesla, будут сотрудничать с Nvidia, а автопроизводители, которые хотят продвинуться в работе над цифровыми панелями будут работать с Qualcomm. Intel снова упустила ключевой технологический поворот и не имеет жизнеспособной стратегии для рынка автомобильных систем мониторинга водителей.

У Seeing Machines есть очень хорошие возможности для захвата рынка цифровых панелей и рынка автомобильных систем к середине десятилетия. Исключением станут автомобили на базе системы Cerence Look от Nvidia и с системой отслеживания направления взгляда от Smart Eye. Одним из таких автомобилей станет грядущий флагман EQS от Mercedes-Benz. Думаю, в будущем умных автомобилей только одна компания захватит лидерство и станет поставщиком систем мониторинга водителей.

Помощь при езде по трассам


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



Представленная еще в 2017, система Super Cruise от Cadillac стала первым примером решения, оказывающего помощь при езде по трассам. Super Cruise позволяет эффективно отслеживать состояние водителя с помощью видеорегистратора и ПО от Seeing Machines.

В 2021 году BMW, похоже, собирается выпустить новое поколение своей системы автоматизации езды в новой модели iX. Ford готовится представить Active Drive Assist в F-150 и Mustang Mach-3, а Mercedes-Benz будет встраивать свое аналогичное решение в новый S-Class. Мои исследования показывают, что все три автопроизводителя последовали примеру Cadillac и сотрудничали с Seeing Machines.

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

Такое положение дел на рынке привело к появлению терминов вроде Уровень 2+, Уровень 2++, Уровень 3- и даже Уровень 2.99, поскольку автопроизводители отказываются от автомобильных систем выше второго уровня и ниже третьего и стремятся делать упор на отличия своих продуктов от конкурирующих.

image

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

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

Mobileye быстро придет к пониманию последствий того, что компания сосредоточила усилия на беспилотной езде, картографировании (REM), стилях вождения (RSS), FMCW-лидарах и умном радаре и упустила тренд систем мониторинга водителей. Qualcomm, для сравнения, заметила этот тренд и реагирует на него возможно, благодаря сотрудничеству с Veoneer.

Intel вот-вот узнает, что даже за 15.3 миллиарда долларов можно купить компанию с близорукой продуктовой стратегией. Думаю, им будет обидно осознавать, что в 2017 году можно было за несколько миллионов долларов купить Seeing Machines. Судьба Амнона Шашуа, генерального директора Mobileye, зависит от реализации обещания по созданию потребительских систем беспилотной езды к 2025 году я к этому отношусь довольно скептически.

Судя по всему, к середине десятилетия Seeing Machines будет доминировать на рынке систем мониторинга водителей в сегменте помощи при езде по трассам благодаря техническому превосходству над такими конкурентами как Cipia (ранее Eyesight), Jungo, Mitsubishi, Smart Eye и Xperi. Превосходство Seeing Machines проявляется в оптике, исследованиях человеческого фактора и захвате надежных и стабильных сигналов в поведении водителей.

Новый взгляд на автомобильную промышленность


image

Технологическая презентация Qualcomm под названием Automotive Redifined (Новый взгляд на автомобильную промышленность) состоится 26-27 января. На ней выступит Накул Дуггал, который руководит автомобильным бизнесом Qualcomm с сентября вместе с президентом и новым генеральным директором компании Криштиану Амоном, возглавившим процесс перехода Qualcomm от сотовой связи к автомобильной промышленности.

Я жду невероятных новостей с этого мероприятия. Как показал декабрьский саммит по Snapdragon, Qualcomm любит привлекать партнеров и клиентов крупными объявлениями, поэтому я ожидаю появления генерального директора Veoneer Яна Карлсона и официального запуска партнерства Qualcomm и Veoneer.

Также мы можем увидеть генерального директора GM Мэри Барру, воодушевленную ее недавним прекрасным выступлением на CES (в нем много говорится о создании электромобилей и экологических проблемах и очень мало об электронике и технологиях).

Хоть прогнозы и бывают либо удачными, либо неверными, я хочу предсказать, что GM может стать первым автопроизводителем, который примет решения от Qualcomm и Veoneer в качестве основы для Ultra Cruise. Также GM планирует начать работу с Google Android Automotive OS и положит начало тренду по внедрению цифровых панелей в салоны.

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




image

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

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

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

Если вам интересно попробовать свои силы в решении тех задач, которые у нас есть, пишите в личку.



О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru