Прототип автоматизированной системы передачи показаний счетчиков воды на основе LoRa-модулей

Введение в LoRa

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

Мне показалось интересным реализовать систему передачи и подсчета таких импульсов самостоятельно. В интернете есть примеры реализации подобных систем на основе Wi-fi, Bluetooth и Arduino [1][2][3][4][5], но в 2021 году это уже очень скучно и, к тому же, потребляет много энергии. Я решил построить подобную систему на основе модных радиомодулей LoRa (нодах), которые потребляют очень мало энергии и могут быть объединены с помощью сети LoRaWAN и подключены к шлюзам (Gateways), которые, в свою очередь, соединяются через интернет с сервером.




Такая система придумана для экономии энергии на оконечных нодах. Например, в моем туалете нет электричества, или мне просто не хочется штробить стены и выводить проводку для розеток. Вместо этого я беру один аккумулятор 18650, и подключаю к нему LoRa-модуль, который будет передавать единичку на такой же LoRa-модуль в шлюзе, подключенном в обычную розетку в жилой комнате, когда срабатывает геркон. Шлюз подсчитывает, сколько воды утекло, и передает эти данные по домашнему Wi-Fi или 4G управляющей компании. В качестве LoRa-модуля можно использовать, например, RFM95 или аналогичный ему Semtech SX1276. Цена этих модулей составляет 300-400 рублей, но я где-то покупал и за 270. В качестве шлюза можно использовать, например, модули Heltec WiFi LoRa 32 или Lilygo TTGO lora32. Эти модули стоят по 1000 рублей, но нужно учитывать, что такой модуль требуется всего один, и в него будут поступать все данные со многих модулей, если делать умный дом на основе LoRa. В Европе и России военные согласовали для LoRa частоты 830-870 МГц. Исходя их этого приобретайте модули на 868 МГц (в США 915 МГц, в Азии 433 МГц).






Казалось бы, все очень красиво и предельно просто. Но при ближайшем рассмотрении возникают особенности. Сам по себе LoRa-модуль потребляет очень мало, но standalone он работать не может. Для управления LoRa-модулем нужен контроллер. Китайцы придумали специальные модули на основе Atmega328p, в которые можно впаять LoRa-модуль, и залить в контроллер прошивку, даже написанную на фреймворке Arduino.



Но мы не ищем легких путей! Специализированные модули на Atmega328p стоят около 300 рублей, но как бы жаба душит, потому что мы уже купили сами LoRa-модули и шлюз, а на продукт китайского сумрачного гения как-то не рассчитывали. Для управления LoRa-модулем не нужен мощный контроллер, для этих целей вполне может сгодиться дешевый контроллер серии Attiny. Энтузиасты уже реализовали подобные модули для измерения температуры самостоятельно на основе распространенного и дешевого Attiny85 [7][8][9][10].



В ходе рассмотрения подобных проектов я выяснил, что реализации на Attiny85 остро не хватает свободных ног, что ведет к необходимости правки фьюзов для нормализации RESET-ноги. Это меня категорически не устроило при том, что существует вполне нормальная и не сильно более дорогая альтернатива в виде Attiny84 с 14-ю ногами, на последнем микроконтроллере и было решено остановиться. При использовании Attiny84 совместно с фреймворком Arduino нужно иметь ввиду, что номера выводов Attiny сильно отличаются в этом фреймворке от привычных при программировании на чистом AVR.



Наиболее близкий к моим надобностям проект был скоро найден [11]:



Разработчик реализовал LoRa-ноду с контроллером Attiny84 с возможностью подключения нескольких датчиков к свободным ногам микроконтроллера.



В ходе рассмотрения данного проекта и подобных ему выяснилось, что члены сообщества thethingsnetwork (4000 LoRa-узлов) написали библиотеки для LoRa-модулей в связке с Attiny, адаптировав их к условиям сети LoRaWan. В этих библиотеках кроме, собственно, передачи данных, присутствует очень много кода, связанного с шифрованием. Кроме того было выяснено, что их реализация несколько отличается по методу расчета несущих частот от реализации библиотеки Arduino-LoRa [12], которую я планировал использовать для модуля Lilygo TTGO lora32 v1, выступающего в роли шлюза. В результате было решено изменить частоту при использовании Arduino-LoRa с 866 до 868.1 МГц, а код библиотеки RFM95.cpp из проекта [11] переписать, выпилив шифрование и приведя значения, записывающиеся в регистры LoRa-модуля, к значениям из библиотеки Arduino-LoRa, все равно мои импульсы из туалета пока никому кроме меня не нужны, а также заменить метод расчета несущих частот. Работа с регистрами оказалась самой сложной и долгой частью реализации прототипа. Впоследствии, конечно, можно адаптировать разрабатываемую систему для сети LoRaWAN, но пока моей задачей было получить работоспособный прототип, способный просто адекватно считывать и передавать данные.

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

Описание системы

Сначала был реализован неудачный прототип, который должен был совмещать все функции на одной плате. С ЛУТ для прототипирования мне принципиально связываться не хотелось, и в наличии было очень много SOP/DIP переходников, поэтому я решил их использовать, спаяв на макетной плате гнезда для них. Это позволило использовать в прототипе именно те электронные SOP-компоненты, которые в будущем будут в устройстве. В случае выхода из строя таких компонентов их можно легко заменить. Поскольку шаг отверстий под вилки в LoRa-модулях составляет 2.0 мм, мне требовалась макетная плата, сочетающая в себе шаги отверстий 2.0 мм и 2.54 мм. Такие платы существуют, и стоят от 50 до 100 рублей в зависимости от жадности продавца.



На плате должны были находиться модуль питания от литиевого аккумулятора 3.7 В, Attiny84, LoRa-модуль SX1276 и IPEX-коннектор для выносной антенны, чтобы не быть ограниченным пластиковым корпусом. Попытка уместить все это на одной плате закончилась неудачно - бесконечная борьба с возникающими непонятно откуда КЗ вынудили разделить прототип на два модуля.



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



Я очень рекомендую эти макетные платы. Их качество стоит их высокой цены, а примененный вариант платы очень удобен для прототипирования небольших устройств или модулей, так как имеет две скрытые внутри шины VCC и GND с несколькими выводами. Это позволяет реализовать большинство простых схемок именно в том виде, как они нарисованы.



У модуля питания две функции: стабилизация напряжения питания на уровне 2.5 В и разрыв цепи батареи при напряжении менее 3.15 В, чтобы не убить батарею. Для последнего была использована известная схема на основе формирователя импульса MCP100-315T, который стоит всего около 40 рублей.



Понижение напряжения до 2.5 В осуществлялось с помощью малошумящего стабилизатора напряжения LP2985-28DBVT с низким значением Dropout Voltage производства TI. Такое напряжение питания было выбрано для обеспечения максимального времени использования литиевой батареи с учетом применения формирования импульса и минимального падения напряжения на стабилизаторе. Перед пайкой все соединения были прорисованы во Fritzing.



Все остальные компоненты прототипа были размещены на упомянутой плате "2.54 мм/2.0 мм", к ним был также добавлен ICSP-коннектор для подключения программатора USBAsp через переходник "10 на 6".



Питание осуществлялось через известный модуль AMS1117-5.0/3.3, так как это позволяло быстро менять напряжение питания.

Работа с Attiny, вообще говоря, представляет определенную сложность, так как данная серия микроконтроллеров не обладает полноценным SPI и не имеет на борту hardware serial. Это влечет за собой невозможность простой отладки кода через последовательный порт. Существует большое количество библиотек-реализаций software serial, но ни одна из них у меня так и не заработала на Attiny84. Таким образом, было решено проводить отладку влоб - с помощью OLED-экрана ssd1306. С подключением этого распространенного экрана к Attiny84 также существуют определенные сложности, но опытным путем были найдены библиотеки, позволяющие все-таки выводить на этот экран данные с Attiny84 [13][14].
По факту получилось выводить информацию только единожды, затем контроллер зависал, но и этого оказалось достаточно для того, чтобы убедиться: АЦП контроллера правильно измеряет напряжение питания с точностью 50 мВ, и эти данные можно далее передавать через LoRa-модуль.



Напряжение питания измерялось и передавалось, так как была необходимость получать и передавать именно цифры. Передающий и приемный модули записывают и получают данные из определенных регистров. Эти данные хранятся и передаются в виде строк. На стороне Attiny84 строка считывается в виде массива char и конвертируется в ссылку unsigned char*. А на стороне Lora32 данные принимаются из регистра в виде строки String. Все это не очень удобно для передачи цифр. Цифры приходится передавать, запаковывая их в строку побайтово и интерпретировать полученное, деля строку также побайтово. Если этого не делать, то вы просто получите так называемые "крякозябры", которые являются ничем иным, как различными малоиспользуемыми символами UTF-8.




Проверка модуля с герконом

Итоговой целью было наладить взаимодействие разработанной системы с герконом счетчика воды. На уровне прототипа было решено использовать готовый модуль, имитирующий геркон счетчика и имеющий в схеме компаратор LM393, который позволяет интерпретировать импульс от геркона как высокий логический уровень (boolean true или int 1) при приложении магнита. Модуль геркона был соединен с Attiny84 по приведенной схеме.






Из-за огромного объема материала создание готового устройства на основе разработанного прототипа вышеприведенных схем будет рассмотрено в следующей статье.

Код ноды
Код шлюза