Привет, Хабр!

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


Тема это большая и сложная, но я постараюсь выделить основные моменты — не в последнюю очередь на основании ошибок, которые я видел во всевозможных реальных устройствах и проектах, в том числе публиковавшихся на Хабре. Я не буду долго и нудно перечислять ГОСТы, но перечислю совсем базовые вещи, которые необходимо понимать и соблюдать, чтобы не убить хотя бы себя (если вы планируете не убивать также и окружающих, то после завершения этой статьи не поленитесь пролистать и релевантные ГОСТы).

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

Привет, Хабр. Под этим пафосным заголовком я бы хотел поговорить о том, что такое «инженерная наука», в чём состоит главная обязанность инженера и что бывает, если он с ней не справляется — мне кажется, в последнее время эта тема становится всё более актуальной, при этом её публичного обсуждения я не вижу.

Сподвигла меня на это разразившаяся (при моём активном участии) в минувшие выходные история с «нейроинтерфейсами» компании Bitronics Lab — детскими учебными наборами для снятия ЭЭГ и мышечной активности, которые при ближайшем рассмотрении оказались попросту небезопасны в использовании из-за несоблюдения их производителем базовых требований к электробезопасности медицинского оборудования.

История это очень показательна в том, что она демонстрирует, как по мере роста сложности система, составленная из кажущихся её авторам безопасными компонентов, становится опасной — причём на примере системы простой, бытовой и интуитивно понятной, а не атомного реактора или реактивного лайнера, которые любят брать в качестве примеров авторы книг вроде моей любимой "Inviting Disaster".

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

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



Казалось бы, что может пойти не так?

Короткая, но важная для причастных к IoT новость: ГКРЧ официально расширила безлицензионный диапазон 868 МГц, в котором традиционно живут такие сети, как LoRaWAN, Стриж/Вавиот, Sigfox и другие.

Официально это называется «неспециализированные устройства малого радиуса общего применения», а закреплены изменения в Приложении 12 к Решению ГКРЧ № 18-46-03-1 от 11 сентября 2018 года.

Было:

• 864,0 — 865,0 МГц — мощность до 25 мВт, рабочий цикл до 0,1 % или LBT*, запрещено использование на территории аэропортов
• 868,7 — 869,2 МГц — мощность до 25 мВт, рабочий цикл без ограничений, использование без ограничений

Стало (жирным выделены изменения):

• 864,0 — 865,0 МГц — мощность до 25 мВт, рабочий цикл до 0,1 % или LBT*, запрещено использование на территории аэропортов
• 866,0 — 868,0 МГц — мощность до 25 мВт, рабочий цикл до 1 % или LBT*, запрещено использование на территории аэропортов, спектральная плотность мощности до 1000 мВт/МГц
• 868,7 — 869,2 МГц — мощность до 100 мВт, рабочий цикл до 10 % или LBT*, использование без ограничений

* Listen Before Talk. Что это означает, правда, никто не знает, так как в российских НПА техническая суть LBT нигде не расшифровывается. Да и, собственно, никто его и не использует.

Что это означает конкретно для сетей LoRaWAN?

Привет, Хабр.

Традиционным уникальным преимуществом платформы Arduino называлось (да и сейчас иногда называется, хотя это уже неверно — и мы поговорим, почему) опускание порога входа в микроконтроллерную разработку до уровня базовых знаний C/C++ и электроники в маштабе «подключить светодиод в нужной полярности».

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

Заслуги Arduino в снижении порога вхождения действительно трудно переоценить — эта платформа появилась на свет в середине нулевых годов, а после 2010 завоевала серьёзную популярность среди любителей. Особых альтернатив на тот момент ей не было — процессоры на ядрах Cortex-M только появились, по сравнению с AVR они были довольно сложны даже для профессиональных разработчиков, а отладочные платы у большинства вендоров стоили от сотни долларов и выше (и в общем в индустрии ценник за отладку на 5-долларовом контроллере в $500 никого сильно не удивлял).

Однако большая проблема Arduino в том, что её развитие за минувшие 10+ лет более всего напоминает некоторые модели АвтоВАЗа:


Так как дальше я планирую длинное вступление, то сейчас, чтобы вы представляли, в чём будет заключаться практическая часть, я приведу полный текст программы, включающий инициализацию процессора STM32 и мигание светодиодом. Программа написана для ОС ARM Mbed:

#include "mbed.h"
DigitalOut myled(LED1);

int main() {
    while(1) {
        myled = 1; // LED is ON
        wait(0.2); // 200 ms
        myled = 0; // LED is OFF
        wait(1.0); // 1 sec
    }
}

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

Конспект первой лекции по программированию современных микроконтроллеров на примере STM32 и операционной системы RIOT. Лекции читаются в Институте информационных технологий МИРЭА по субботам, с 12:50 в актовом зале на 4 этаже корпуса Д. В занятиях отводится 1,5 часа на саму лекцию и 3 часа на практические занятия в лаборатории IoT Академии Samsung по теме лекции.

Привет, Гиктаймс! Как мы и обещали, начинаем публикацию конспектов лекций, которые сейчас читаются в Институте ИТ МИРЭА. По результатам первой, вводной лекции мы решили немного изменить структуру курса — вместо планировавшихся двух потоков по 5 занятий будет один поток на 7 занятий. Это позволит в более спокойном темпе разобрать ряд вспомогательных вопросов, а также статьи с конспектом будут появляться на GT каждую неделю в течение всего марта и апреля, а не через неделю, как планировалось раньше.

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

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

Цель курса — освоение навыков, позволяющих свободно работать с микроконтроллерами на ядре ARM Cortex-M на современном уровне и, при наличии такого желания, двигаться в сторону дальнейшего углубления своих знаний.



Сегодняшняя лекция — первая, поэтому на ней будут разбираться общие понятия: что такое вообще микроконтроллер и зачем он нужен, что такое прошивка и как она получается, зачем нам нужна операционная система, и наконец — как работать с git. Результат практического занятия — собственный репозитарий на GitHub с исходными кодами ОС, а также успешно настроенная среда сборки на локальном компьютере.

Привет, Гиктаймс! Этим полукреслом мастер Гамбс… Этим постом мы — проект IoT Академия Samsung и компания Unwired Devices — начинаем цикл публикаций по мотивам нового практического курса по программированию микроконтроллеров на ядре Cortex-M3, который с завтрашнего дня будет читаться в Институте Информационных Технологий Московского Технологического Университета (также известного как МИРЭА).

Цель курса — познакомить студентов с современными микроконтроллерами на ядре Cortex-M3 и дать им базовые навыки программирования под них на языке C под операционной системой. Требования к слушателям — знакомство с языком C (не обязательно на микроконтроллерах) и базовое понимание электроники (на уровне умения подключить светодиод).



Изначально программа IoT Академии задумывалась как достаточно высокоуровневая — студенты должны работать с готовыми модулями передачи данных для сетей LoRa и 6LoWPAN, в которые уже были загружены прошивки с поддержкой нужных датчиков и необходимой логикой работы с ними. Фактически, курс заключается в настройке этих модулей и написании высокоуровневого ПО для обработки приходящих данных на платформе Samsung Artik + Tizen.

Однако, как показала практика, многим студентам интересно более серьёзно углубиться в то, что происходит внутри микроконтроллеров. При этом на данный момент с обучающими курсами по контроллерам Cortex-M в паре с операционными системами всё обстоит достаточно плохо: по сути, девять из десяти таких курсов посвящены написанию несложного приложения с использованием StdPeriphLib и/или CubeMX, причём половина текста приходится на вопросы инициализации контроллера и его периферии.

Часть первая: Meltdown
Часть вторая: Spectre

Одним из самых интересных вопросов, возникших в дискуссиях об аппаратных уязвимостях Meltdown и Spectre (см. ссылки выше) был вопрос о том, сделал ли нам Дед Мороз этот подарок в связи с тем, что в 2017 году мы вели себя плохо — или, наоборот, хорошо.



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

Часть первая: Meltdown.

Несмотря на всю мощь уязвимости Meltdown, принесённое этим Новым годом счастье не было бы полным, если бы не вторая часть открытия, не ограничивающаяся процессорами Intel — Spectre.

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

Строго говоря, Spectre не является одной уязвимостью — уже на старте заявлены два различных механизма (CVE-2017-5753 и CVE-2017-5715), а авторы отмечают, что может быть ещё и много менее очевидных вариантов.

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

Да, я знаю, что это уже третий материал на GT/HH по данной проблеме.

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

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

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

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

Третья из серии статей, посвящённая описанию основных отличий технологий маломощной дальнобойной радиосвязи, получающей сейчас распространение в системах Интернета вещей: широкополосной связи LoRa от узкополосных (UNB, Ultra Narrow Band) систем, таких как Sigfox и «Стриж», а также вопросам их практического применения.

• Связь в интернете вещей: LoRa против UNB. Часть 1: физика
• Связь в интернете вещей: LoRa против UNB. Часть 2: бизнес
• Связь в интернете вещей: LoRa против UNB. Часть 3: технические тонкости
• Связь в интернете вещей: LoRa против UNB. Часть 4: сети и оборудование LoRa

Привет, GT.

После первых двух статей, а также живых рассказов по данной теме меня несколько раз просили подробнее рассказать о базовых технических аспектах работы LoRa и UNB-сетей несколько подробнее, чем я рассказывал в первой статье:

• Разделение каналов в UNB-системах
• Проблема обратной связи в UNB-системах
• Разделение каналов в LoRa
• Адаптивные скорости в UNB и LoRa
• Помехозащищенность в UNB-системах и в LoRa

Что ж, приступим. Ниже будет, как обычно, много текста и мало картинок.

Вторая из серии статей, посвящённая описанию основных отличий технологий маломощной дальнобойной радиосвязи, получающей сейчас распространение в системах Интернета вещей: широкополосной связи LoRa от узкополосных (UNB, Ultra Narrow Band) систем, таких как Sigfox и «Стриж», а также вопросам их практического применения.

• Связь в интернете вещей: LoRa против UNB. Часть 1: физика
• Связь в интернете вещей: LoRa против UNB. Часть 2: бизнес
• Связь в интернете вещей: LoRa против UNB. Часть 3: технические тонкости
• Связь в интернете вещей: LoRa против UNB. Часть 4: сети и оборудование LoRa

Привет, Гиктаймс!

Извиняюсь за долгое молчание — я обещал многим выложить эту часть статьи ещё 22-го августа, но меня немного затянул прекрасный город Алматы, а потом прочие неотложные дела. В качестве компенсации — обещаю после сегодняшнего текста рассказать про конкретное оборудование для сетей LoRa/LoRaWAN (наше и не только), а также ещё и про некоторые технические аспекты работы сетей LPWAN. Последний текст логически должен был бы продолжать самый первый — там будет и про помехозащищённость, и про проблему обратной связи, и про достижимые скорости — но с одной стороны, на наших лекциях многие интересовались этими деталями, а с другой, сегодняшний текст тоже был обещан ещё более многим, и задерживать его ещё дольше совсем некрасиво. Поэтому сначала немного поговорим про бизнес.



Итак, поехали. В первой части я рассказал, чем схожи и чем отличаются на физическом уровне конкурирующие протоколы для IoT-сетей большой дальности — LoRa, Стриж, Sigfox и другие.

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

И вот здесь всё становится совсем весело.

Первая из серии статей, посвящённой описанию основных отличий технологий маломощной дальнобойной радиосвязи, получающей сейчас распространение в системах Интернета вещей: широкополосной связи LoRa от узкополосных (UNB, Ultra Narrow Band) систем, таких как Sigfox и «Стриж»

1. Связь в интернете вещей: LoRa против UNB. Часть 1: физика
2. Связь в интернете вещей: LoRa против UNB. Часть 2: бизнес
3. Связь в интернете вещей: LoRa против UNB. Часть 3: технические тонкости
4. Связь в интернете вещей: LoRa против UNB. Часть 4: сети и оборудование LoRa

Тема маломощной радиосвязи, позволяющей, не выходя за рамки безлицензионных диапазонов (то есть, как правило, за мощность 25 мВт), передавать низкоскоростные данные на расстояния от 1-3 до 10-30 километров, в России начала бурно развиваться в последние полгода. То есть — говорили о ней и до этого, но практические применения встречались очень редко, а разработчиков и интеграторов, способных сделать проект на подобных технологиях, было крайне мало.

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

Основная конкуренция в этом сегменте сейчас — между широкополосной связью LoRa и узкополосной Sigfox (а конкретно в России — схожей с ней технологией «Стриж-Телематики»). В будущем к этому списку добавится UNB-протокол Weightless, а также сети, продвигаемые поставщиками классического оборудования сотовой связи — NB-IoT и LTE-M, но это случится года через два-три.

Итак, в чём же разница — и что выбрать для конкретного проекта? Поехали.

Привет, Geektimes!

Этим полукреслом мастер Гамбс начинает новую партию мебели...
И. Ильф, Е. Петров, «Двенадцать стульев»

Совсем недавно мы — Mail.Ru Group, Intel и Unwired Devices — делали хакатон по Интернету вещей. В принципе, это могло бы быть рядовым событием — хакатоны по IoT сейчас не делает только ленивый. Но мы решили придумать формат, который выгодно отличал бы нас от других подобных мероприятий.

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


Ничтожная часть выпитого за два дня кофе

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

Привет, GT!

Если вы хотели бы сделать свой собственный «железный» модуль на Intel Edison, но не уверены, с какого бока к нему подступиться — этот текст для вас. Он — про особенности и мелкие нюансы создания своего устройства на Edison, без использования готовых отладочных плат Intel или Sparkfun.

Недавно у нас возникла специфическая задача: нам понадобился IoT-хаб (то есть шлюз между специфическими для «Интернета вещей» сетями 6LoWPAN и LoRa, которыми мы занимаемся, и внешним миром) на архитектуре x86. Наш стандартный вариант — это решение на нашем собственном микрокомпьютере Unwired One на архитектуре MIPS, но в данном случае был нужен именно x86.

Дело в том, что хаб у нас — это не просто транслятор из 6LoWPAN/LoRa во внешний мир всего, что с той стороны прилетело, а во-первых, небольшой сервер IoT-сети, который поддерживает её существование, раздаёт IP-адреса (при наличии в данной сети таковых) и занимается прочей технической работой, во-вторых, собственно border router из IoT во внешний мир, в-третьих, прослойка на уровне приложений, превращающая наши собственные протоколы IoT-сети в распространённый MQTT и унифицирующая сети разных видов, а в-четвёртых, платформа, на которой клиент может сам написать какой-либо интересный ему софт, проводящий накопление и обработку данных до отправки их на большой сервер, в облако и т.п.



Собственно, в последнем и возникла загвоздка. Проблема в том, что при всех разговорах о грядущей победе IoT, с ПО этого уровня в нём всё довольно плохо — его, если говорить коротко, нет. Стандартного, универсального, не привязанного к конкретной железке и не написанного на яве (да простят меня её поклонники, но когда у вас 256 МБ ОЗУ — это много, Java — так себе выбор).

Привет, Гиктаймс

Как вы знаете, мы — компания Unwired Devices — занимаемся базовыми технологиями связи для «Интернета вещей», то есть, если говорить более конкретно, модулями связи и низкоуровневым ПО для сетей 6LoWPAN и LoRa. Темы крайне популярные и востребованные, но при этом, как показывает практика, большинство потенциальных потребителей и даже разработчиков электроники в их специфике разбирается довольно слабо.



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

Итак, в июле:

• 25 июля, Санкт-Петербург — семинар по IoT совместно с компанией «Россинно»
• 30-31 июля, Москва — IoT-хакатон в офисе Mail.Ru Group совместно с компанией Intel

Две недели назад мы уже приглашали всех желающих принять участие в хакатоне по теме «Интернета вещей», который пройдёт 30-31 июля в московском офисе Mail.ru Group — и научиться работать с такими современными IoT-платформами, как микрокомпьютеры Intel Edison и СУБД Tarantool.

С того момента мы получили множество заявок и описаний будущих проектов — от вполне конкретизированных до «сделаю что-нибудь крутое». Авторы многих из них планировали построить прототипы целых распределённых систем сбора и обработки данных — то есть, в общем, реализовать самые настоящие IoT-проекты с областью применения от «умного дома» до количественного земледелия.



Поэтому мы решили расширить круг оборудования, которое будет доступно участникам хакатона — и теперь в него войдут комплекты беспроводных модулей сети 6LoWPAN разработки компании Unwired Devices, которые в сочетании с Tarantool и Edison позволят осуществить всё, что бы ни задумали участники.

Итого, участникам хакатона будут доступны технологии:

• Набор датчиков и управляющих устройств Unwired Devices для сети 6LoWPAN
• Шлюз между 6LoWPAN и Wi-Fi на базе микрокомпьютера Intel Edison
• Работающая на шлюзе СУБД Tarantool, обеспечивающая обработку и надёжную репликацию данных

Более того, хакатон посетят и представители венчурного инвестора — фонда CommIT Capital, принадлежащего компании «Ростелеком».

Подавайте заявки и приходите!

P.S. Что именно будет входить в наборы — под катом.

Привет, GT.

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

1. Компактными — чтобы не увеличивать размеры устройств
2. Экономичными — чтобы долго работать даже на батарейках
3. Дешёвыми — чтобы их использование имело какой-то экономический смысл

К всеобщему счастью, сейчас таких средств появилось достаточно много — начиная с в той или иной степени удачных попыток адаптации старого доброго Wi-Fi к этим требованиям (я сейчас в большей степени про устройства класса battery-powered Wi-Fi, от ESP8266 до QCA 4004 и TI CC3200) и заканчивая специализированными протоколами, изначально сделанными под данные требования: в первую очередь ZigBee, Z-Wave и 6LoWPAN.

Наиболее гибким, удобным и перспективным из этого является 6LoWPAN (а если вы слышали произносимое с придыханием слово «Thread», то он собственно поверх 6LoWPAN и работает) — и, собственно, мы как раз и занимаемся разработкой модулей и устройств с использованием 6LoWPAN.

Но сетевые протоколы — это, очевидно, лишь половина беды. Вторая половина — «железо», на котором они будут работать.

Модули 868 МГц нашей разработки на TI CC1310

В последнее время возникла мода клеить этикетку «IoT» буквально на всё, что хоть как-то умеет работать с «беспроводкой» — начиная с Arduino с нацепленными BLE- или Wi-Fi-шилдом и заканчивая всевозможными морально устаревшими чипами, к которым десять лет назад выпустили «официальный» стек ZigBee. У человека, который впервые в это погружается, голова закружится достаточно быстро и с неприятно большой скоростью.

Мы в своей работе однозначно определились с выбором платформы на обозримое будущее — это последнее поколение SoC Texas Instruments серии SimpleLink, чипы CC1310, CC2630 и CC2650.

Под хабракатом — объяснение, почему выбор именно таков и почему мы считаем его правильным.

Привет, Geektimes!

Управление мощными нагрузками — достаточно популярная тема среди людей, так или иначе касающихся автоматизации дома, причём в общем-то независимо от платформы: будь то Arduino, Rapsberry Pi, Unwired One или иная платформа, включать-выключать ей какой-нибудь обогреватель, котёл или канальный вентилятор рано или поздно приходится.

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

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



Я же хочу рассказать про простую и довольно очевидную, но при этом редко встречающуюся схему, умеющую вот такое:

• Гальваническая развязка входа и нагрузки
• Коммутация индуктивных нагрузок без выбросов тока и напряжения
• Отсутствие значимого тепловыделения даже на максимальной мощности

Но сначала — чуть-чуть иллюстраций. Во всех случаях использовались реле TTI серий TRJ и TRIL, а в качестве нагрузки — пылесос мощностью 650 Вт.

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

Один из способов снизить себестоимость изготовления печатных плат — это объединение нескольких плат на одной заготовке и отправка на фабрику этой заготовки как единого проекта. Фокус в том, что серьёзные фабрики берут деньги за подготовку производства каждой платы, а ориентированные на DIY китайцы часто предлагают (Seeedstudio, например) фиксированную цену за фиксированный размер текстолита. В первом случае единый проект, даже если он в итоге разрезается на несколько плат, будет считаться как одна плата, а во втором — можно вместить на одну стандартную заготовку несколько небольших плат.

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

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



Это — один проект. В нём 32 платы 13 разных видов. Как собрать такой проект за четверть часа — ниже.

Привет, Гиктаймс!

В последнее время — ну как «время», так обычно говорят про дни или недели, а тут речь идёт скорее уже о годе-двух — мимо постоянно проскакивают статьи на тему «что такое Интернет вещей» (ну и на смежные: основные игроки, основные тенденции, новейшие продукты и так далее). К сожалению, примерно 99 из 100 из них насколько объёмны, настолько же и бессмысленны: их авторы пытаются говорить об IoT как о некоей единой и цельной концепции.

Однако цельного и единого IoT не существует и не может существовать. В лучшем случае, IoT можно определить как концепцию удалённого взаимодействия машина-машина (m2m) или машина-человек (m2h), в то время как классический Интернет — это взаимодействие человек-человек.

Но на этом единство и заканчивается. Можно ли описать одной статьей «тенденции и основных игроков интернета»? Да вы шутите, что ли? Придётся охватить СМИ, соцсети, видеосервисы, магистральных провайдеров, ВОЛС, сотовые сети, корпоративные сети, облачные сервисы для бизнеса, сетевое оборудование для дома, CPE для офиса, магистральное оборудование… всё это — части того, что называется сейчас «Интернет».

То же самое — и с «Интернетом вещей». Это и лампочки LiFX в квартире, и контроллеры Danfoss в вентиляционных установках офисных зданий, и ваш любимый фитнес-трекер, и система мониторинга дорожной обстановки мегаполиса, и централизованный сбор данных о состоянии и ресурсе парка электрофрезерных станков, и много чего ещё. Каждое из этих применений — это свой собственный рынок, собственные решения и на программном, и на аппаратном уровне и, разумеется, собственные игроки, многие из которых другими сегментами IoT не занимаются и никогда не будут заниматься.

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

Что в этой ситуации делать? Я думаю, начать немного разгребать интернето-вещевые завалы, раскладывая по полочкам базовые понятия. И начать я хочу с того, какие беспроводные технологии сейчас популярны — и чем они, чёрт возьми, друг от друга отличаются.

Говоря человеческим языком — на чём сейчас принято делать нижние три уровня модели OSI.