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

Драйвер шагового двигателя. Тестируем микросхему L9110

Из песочницы

Откуда «ножки» растут

В настоящее время стали доступны и приобрели популярность различные станки с программным управлением. Это лазерные и фрезерные резчики и гравёры. А так же 3D принтеры. Все эти станки имеют один общий узел — шаговый двигатель.
И этому двигателю нужен драйвер.
Принцип работы двигателя не является предметом этой статьи. Мы рассмотрим только драйвер. Всё, что нам нужно знать в данном контексте — это какие управляющие сигналы нам нужно формировать для управления шаговым двигателем. Оказывается, это самые обычные прямоугольные импульсы.
Существует некоторое количество решений драйверов от различных компаний. В нашей статье мы рассмотрим самое доступное решение драйвера L9110 и его аналог HG7881 Это решение часто используется в Arduino

Теория и практика

Я решил применить микросхему L9110 в своём проекте.Довольно легко нагуглил datasheet. Прочитал. Всё предельно понятно. Характеристики, распиновка, таблица истинности… По всем параметрам драйвер, вроде бы подходит. Напряжение коммутации — 12 вольт, выходной ток 800 ма. — всего хватает.

Как мы научились подключать китайские камеры за 1000р к облаку. Без регистраторов и SMS (и сэкономили миллионы долларов)

Всем привет!

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

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

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

Для этого необходимо, чтобы на камере был установлен модуль ПО работающий с облаком. Однако, если говорить про дешевые камеры, то у них очень ограничены аппаратные ресурсы, которые почти на 100% занимает родная прошивка вендора камеры, а ресурсов необходимых для облачного плагина — нет. Этой проблеме разработчики из ivideon посвятили статью, в которой говорится почему они не могут установить плагин на дешевые камеры. Как итог, минимальная цена камеры — 5000р ($80 долларов) и миллионы потраченных денег на оборудование.

Мы эту проблему успешно решили. Если интересно как — велком под кат

Пайка в домашних условиях: запись стрима

Недавно мы провели двухчасовой стрим «пайки в домашних условиях»: разработчик аппаратной части Яндекс.Станции Геннадий «Крэйл» Круглов продемонстрировал, как он паяет в домашней лаборатории. Гена показал устройства в лаборатории и сам процесс пайки, а в перерывах ответил на десятки вопросов от зрителей. Вот запись стрима:

Гена разрабатывает электронику с 2002 года. За это время он поучаствовал более чем в двухстах железных проектах и начал преподавать в МГТУ им. Баумана. Сейчас он читает там два курса: «Цифровая обработка сигналов» и «Микропроцессоры и цифровые устройства». В Яндексе Гена с 2015-го.

Хождение по граблям в чистом поле или как собрать MAC-адреса близлежащих Wi-Fi-устройств

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

Go vs Javascript. На чем писать IoT проекты

Из песочницы

Какой язык программирования лучше для вашего IoT проекта? Ответ на этот вопрос неоднозначный и субъективный. Есть несколько аспектов, которые необходимо учитывать при рассмотрении этого вопроса: задачи, цели и потребности вашего проекта. Важную роль также играют ваши личные предпочтения, наличие и возможности квалифицированных разработчиков.
Существует мнение, что разработанный Google язык Golang, может в конечном итоге вытеснить JavaScript (или, лучше сказать, Node.js) из сферы IoT приложений. Правда ли суслик может победить в этой битве? Давайте подробнее рассмотрим, как Golang, так и JS, их преимущества и недостатки для IoT решений.

Архитектура IoT-сценария

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

• Сервис Yandex IoT Core представляет собой мультитенантный отказоустойчивый масштабируемой MQTT-брокер с набором дополнительных полезных функций.
• Сервис Yandex Cloud Functions является представителем перспективного направления serverless и позволяет запускать ваш код в виде функции в безопасном, отказоустойчивом и автоматически масштабируемом окружении без создания и обслуживания виртуальных машин.
• Yandex Object Storage — это эффективное хранилище больших массивов данных и очень хорошо подходит для «исторических» архивных записей.
• В Облаке существует целое семейство сервисов для хранения и анализа данных, практически на любой вкус, но я хочу отметить сервис Yandex Managed Service for ClickHouse, как один из примеров «управляемых» баз данных. Это сервис для развёртывания и управления «колоночной» базой данных с открытым исходным кодом, имеющим встроенную функциональность работы с временными рядами, что актуально для оперативных данных, на базе которых обычно и нужно проводить большую часть анализа и строить отчёты.

Управление Tion S3 и его подключение к умному дому

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

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

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

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

Полный цикл создания устройства и работа с фабриками в Китае. Доклад Яндекса

Меня зовут Андрей Холодный. Весь мой опыт связан с телекомом: я работал практически во всех крупных провайдерах связи и даже руководил своим стартапом. На моих проектах регулярно возникали задачи разработки и выбора поставщиков роутеров и ТВ-приставок. С конца 2018 года я применяю этот опыт в Яндексе: руковожу командой, которая координирует разработку и производство устройств с Алисой.
Под катом — конспект моего недавнего доклада. В нем два больших блока: про этапы разработки устройства и про общение с фабриками в Китае. Надеюсь, конспект будет полезен тем, кто начинает думать о производстве собственных устройств.

История появления «интернета вещей»

Появление IoT было предсказано за долго до XXI века. Еще в начале прошлого столетия Никола Тесла предполагал, что радиоволны будут выполнять функцию нейронов «мозга», которые управляет всеми предметами на нашей планете. Тесла считал, что инструменты управления этими предметами будут легко помещаться в кармане брюк. Если раньше Теслу кто-то считал фантастом, то он глубоко ошибался. Великий физик понимал то, о чем его современники не могли даже фантазировать.

Пророчества Теслы сбылись в конце прошлого века. Британский ученый Кевин Эштон придумал термин «интернет вещей». Именно он первым предложил повысить эффективность логистических операций без посредничества человека.

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

Концепция IoT основана на принципе М2М. Это означает, что электронные устройства могут «общаться» друг с другом без посредничества человека. IoT – это автоматизация наивысшего уровня. В IoT для обмена информацией через интернет используются TCP/IP-протоколы.

Этот метод коммуникации обеспечивает существенное преимущество – все системы могут быть объединены в одну сеть. За счет этого появилась возможность видоизменять бизнес-процессы целых отраслей экономики. Более того, такой метод можно использовать даже в масштабах государства.
IoT способствует формированию экономики «совместного потребления». Таким образом, из деловых, бытовых и производственных процессов исключаются любые посредники.

После появления концепции интернет вещей прошло всего 20 лет. Тем не менее эта концепция уже сегодня является главным трендом IT-рынка. В ближайшие несколько лет ожидается существенное увеличение числа интернет вещей. По прогнозам аналитиков, к 2030 году их количество превысит отметку в 50 миллиардов. Этому поспособствует появление новых технологий, которые позволяют поставить на конвейер производство миллионов недорогих чипов для самых разных устройств. За счет этого глобальная «интернетизации» окружающих предметов уже не воспринимается нами, как нечто неординарное.

Мониторинг производственного оборудования: как с этим дела в России

Recovery Mode

Привет, Хабр! Наша команда занимается мониторингом станков и разных установок по всей стране. По сути, мы обеспечиваем возможность производителю не гонять лишний раз инженера, когда «ой, оно всё сломалось», а на деле надо нажать одну кнопку. Или когда сломалось не на оборудовании, а рядом.
Базовая проблема следующая. Вот вы производите установку для крекинга нефти, либо станок для машиностроения, либо какое-то другое устройство для завода. Как правило, продажа сама по себе крайне редко возможна: обычно это контракт на поставку и обслуживание. То есть вы гарантируете, что железяка будет работать лет 10 без перебоев, а за перебои отвечаете либо финансово, либо обеспечиваете жёсткие SLA, либо что-то подобное.
По факту это означает, что вам нужно регулярно отправлять инженера на объект. Как показывает наша практика, от 30 до 80 % выездов — лишние. Первый случай — можно было бы разобраться, что случилось, удалённо. Либо попросить оператора нажать пару кнопок — и всё заработает. Второй случай — «серые» схемы. Это когда инженер выезжает, ставит в регламент замену или сложные работы, а сам делит компенсацию пополам с кем-то с завода. Или просто наслаждается отдыхом с любовницей (реальный случай) и поэтому любит выезжать почаще. Завод не против.
Установка мониторинга требует модификации железа устройством передачи данных, самой передачи, какого-то озера данных для их накопления, разбора протоколов и среды обработки с возможностью всё посмотреть и сопоставить. Ну и с этим всем есть нюансы.

Визуализация данных для беспилотного транспорта с открытым исходным кодом от Uber

Перевод

Uber надеются создать стандартную систему визуализации для работы инженеров в области разработки беспилотных транспортных средств на основе открытой версии своей системы.
В то время как Uber не скрывает своих амбиций в отношении беспилотных автомобилей, компания по продаже поездок спокойно продвигается вперед в разработке новых технологий для отрасли. Последняя — это новая, открытая версия системы визуализации беспилотного транспорта (AVS), которая позволит разработчикам и инженерам обмениваться данными об беспилотных транспортных средствах в понятной и стандартизированной форме.«Понимание того, что беспилотные транспортные средства видят во время навигации в городской среде, необходимо для разработки систем, которые заставят их работать безопасно», — пишут в своем блоге инженеры Убера Сяодзи Чэнь, Джозеф Лизи, Тим Войташек и Абхишек Гупта. «И точно так же, как мы используем стандартные уличные знаки и дорожную инфраструктуру для помощи водителям, разработчики беспилотных транспортных средств будут хорошо обеспечены стандартной платформой визуализации, которая будет представлять входные данные от датчиков, классифицировать изображения, выводить информацию о движении и использовать все другие методы, используемые для создания точного изображения ближайшего пространства.»

IoT там, где вы не ждали (часть 3). Построение имитационной модели

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

Windows 10 IoT Enterprise — секреты настройки для Embedded-сценариев

Предисловие

Наверно Вы видели банкоматы, информационные киоски, рекламные панели, на которых отображается ошибка или уведомление системы. Если Вы не видели подобные общественные устройства «живьем», то Вы легко сможете найти подобные фотографии в интернете если поищете картинки по словам «банкомат ошибка windows». А однажды уведомление системы появилось в прямом эфире во время прогноза погоды, фото можно найти по словам «уведомление windows в прямом эфире». Ради интереса еще можете поискать «самый большой синий экран».

О чем же все это говорит?

— Вы любите кошек?
— Нет
— Вы просто не умеете их готовить!
Для специализированных устройств Майкрософт предлагает использовать Windows 10 IoT Enterprise, которая отличается от Windows 10 Enterprise только отсутствием универсальных приложений. Соответственно, с технической точки зрения Win 10 IoT Enterprise является настольной операционной системой, которая подразумевает взаимодействие с пользователем. Но на специализированных устройствах взаимодействия с пользователем не должно быть т.к. порой даже нет пользователя в привычном его понимании, особенно это касается рекламных панелей.

Режимы сохранения энергии в NB-IoT

Устройствам, которые работают от батарейки, важно потреблять как можно меньше энергии. Для этого в NB-IoT предусмотрены два режима энергосбережения: Power Saving Mode, PSM и Extended idle mode DRX, eDRX

Рассмотрим их подробнее.

Режим сохранения энергии PSM, Power Saving Mode

Согласно спецификации 3GPP TS 23.682, Power Saving Mode (PSM) – это режим, аналогичный отключению питания, при котором устройство, тем не менее, остается зарегистрированным в сети. Любопытно, что режим PSM появился в спецификациях 3GPP раньше, чем NB-IoT – в 3GPP Release 12.

Устройство NB-IoT инициирует режим PSM, включая значения двух таймеров в запросы ATTACH REQUEST/TAU REQUEST, посылаемые в процедурах Attach и TAU (TAU, Tracking Area Update — это периодическая процедура, которая используется в LTE для уведомления сети о доступности и местоположении мобильного устройства).

Первый таймер — T3324 Active Timer — определяет время, в течение которого устройство остается доступным со стороны сети после процедуры Attach, TAU или передачи данных.

Второй таймер — T3412 Extended periodic TAU Timer — определяет период процедуры TAU.

Режим PSM и таймеры T3324, T3412 показаны на рис. 1:

Если сеть разрешает использование режима PSM, то значения этих таймеров включаются в ответные сообщения ATTACH ACCEPT/TAU ACCEPT

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

Зато устройство обязано применить значения, полученные от сети.

Длительность нахождения устройства в режиме PSM определяется как разница между Extended periodic TAU Timer и Active Timer (T3412-T3324). Так как значение T3324 Active Timer может быть равно нулю, то максимальное теоретическое время нахождения устройства в режиме PSM равняется максимальному времени T3412 Extended periodic TAU Timer и составляет 413 дней и 8 часов (!!!). Максимальное значение T3324 Active Timer составляет 3 часа и 6 минут (186 минут).

Когда устройство находится в режиме PSM, оно недоступно со стороны сети (для так называемых mobile terminating сервисов).

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

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

Режим сохранения энергии eDRX (Extended idle mode DRX)

eDRX (Extended idle mode DRX) можно считать дополнительным режимом энергосбережения устройства, он появился в спецификациях 3GPP Release 13. DRX означает прерывистый приём (Discontinuous Receiving). Метод прерывистого приема известен в сотовой связи давно, и заключается в том, что для сохранения энергии приемный тракт устройства включается периодически в определенные промежутки времени, а большую часть времени отключен. Сеть «знает» об этом и посылает сигналы вызова (paging) только в «правильные» моменты времени. Расширенный режим прерывистого приёма (eDRX) позволяет существенно увеличить период времени, когда приемный тракт устройства выключен. Согласно спецификации 3GPP TS 23.682, период прерывистого приема eDRX в режиме NB-IoT составляет от 20,48 до 10485,76 секунды (10485 секунд — это почти 3 часа).

Сравнение «старого» DRX и «нового» eDRX представлено на рис. 2:

Устройство NB-IoT активирует режим eDRX, передавая значение длительности периода eDRX в запросах ATTACH REQUEST/TAU REQUEST, посылаемых в процедурах Attach и TAU. Если сеть разрешает использование режима eDRX, то значение периода eDRX включается в ответные сообщения ATTACH ACCEPT/TAU ACCEPT. Сеть не обязана подтверждать запрошенное устройством значение периода eDRX, а вот устройство обязано применить значение, переданное сетью.

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

Режим eDRX может применяться одновременно с режимом PSM.

Режимы PSM и eDRX входят в число минимальных требований к сетям NB-IoT, рекомендованных GSMA.

Когда написать свою IoT-платформу выгоднее, чем покупать готовую

Привет!
В конце апреля я рассказал вам про наши датчики и упомянул специальную IoT-платформу, на которой они работают. Пришло время рассказать об этом подробнее.
Платформа нужна для того, чтобы обеспечить управление устройствами IoT-сети всех уровней и съем данных с датчиков, хранение этой информации и её дальнейшую обработку. Да, на рынке сейчас достаточно подобных платформ, но они не готовы решать задачу «из коробки». Это или какие-то отдельные куски бэкенда, которые полезные и нам бы пригодились в работе, или такие же полезные куски фронтенда, но такого, чтобы все сразу и прямо из коробки — нету. Даже самая близкая к нашим потребностям платформа требовала довольно серьезного допиливания и найма в штат новых разработчиков исключительно под эти задачи.
Мы сели, посчитали total cost of ownership и другие плюсы и минусы использования ведущих платных платформ, сравнили это с возможностью пойти и написать свою платформу. И получилось, что сделать свою для нас — примерно в два раза дешевле, при этом платформа будет полностью соответствовать стеку технологий, принятых в SIBUR Digital.

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

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

1. Бекенд игровых сущностей, которые отвечали за игровые механизмы
2. Шина обмена данных бекенда и площадки на VPS
3. Транслятор из запросов бекенда (игровых элементов) на ардуино и железо на площадке
4. Ардуино, которая занималась управлением релешками, получала команды с транслятора и делала фактическую работу
5. Фактические устройства: вентилятор, гирлянды, торшеры и прочее
6. Фронтенд — сам сайт Сокола, с которого игроки управляли устройствами

Давайте пройдёмся по каждой из них.