Обзор LoRa концентратора — RAK831

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

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

B49-0

Распаковка и комплектация

Упаковка — стандартная коробочка с лейблом RAK и фирменной обезьянкой на наклейке-пломбе (кликабельно):

Открываем. Внутри можно видеть провода в отсеке сверху, в основном отсеке первым слоем идёт FT2232H модуль и следующим слоем, собственно, LoRa концентратор RAK831 (кликабельно):

Всего внутри содержится: концентратор RAK831, FT2232H модуль, кабель USB-miniUSB, 2 штыревых комплекта проводов мама-папа и антенна. Поближе на фото все комплектующие из коробки (кликабельно):

Концентратор сверху отдельно (кликабельно):

Концентратор снизу отдельно, тут сразу видно небольшой недочёт — SMA разъём вообще не пропаян снизу… не выдержал, пропаял сразу (кликабельно):

Как-то скучно выглядит, мало деталек… аккуратно снимем экраны, под ними-то уж явно поинтереснее будет! ;) Присутствует термопрокладка на основном чипе (кликабельно):

Модуль FT2232H и инструкция к нему (кликабельно):

Пайка SMD хорошая, как и на самом RAK831, а вот пайка PLS разъёмов не очень, видно довольно много флюса и часть дорожки у одного контакта вообще оторвана (боковой разъём) — видимо паяли впопыхах или студенты.

Сразу отмечу, что на плате предусмотрено место для установки EEPROM в SOIC-8 корпусе — она нужна, если вы хотите на основе FT2232H сделать своё устройство (свои PID\VID\имя\настройки портов), а-ля USB в JTAG\SPI\I2C\шина или более навороченное. Это удобно, радует, что предусмотрено место!

B49-21

Есть одно но — EEPROM 93С46 не очень удобен в плане большого корпуса (FT2232H можно взять в QFN-64 для своего устройства и SOIC рядом с ним выглядит не очень, имхо) и не всегда можно его достать. Выход есть — 93LC56AT-E в SOT-23-6 или 93LC56AT-I в DFN-8, только схема подключения немного отличается:

B49-22

У меня в наличии 93LC56AT-E, поэтому пришлось немного поколхозить (кликабельно):

Идеально было бы, если бы на плате было предусмотрено под 2-3 варианта установки EEPROM. Сам модуль FT2232H сделан удобно, и я явно буду использовать его не только с RAK831 (при использовании с малиной он не особо-то и нужен), а и при отладке других проектов.

Еще из небольших неудобств — линия шины BDBUS0 выведена на нижний, красный разъём, что не удобно. На месте же этого пина на правой колодке присутствует PWREN — зачем? Более логично его было бы вывести как раз вниз, к питанию и сигналам SUSPEND, USB_RST.

Больше особенностей не заметил, можно переходить к подключению и запуску!

Uniwersal Windows Platform

Это первое, что пришло в голову, как только задумался о применении, — попробовать прикрутить к такому крутому проекту, как Wirehome (или HA4IoT по-старому) — это а-ля автоматизация для дома на Windows IoT. Начал изучать материалы, гуглить, что уже есть по теме. В итоге из основного:

  • RAK831_LoRaGateway — официальный пример работы с RAK831 для Linux;
  • The Things Network GitHub — практически всё, что потребуется для старта концентратора, есть здесь;
  • A LoRaWAN “The Things Network” Gateway for Windows IoT Core — практически готовый проект концентратора на обычном конечном устройстве и малине с Windows IoT, но с ограничениями: только один канал; неполная поддержка спецификации LoRaWAN;
  • AN_475 FTDI Windows 10 IoT Solutions — официальный пример приложения UWP (видео) для Windows IoT и FT4232H (и других чипов);
  • FTDISample — неофициальный пример работы с FTDI на UWP (не работает на новых билдах Windows IoT).

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

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

  • само портирование с сишного кода под сишарп не такое уж и простое в этом случае вышло;
  • библиотека из примера FTDI не имеет исходников, откомпилирована под АРМ, декомпилировать удавалось частично — собрать обратно её мне не удалось;
  • для отладки UWP библиотеки\приложения можно, конечно же, использовать нативный SPI на малине, и так и нужно поступать, т. к. модуль FT2232H для малины по факту не нужен, но для написания и отладки библиотеки\приложения это не вариант — очень медленно это будет по сравнению с ПК + FT2232H (вот тут то и нужна UWP библиотека);
  • работа и тупо недостаток свободного времени.

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

WSL + PC + FT2232H

Недавно я опробовал WSL и он мне очень понравился! Также разобрался и опробовал компиляцию проекта-примера RTL0B_SDK для RTL8710BN — крайне просто и действительно значительно быстрее, чем с использованием MSys. Буду разбираться, как делать свои проекты под WSL, и опишу процесс в одной из следующих статей, но речь сейчас не об этом. ;)

Итак, у меня есть ПК с Windows 10, в ней есть WSL с Ubuntu, есть модуль FT2232H и мануал по установке примера от RAK для Linux — что может быть проще для быстрого старта??

Идём на RAK831_LoRaGateway и практически по шагам повторяем всё, как там описано. Я же таки повторюсь и опишу, как это было у меня.

Скачиваем архив исходников:

$ wget https://github.com/RAKWireless/RAK831_LoRaGateway/archive/master.zip

Распаковываем их рядом:

$ unzip master.zip

Примечание: если не установлен unzip, ставим его:

$ sudo apt-get install unzip

Далее ставим драйвера для FTDI:

$ sudo apt-get install libftdi-dev

Будут установлены следующие пакеты:

  • libftdi-dev 0.19-4 (armhf)
  • libftdil 0.19-4 (armhf)
  • libusb-dev 2:0.1.12-20 (armhf)

Далее заходим в папку исходников библиотеки libloragw:

$ cd RAK831_LoRaGateway-master/libmpsse/src

Обновляем конфигурацию сборки:

$ sudo ./configure --disable-python

Чистим проект перед сборкой на всякий случай (прикол к слову — на Ubuntu у меня, как ни странно, заработало просто make, а на Raspbian без этого не собиралось):

$ make clean

Теперь собираем:

$ make all

Устанавливаем скомпилированную библиотеку в ОС:

$ sudo make install

Обновляем кэш установленных библиотек:

$ sudo ldconfig

Далее потребуется собрать, собственно, примеры работы с концентратором. Переходим в директорию lora_gateway:

$ cd ../../lora_gateway

Если необходимо, настраиваем опции сборки:

$ sudo nano libloragw/library.cfg

Я, к примеру, для первого запуска выставил флаг для отображения логов работы SPI — DEBUG_SPI= 1.

Чистим проект перед сборкой:

$ make clean

Собираем:

$ make all

Вроде всё отлично! Всё собирается, и вот-вот можно будет запускать концентратор. Для запуска тестовых приложений переходим в папку libloragw:

$ cd libloragw

Предварительно подключив модуль FT2232H к ПК, убедившись, что он определился в Windows и драйвера установлены. Подключаем концентратор по следующей схеме из Quick Start Guide:

B49-24

Или подключение в виде таблицы:

B49-25

Последнее, что осталось для проведения теста, — запустить любую утилиту-пример работы с концентратором. Запустим пример на приём пакетов:

$ sudo ./test_loragw_rx 868.0

И вот тут нас ждёт разочарование…

B49-26

Ошибка доступа к FT2232H — попросту не находится ни одного доступного. В чем же проблема? COM-порты FT2232H прекрасно видны в Ubuntu и открываются, проверено. Начал искать… вводим команду вывода списка подключенных USB устройств:

$ lsusb

И пусто. Вообще. Странно, в чём же проблема то, ищем дальше и находим:

Ну что же, выходит, на данный момент есть только один путь у меня, чтобы попробовать концентратор в работе…

Raspbian + Raspberry Pi 2\3

Окей, пока это самый наименее затратный по времени и рабочий из коробки путь (да-да, знаю, сам пошел «неверными» путями с кучей грабель, но это интересно и опыт!).

Мануал по установке повторяется практически один-в-один с тем, что выше для WSL Ubuntu. Только надо включить нативный SPI в Raspbian, вызвав приложение для настройки:

$ sudo raspi-config

Далее переходим по пункту Interfacing Options:

B49-27

Далее выбираем SPI:

B49-28

Разрешаем его работу после загрузки ОС:

B49-29

И после этого сообщения можно завершать работу приложения и перезагружать малину:

B49-30

Перезагрузить малину командой:

$ sudo reboot

Теперь можно повторять мануал установки тестового комплекта из RAK репозитория. В настройках компиляции libloragw/library.cfg только не забываем выбрать использование нативного SPI, а не FT2232H (но можно и его, если лень, — просто в USB втыкаем, будет так же работать).

И всё запустилось с полпинка! Единственное, что, вроде как, надо еще делать — это дергать Reset на концентраторе после запуска малины. Я этого не делал, работает и без принудительного сброса, но если устанавливать концентратор на постоянную основу для работы, то этим стоит озаботиться. Решается это или шелл скриптом:

#!/bin/bash
echo "17" > /sys/class/gpio/export
echo "out" > /sys/class/gpio/gpio17/direction
echo "1" > /sys/class/gpio/gpio17/value
sleep 5
echo "0" > /sys/class/gpio/gpio17/value
sleep 1
echo "0" > /sys/class/gpio/gpio17/value

Или мини-утилитой на Си, исходник RAK831Reset.c :

#include
#include
#define GPIO_RESET_PIN 0 // gpio17, проверять соответствие пинов в wiringPi !!!
int main() {
wiringPiSetup();
pinMode(GPIO_RESET_PIN, OUTPUT);
digitalWrite(GPIO_RESET_PIN, HIGH);
sleep(5);
digitalWrite(GPIO_RESET_PIN, LOW);
return;
}

Для неё требуется установленная библиотека по работе с GPIO — wiringPi.

Компилируется же утилита просто:

$ gcc -Wall -o RAK831Reset RAK831Reset.c -lwiringPi 

Запускается еще проще:

$ sudo ./RAK831Reset

Здесь должны быть результаты теста

Для теста я переделал пример test_loragw_full_duplex, чтобы он отвечал на пакеты со строкой ‘PING’ ответным пакетом со строкой ‘PONG’. Вроде бы даже заработало (скриншот первых тестов с дополнительной нагрузкой в виде 0х00 до длины в 64 байта):

B49-31

Вот только очень смущает значение RSSI — платы лежат на столе, рядом друг с другом, а уровень сигнала довольно мал. Попробовал потестировать на расстоянии — подтвердилось, что явно методика неверна, связь была метров 100-150 максимум и далее вообще не принимаются пакеты. Круто… прям совсем ‘дальнего действия’ технология или руки крайне кривые. :) Будем разбираться…

При запуске утилиты test_loragw_full_duplex 868.1 сначала смутило, что автоматически частоты каналов на приём\передачу разделяются (т. е., к примеру, на приём выставляется ожидаемо 868.1 МГц, а на передачу 868.5 МГц), я же схитрил и аргументами при вызове задал одинаковые частоты. Но если подумать, это вполне логично, потому что RF Tx\Rx здесь совмещены и в итоге подключаются к единственной антенне. Поэтому для того, чтобы концентратор «не ловил» свои же отправленные пакеты как принятые или банально не накладывалась передача\приём (что у меня и происходило, поэтому и приём крайне паршивый), вполне логично их разделить по частоте на разные каналы, только вот в примере прошивки ping-pong для RAK811 я не нашел назначения разных частот для приёма\передачи (потому вначале и схитрил, установив одинаковые частоты Tx\Rx, по сути же эта прошивка — просто технический пример для двух RAK811, не более), а реализовано это все уже в примере конечного устройства Class A, для работы этого примера уже требуется сетевой сервер (а-ля The Things Network), который будет работать с концентратором, а концентратор уже будет работать с конечными устройствами\датчиками и, соответственно, принимать от них данные, и в итоге сетевой сервер так же работает с сервером приложения (грубо говоря, вашей программой, которая подключается к сетевому серверу, авторизуется и «слушает» авторизованные устройства), собирающего данные от различных шлюзов и оконечных устройств. Вот так примерно это выглядит:

B49-33

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

При тестировании двух модулей RAK811 я использовал жестко заданные параметры без адаптивной  скорости передачи данных ADR, хотя в LoRaWAN сети параметры оптимально корректируются сервером сети. Вот наглядная картинка зависимости параметров кодирования\скорости передачи данных\размера передаваемых данных\дальности работы:

B49-32

На ней наглядно видно, что с параметрами, которые по умолчанию заданы в примере ping-pongSF = 7, полоса = 125 кГц, для EU868 региона это соответствует Data Rate = 5 (из файла Region.h), дальность можно ожидать до 1 км. По факту в реальных условиях ещё ниже. Дополнительным подтверждением этому служат результаты измерений из статьи Возможности использования радиотрансиверов компании Semtech, в конце были проведены испытания дальности работы SX1272 (аналогичный трансивер установлен в модулях RAK811) и у них результаты в парке г. Москва получились аналогичны моим, полученными в пром.зоне г. Краснодар:

Цитата из статьи: Полученные данные свидетельствуют о достижении следующих результатов дальности связи: 300 м (полоса 125 кГц), 275 м (полоса 250 кГц) и 250 м (полоса 500 кГц).

Параметры аналогичны моим — SF = 7, скорость кодирования 4/5, полоса 125 кГц. У меня же (статья Обзор WISNode-LoRa) получились следующие результаты:

B35-21

Мои результаты измерений получились аналогичны результатам измерений, проведённым инженерами ЗАО «Московского научно-исследовательского телевизионного института». С одной стороны меня это радует, я таки не ошибся сильно в методике тестирования (у меня даже более жесткие условия были — не просто как приёмник\передатчик использовались модули, а одновременно принимали и отправляли ответ, и считались успешными пакеты, которые прошли туда и обратно, а не только в одну сторону), с другой стороны сами результаты не очень-то и впечатляют, когда рекламируются километры, а по факту сотни метров.

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

Вывод

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

И да, надеюсь, нет серьезных косяков по линуксу, т. к. я в нём нуб, и если нашли ошибки или знаете как что сделать лучше, буду рад комментариям! ;)

Ссылки

Что где скачать\почитать:

Не реферальные ссылки, что где купить:

  • RAK Shop — магазин RAK на площадке AliExpress;
  • RAK831 — только концентратор;
  • RAK831 Module Kit — концентратор с плюшками для разработчика;
  • Glass Fiber Antenna — более лучший вариант антенны для концентратора
  • IoT Solution Experience Kit — дорогой вариант всё-в-одном, чтобы поиграться абсолютно со всеми девайсами LoRa от RAKWireless.
Реклама

Рубрики: C/C++, Обзоры

Tagged as: , , , , , , , ,

6 Comments »

Добавить комментарий

Please log in using one of these methods to post your comment:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s