COOLRF: Перезагрузка



    Многие хабравчане уже успели заметить необычно большую паузу в наших регулярных публикациях «из жизни COOLRF». За прошедшие более чем полтора месяца случилось много важных событий. Мы потеряли, но потом нашли и благополучно получили посылку с «редкоземельными» компонентами нашего диммера. Компания JetStyle нарисовала отличный дизайн для нашего сайта. Хабрахабр продлил наш бесплатный корпоративный аккаунт (да, полгода пролетели махом!). Мы решили одну аппаратную проблему диммера, но пока не смогли решить другую. Поняли, что текущий аппаратный дизайн диммера не совместим с программным стеком Atmel BitCloud. Расстались с одним участником. Решили вернуться к разработкам на базе NRF24LE1. Начали разработку одного нового интересного решения с новым разработчиком.

    Интересно? Добро пожаловать под кат (осторожно, неожиданно много букв)!

    Краткий ввод в курс для тех, кто первый раз увидел наш проект
    Мы разрабатываем полноценную систему Умного дома. «Первая ласточка» нашей системы — DIY-диммер. Вот его основные характеристики:
    • Работа по радиоканалу 2,4Ггц
    • Защищенное шифрованием соединение
    • Установка без изменения стандартной электропроводки обычной квартиры
    • Низкий расход электроэнергии
    • Привычный внешний вид выключателей
    • Возможность самостоятельного расширения как аппаратного, так и программного функционала

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

    Хотите быть в курсе всех событий проекта? Это совсем не сложно!
    Нужно всего лишь подписаться на обновление нашей компании на Хабре и в группе ВКонтакте.

    С ВКонтакте вопросов обычно не возникает. Чтобы подписаться на обновления Хабра, нужно перейти на страницу компании и нажать кнопку «Подписаться» в блоке справа.

    Китайские приключения


    Экономия не всегда доводит до добра. Первые два раза мы приобретали электронные компоненты через уже хорошо нам знакомую компанию HQEW. Оказалось, что они занимаются не только печатными платами. У них есть «проверенный» поставщик электроники, через которого, вроде как без проблем и недорого можно купить всё, что душе угодно. На деле, по сравнению с прямыми закупками на taobao, получалось не так уж недорого. Плюс цены на компоненты здорово (иногда — в разы) плавали между разными поставками. Мы решили закупить компоненты на taobao, без HQEW.

    Всё могло закончиться без приключений, воспользуйся мы услугами одного посредника. Но мы хотели провернуть всё быстрее. Поэтому мы договорились с taobao-посредником о нетиповой для него операции — отправке нашего консолидированного (состоящего из нескольких входящих посылок от разных продавцов) груза не сразу в Россию (не быстро, своим каналом), а в соседний Шенчжень китайской курьерской службой. Откуда наша посылка должна была оперативно самолетом улететь к нам.

    В итоге получили классический случай. Посредник отдал посылку курьеру и сказал «я умываю ручки», а служба доставки в Шенчжене вроде как посылку не получила. Каждая сторона долго всячески отгораживалась от ответственности. Только через неделю «разборок» мы начали узнавать от отправителя важные подробности в духе «нашим китайцам звонили ваши китайцы и говорили, что не хватает одной бумажки». В итоге очень помогли сотрудники екатеринбуржского офиса службы доставки (сначала вопросы пытались решать напрямую с китайским офисом). Ситуация разрешилась. С учетом неразберихи посылка шла по «быстрому» дорогому каналу значительно дольше, чем прошла бы по дешевому медленному каналу самого посредника. Намотали на ус…

    Дизайн сайта


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



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

    Аппаратные проблемы диммера


    Приличное количество времени ушло на освоение здесь в Екатеринбурге схемотехники, разработанной на Украине. Не выходило получить стабильно работающую детекцию нуля микроконтроллером. Лампа заметно мерцала на среднем диапазоне регулирования мощности. Секрет оказался прост — при сборке было пропущено требование использования LOWESR-версии одного из конденсаторов.

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

    ZigBee-исследования


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

    BitCloud накладывает на пользовательский код серьезные ограничения по времени выполнения отдельных участков. Мы пришли к выводу, что не получится объединить в одном чипе управление диммером (контроль ноля + управление симистором) и работу со стеком BitCloud. Единственным возможным решением здесь было бы добавления в схематику диммера дополнительного микроконтроллера, отвечающего за низкий уровень работы диммера. Такая «инновация» а) заставила бы нас значительно отодвинуть сроки выпуска продукта, б) привела бы к заметному удорожанию диммера и в) стала окончательно невозможна по причине изменения состава участников.

    Расставание с одним из участников


    Проект покинул Александр Михеев alexmgf, основной идеолог использования ATMEL в качестве управляющего чипа. Александр посвятил огромное количество своих вечеров исследованиям ZigBee. В результате несколько утратил веру в возможность быстрого развития проекта. После смены основного места работы свободного времени у Александра стало значительно меньше. Было принято совместное решение о расставании.

    Все разработки, касающиеся чипа ATMEGA128RFA1 и радиомодуля, на нем основанного, остаются за Александром. Желающим приобрести эти модули (а таких желающих оказалось весьма не мало — чип имеет своих поклонников) следует обращаться напрямую к нему: AlexMGF (skype).

    Перезагрузка проекта COOLRF


    Переход проекта на использование новых чипов в своё время произошел сразу по нескольким причинам: 1) было сложно найти людей, умеющих программировать чипы NRF24LE1, 2) появился человек, желающий взять на себя значительную часть работы по проекту и имеющий многолетний опыт взаимоотношений с микроконтроллерами ATMEGA128RFA1, 3) на базе ATMEGA казалось возможным разработать модуль, совместимый с  индустриальными стандартами, а значит — совместимый с устройствами других производителей (хорошее конкурентное преимущество).

    В сегодняшних реалиях все указанные причины оказались не актуальными: 1) люди, пощупавшие NRF24LE1 и нашедшие его вполне интересным, начали появляться (посты: 1, 2 и 3), 2) с Александром мы вынуждены были расстаться и 3) ZigBee реализовать оказалось совсем не просто.

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

    Новые начинания


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



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



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

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

    Что дальше?


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

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

    Если таким человеком оказались вы, не стесняйтесь обратиться напрямую к webself по любому из указанных на профильной страничке каналу связи.
    COOLRF 40,27
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Похожие публикации
    Комментарии 30
    • +1
      А кикстартер не думали?
      • +1
        Думаем, но нам пока рано.
      • –1
        какие-то совсем не радужные новости :(
        • +1
          Но и совсем не печальные, согласитесь. )
        • 0
          Поняли, что текущий аппаратный дизайн диммера не совместим с программным стеком Atmel BitCloud. Расстались с одним участником. Решили вернуться к разработкам на базе NRF24LE1. Начали разработку одного нового интересного решения с новым разработчиком.


          Что-то Вас штормит… причем неслабо так, то перешли с NRF24LE1 на ZigBee, потом обратно… Грустно. Желаю наконец то устаканиться и выпустить продукт.
          • 0
            Может стоить пойти более простым путем? Взять дешовский pic или даже arm, придумать радиоканал связи как у noolite, но только двунаправленный, придумать минимальное шифрование и все. При наличии опытного разработчика (ключевое слово ОПЫТНОГО) такое решение можно сделать за неск. месяцев.
            • +2
              Мне кажется, более простой путь и так выбран. Готовый радиоканал, который не надо отлаживать, у которого есть контроль ошибок и адресация ( и кстати каждый модуль внутри имеет по 6 буферов и 6 адресов для приема ). Остается только настроить и включить его.
              В Вашем случае надо разработать+отладить канал, на нем поднять контроль ошибок, контроль коллизий, идентификацию — это все гораздо дольше.
          • +1
            Смотрю, Вы перешли на маленькие модули как у меня :)
            С большим интересом слежу за Вашим проектом, желаю успехов!
            • +1
              " BitCloud накладывает на пользовательский код серьезные ограничения по времени выполнения отдельных участков. Мы пришли к выводу, что не получится объединить в одном чипе управление диммером (контроль ноля + управление симистором) и работу со стеком BitCloud "
              Как меня радует подобный подход. Стандартная бибилиотека не работает в наших условиях — варианты решения: ищем другую стандартную библиотеку, меняем условия ( в нашем случае — МК). Просто очаровательно. Посмотреть исходники библиотеки (они, как правило, есть), понять, что там не так, немного подпилить (заодно получив массу полезных знаний) — такой вариант современным разработчиком даже не рассматривается. Будущее индустрии в нашей стране мне представляется весьма туманным…
              Кстати а по поводу Вашего нового проекта — видел его раньше в виде ТЗ — позволю себе маленькое предложение — вместо того, чтобы менять существующий контроллер, раз он так хорош (хотя тиристорное управление существует на первый десяток лет), сделайте модуль, который будет под управлением радиоканала имитировать изменение параметров регулирующего элемента (скорее всего переменного резистора) и задача решена (DISS в действии).
              • +1
                Прежде чем писать мнение о нашем подходе, следует ознакомиться, что есть BitCloud. Хотя бы поверхностно. Он без исходников поставляется, объектными файлами. И скорректировать его внутреннюю архитектуру нет никакой возможности.

                По второму вопросу вы предлагаете подключиться к штатному резистору термостата и менять его сопротивление по сигналу с радиомодуля — я правильно понял суть предложения? :)
                • +1
                  По второму вопросу — именно так. При этом вы можете совершенно не думать об объекте управления — все уже сделано.
                  А по первой части — приношу извинения, если кого то обидел. Мысль была высказана о наболевшем — полнейшее нежелание среди молодых людей в чем то углубленно разбираться. И если нет исходников конкретной библиотеки, то наверняка существуют исходники других библиотек для такого достаточно распространенного интерфейса. Даже если они не портированы на выбраный МК, задача вполне решаема, разумеется при наличии желания ее решать (все остальные факторы не столь значимы, по моему мнению).
                  • 0
                    1. Никого не обидели, просто удивляет способность людей критиковать что-либо, при полном нежелании хоть как-то самим разобраться в вопросе. У этой библиотеки нет исходников. Под эту архитектуру это единственное доступное решение. И даже если бы исходники были, протокол не так прост, чтобы взять и скорректировать работу стека за пару вечеров. Портировать стек с другого МК — это вообще утопия, даже если бы было что портировать. Думаю, вы совсем слабо себе представляете расход временных ресурсов на такие «простые» действия. Почитайте пожалуйста документацию на ZigBee и другие доступные материалы на эту тему, чтобы продолжать риторику.

                    2. Если вы видели наш термостат еще в виде ТЗ, то видимо опять не очень внимательно читали. В конвекторах NOBO электроника четко поделена на силовую и управляющую. Мы подменяем только управляющую часть, используем штатную силовую. Мы создаем законченное решение, которое можно будет купить и просто вставить в конвектор. Без каких-либо доработок его напильником/паяльником.

                    Вы предлагаете сделать «колхоз», который обычно делают в устройствах «для себя». В каком виде вы предлагаете отдавать продукт людям в вашем сценарии разработки? В виде инструкции, куда подпаять и где подточить? Это не наш путь.
                    • 0
                      Значит так. Насчет полного нежелания разбираться в вопросе — сильно сказано. Я конкретно не работал с ZigBee, но работал с протоколами и интерфейсами, сравнимыми с ним по сложности. Я ОЧЕНЬ хорошо представляю себе расход временных ресурсов на ЛЮБЫЕ действия по проектирования электроники (более 20 реализованных проектов в разных областях тому подтверждение). За пару вечеров — видимо нет, но если Вы за эту пару вечеров успели разработать платы под новый МК, развести их, заказать и получить, то тогда, конечно, Ваш подход правильнее. Но, опять таки, мой многолетний опыт мне подсказывает что переход на другой МК займет ни в коем случае не пару вечеров. Мое личное мнение (естественно, я допускаю существование неправильного другого), что для портирования существующего стека на другой МК (при отсутствии СУЩЕСТВЕННЫХ различий в объеме постоянной и оперативной памяти и ЖЕСТОЧАЙШИХ требований стандарта к времени реакции) для квалифицированного инженера не должно занять более 2-3 недель упорного труда, что более чем сравнимо со временем перехода на другой МК. Сначала Вы сами пишете, что разработчики, привыкшие к ATMEL, не хотят переходить на не столь уж сильно от него отличающийся МК (что, на мой взгляд, не говорит в их пользу), а когда я пишу о нежелании современной молодежи глубоко разбираться в том, что составляет суть профессии, которую они выбрали, выясняется, что задача понять происходящее в полностью документированом стандарте совершенно неподъемна и чудовищно сложна. Мне данный подход представляется не вполне верным.
                      Что касается второго вопроса, то конечно, если речь идет о поставляемом широкому кругу пользователей продукте, реслизация предлагаемого мной варианта не является приемлемой, я его предложил, исходя из минимальной стоимости разработки. Удобство монтажа неподготовленным пользователем сильной стороной такого решения не назовешь, тут Вы абсолютно правы.
                      • 0
                        Ну вот, оценки уже идут ближе к реальности. 2-3 недели упорного труда (читай — fulltime) опытного разработчика? Может быть. Но у нас нет в распоряжении такого количества времени у специалиста такого уровня. А если бы было, мы бы предпочли его потратить на расширение линейки продукции, а не на портирование какого-то гипотетического зигбишного стека (повторю, не откуда его портировать, разговор сейчас о воздухе идет). Я уже молчу, что стек должен получиться сертифицированным (чтобы работать с другими девайсами), а на этот процесс тоже потребуются значительные средства.

                        В целом мы исходим из реалий с параметрами минимизации расходов, рисков и времени. Если вы сами хотите написать нужную реализацию ZigBee — welcome, пишите, продавайте. Будем только рады появлению альтернативы. Мы пока разберемся с более простым и дешевым решением вопроса.
                • +3
                  Как меня радуют люди, склонные обобщать и подгонять целые категории других людей под одну гребёнку. Просто очаровательно.
                • 0
                  1) Вы не рассматривали вариант использования NRF51822?
                  +++ arm (есть нормальный gcc, а не какой-то sdcc)
                  + BT LE (можно управлять напрямую с телефона)
                  + поддерживает протокол nrf24l*1 (если будут проблемы с BT)
                  — возможно будут те же проблемы что и с BitCloud (стек BT и код приложения крутится одном контроллере)

                  2) Контроль ноля не на прерываниях? Что там так долго выполняется?
                  • 0
                    1) нет, больше никуда прыгать уже не будем, напрыгались :) и BT LE напрямую можно управлять только с телефона со встроенным именно BT LE (на сколько я знаю), а таких телефонов не много.

                    2) лично я на этот вопрос ответить не могу. если Александр сюда заглянет, может быть ответит. он в курсе
                    • 0
                      1) Да, нужен телефон с BT4 (это фактически BT3+BT LE) и Android 4.3+/iOS.
                      Когда диммер зарелизите таких телефонов будет уже много.
                      • 0
                        только сегодня на новом месте инет подключил =), долбаный «кабинет» ((( — прошу прощения, наболело.
                        2) все очень просто, чтобы поддерживать сеть zigbee нужно с определенным интервалом выполнять определенные действия (даже на конечных устройствах), накладываем сюда еще работу самого bitcloud (считай работа операционки) — а его работа простая — по таймеру она проверят всю кучу назначенных ей задач и выполняет их, + также последовательно обрабатывая другие прерывания.

                        Детекция 0 разумеется на внешнем прерывании и даже импульс включения, подаваемый на оптопару, тоже на прерывании от таймера (при чем НЕ на том, который использует bitcloud, предоставляя api для пользования разработчику)

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

                        Решением для диммера, вижу использование доп чипа (самого дешевого и простого) на силовую часть, а atmegarfa1 использовать для работы с сетью и управления чипом силовой части.
                        • 0
                          Вы упёрлись в ограничение на 50us в коде «своего/не_системного» прерывания перехода через ноль? (в остальных местах вполне достаточные ограничения на 10ms/50ms).
                          Вроде кроме этого прерывания и импульса включения по таймеру для диммера ничего больше и не нужно…
                          • 0
                            то ли я много написал, то ли написал не понятно —
                            все очень просто, чтобы поддерживать сеть zigbee нужно с определенным интервалом выполнять определенные действия (даже на конечных устройствах), накладываем сюда еще работу самого bitcloud (считай работа операционки) — а его работа простая — по таймеру она проверят всю кучу назначенных ей задач и выполняет их, + также последовательно обрабатывая другие прерывания


                            Может на примере будет легче понять, хотя из выше сказанного вывод сам напрашивается.
                            Какие то действия, например подготовка\прием-отсылка пакета координатору (это не единственное), происходит под протекцией и когда на такие моменты попадает, скажем 0 — то, например, пропадает полупериод т.к. прерывание обрабатывается после действий над пакетом.
                            • 0
                              Протекция это критическая секция? То есть системный код bitcloud запрещает хардварные прерываний на время значительно превосходящее озвученные 50us?
                              Ваше прерывание по переходу через ноль никуда не должно пропадать и должно вызываться при выходе из критической секции.
                              Timer Input capture не пробовали? При его использовании вы сможете узнать точное время перехода через ноль, даже если во время перехода выполнялась критическая секция.
                              • 0
                                Попробуйте — возможно вам удастся.
                        • 0
                          Вы на самом деле сделали шаг назад. ATMEGA128RFA1 имеет лучшие в классе параметры (в частности, чувствительность приемника). Мы, правда, в одном из коммерческих проектов использовали не его, а AT86RF231. Но ATMEGA128RFA1 это суть тот же AT86RF231 с какой-то атмегой внутри.
                          NRF24LE1 – известное решение, есть много либ и стороннего кода, но с потребительской точки зрения (надежность связи) оно сильно проигрывает. Его ж Нордик для мышей и клавиатур делал, т.е. для дистанции в несколько метров. Намучаетесь вы с реальной сетью в помещениях с ж/б перекрытиями…
                          Вариант продолжения проекта – взять мелкий PIC10F (SOT23-6) за 20 центов в опте и реализовать диммер на нем. У некрочипа есть готовый проект.
                          • 0
                            Кстати по поводу готового проекта — ознакомился. Нестандартное применение выпрямительного диода порадовало -это без сарказма. Но лично меня сразу насторожили в нем номиналы гасящих резисторов и быстрый подсчет подтвердил, что имеется перегрузка по мощности в 2.5 раза. В общем по пустячек, резисторы такое вытерпят и является следствием арифметической ошибки в рассчетах, но тем не менее — «тщательнее надо быть». Еще один примерчик недотсточно ответственного подхода к проектированию, причем со стороны известной фирмы.
                            PS. А почему НЕКРОчип? Я что то пропустил?
                            • 0
                              Ну, я же призывал сходу брать готовую схему от «известного производителя». Любой AppNote нуждается в проверке и, возможно, доработке.
                              А почему НЕКРОчип?

                              Это мем с профильного форму (сахара)
                      • 0
                        Господин GarryC решил создать отдельный топик про нашу профнепригодность, в связи с откатом на NRF24LE1, где во всю не стесняется в выражениях. Кому интересно, можете поучаствовать. Я там еще раз написал о причинах отката, другими словами, для тех, кто на бронепоезде.
                        • 0
                          Я никоим образом не знаком с упомянутой платформой, чтобы сделать такие выводы. Этот комментарий я видел, он от другого автора, и моего мнения по поводу отката на данную конкретную платформу я не имею ввиду отсутствия достаточного уровня компетентности именно по данному поводу. Я стараюсь избегать подхода «Пастернака не читал, но, как весь советский народ, решительно осуждаю» — читателям судить, насколько мне это удается. При этом я все таки стараюсь допускать, что существуют аспекты, которые я мог упустить либо не придать им должного внимания, опять таки мне так казалось. Мое личное мнение, что переход с одной платформы на другую, а затем возврат на предыдущую не может быть отнесен к сильным сторонам проекта и, скорее всего, свидетельствует о недостаточно тщательном продходе к разработке. В своем первом посте я как раз и рассказывал, как вытягивал из МК и библиотеки по крохам требуемое быстродействие и таки вытянул. Если есть аргументированое противоположное мнение, с радостью с ним ознакомлюсь.
                        • 0
                          А вот такую штуку вы видели mysensors.org/? Хорошая стандартная открытая платформа с поддержкой и комьюнити для устройств с nrf24l01.

                          Возможно есть смысл сделать вашу железку на их протоколе. Исходники там есть, правда для арудино.
                          • 0
                            Не видели, ознакомимся. Спасибо за ссылку.

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

                          Самое читаемое