Записки IoT-провайдера. LoRaWAN і RS-485

Привіт, шановні любителі Інтернету Речей. Продовжую свій цикл статей.

Перша частина → Друга частина → Третя частина → Четверта частина → П’ята частина

Отже, ми навчилися працювати з імпульсним виходом лічильників і освоїли шифрування. Який крок наступний? Відповідь очевидна. RS-485.

Трохи теорії. RS-485 (Recommended Standard) – це асинхронний інтерфейс фізичного рівня. Отримав величезну популярність у Промисловому Інтернеті, починаючи від ЖКГ і закінчуючи різними заводами і підприємствами.

В принципі, майже будь-лічильник, який хоче передати нам не один, а кілька параметрів, швидше за все, буде забезпечений RS-485. Рідше RS-232 або M-Bus, але їх поки що залишимо осторонь і розберемо найбільш показовий приклад. Точніше проблеми в роботі з ним.

Проблема швидкості

RS-485 – провідний стандарт. LoRa – бездротова. Логічно, що має бути якийсь пристрій, здатне їх подружити.

Все вірно. Майже у кожного виробника оконечки в лінійці є радіомодуль з підтримкою RS-485. Працює за принципом прозорого каналу. Всі пакети, які ходять по дроту, упаковуються в якості корисного навантаження пакетів LoRaWAN і йдуть на передачу. Або приймаються і перетворюються в електричні імпульси.

І тут перша проблема. RS-485 – досить швидкісний інтерфейс. Пакети по ньому ходять зі швидкостями в декілька кілобіт/сек або навіть кілька десятків. Наприклад, одна з типових швидкостей Modbus – 9,6 кбіт/сек.

LoRa, навіть при найкращому SF=7 (125 кГц, 4/5) вичавить 5,5 кбіт/сек. З більш високими SF буде ще менше.

Це означає, що опитування значень якого-небудь електролічильника займе не секунди, і навіть не десятки секунд. Рахунок піде на хвилини. І це ще при правильно відрегульованому часу очікування. Якщо залишити налаштування за замовчуванням, ваш опитування, швидше за все, закінчиться помилкою тайм-ауту. Я вже мовчу про обмеження в довжині пакетів LoRaWAN. Там просто біда.

Проблема опитування

З імпульсними виходами все просто. Ми вважаємо імпульси, множимо їх на ціну поділки і отримуємо показання лічильника. З цим впорається будь простенький інтерфейс. І такий інтерфейс, крім простоти, буде ще універсальним.

З RS-485 все куди гірше. Дивно, але багато хто не розуміють однієї важливої речі.
RS-485 – це НЕ ПРОТОКОЛ ОБМІНУ! Він не обумовлює формат пакетів, які ходять всередині нього. По суті – це просто середовище передачі. Зазначені лише електричні та часові характеристики інтерфейсу. Всі! Все, що зверху вже треба розбирати окремо.

Читайте також  Цікавий JavaScript: Без фігурних дужок

А розбирати є що! Поверх нашої середовища кожен виробник може накрутити, що душі завгодно. Ну, або що виявилося зручно особисто йому. Приміром, теплолічильник ВКТ-7 буде спілкуватися з нами через ModBus. А Енергоміра – через ГОСТ Р МЕК 61107-2001.

Це всі протоколи, які накладаються на середовище передачі зверху і мають більш високий рівень. Кожен протокол має свій склад кадру, вимагає своїх команд на виконання тих чи інших дій, передбачає різне зберігання (а значить і опитування) значень. Отже, для кожного пристрою потрібен свій скрипт опитування. Більше того, навіть у рамках одного протоколу (той же ModBus) цей скрипт буде відрізнятися від пристрою до пристрою.

Самі по собі протоколи не є таємницею і, по більшій частині, відкриті. Більше того, сайт кожного виробника найчастіше містить безкоштовну утиліту, за допомогою якої можна прилади опитувати. Але ці утиліти не універсальні і заточені під одного виробника. А ми пам’ятаємо, що у нас майже завжди зоопарк пристроїв. І ставити клієнту на комп’ютер кілька програм одночасно… ну це не дуже зручно.

Виходу два. Або писати щось своє. Або взяти програму, в якій вже скомпільовані скрипти опитування найпопулярніших пристроїв. На ринку чимало готових рішень, скажімо «ЛЭРС-облік» або «ЯЭнергетик». Але вони платні і коштує хороших грошей. Як і розробка свого софта.

Крім того, якщо ми говоримо про Промисловий Інтернет (тобто виходимо за рамки ЖКГ) готові універсальні рішення вам вже не допоможуть. Як бути?

Аж ніяк.

Якщо ви все ще плануєте опитувати через LoRa по прозорому каналу, ви все одно упретеся в обмеження швидкості і таймаут. Може не відразу і не з першим пристроєм, але це станеться.

Проблема стандарту

Крім всіх бід, у нас є ще одна. Т. к. RS-485 передбачає, що ми можемо звернутися до пристрою в будь-який момент, радіомодуль LoRa з його підтримкою повинен бути класу С. тобто завжди слухати ефір і бути готовим відповісти.

Нагадаю, що клас З не передбачає батарейного живлення, але тут біда не настільки серйозна. Зазвичай, RS-485 знаходиться там, де зовнішнє живлення можна роздобути.

Гірше інше.

За законом, ми можемо працювати в двох частотних діапазонах. Пам’ятайте, обмеження в 864-865 МГц? Не більше 0,1 % часу в ефірі? Це означає, що кожне окремо взяте пристрій може перебувати в ефірі, припустимо, не довше 3,6 секунд на годину. Але за цей час, на SF=12 ми навіть три пакета не пропихнем.

Читайте також  Додаток на python kivy для різноманітності раціону харчування. Від коду і до отримання .apk файлу для Android

Можна спробувати вичавити максимум з каналів 868,7-869,2. Однак тут вступає в силу вже інше обмеження регіональних стандартів специфікації LoRaWAN – не більше 1 відсотка часу в ефірі для кожного кінцевого пристрою (duty cycle). ОК, вже легше, 36 секунд. Тільки толку все одно не особливо.

В якийсь момент, ми можемо сказати – та ну їх, ці дурниці! Буду сидіти в ефірі стільки, скільки потрібно! Але тут з’являється:

Проблема ємності ефіру

LoRa не дарма обмінюється короткими і рідкісними пакетами. По суті, навколо цього побудований весь стандарт. Потрібно, щоб кожен пристрій займало максимально мало часу в ефірі. Тоді ми знизимо ризик колізій і зможемо досягти тієї самої фантастичної щільності в кілька тисяч радимодулей на одну БС. Що ж буде, якщо один радіомодуль строчить пакетами як з кулемета? Його частота зайнята в момент передачі. А в момент відповіді зайняті взагалі всі частоти, т. к. базова станція нічого не чує, коли передає сама.

Зрозуміло, ніхто не відміняв заділи на збільшення ємності. Тобто якщо в зоні дії одного радіомодуля буде дві БС, відповідати буде все одно одна, а друга може почути якийсь інший пакет. Однак, ефір не гумовий. Якщо кожен радіомодуль буде займати хвилину на обмін пакетами, то в годину на одну БС ми зможемо повісити не більше 60 кінцевих пристроїв, це ще за умови відсутності колізій. Дуже мало, особливо якщо згадати, що радіус дії кожної БС в місті – близько 2 км, а може і більше.

Значить, немає?

Виходить, що наша мережа LoRaWAN обмежена тільки пристроями з імпульсним виходом і сторожовими системами, де реєструється факт спрацювання?

Немає.

Просто ми спробували використовувати концепцію Інтернету Людей там, де цього робити не можна. Погодьтеся, нам звично надмірно використовувати стабільний Інтернет-канал. Наприклад, відкрити відео, прихопивши запас в буфері, і не догледіти. Тобто трафік пройде, але по факту не буде використаний.

Однак, тут все інакше. Швидкості у нас мало часу в ефірі теж. Треба використати його економно. Що можна придумати?

Читайте також  Розробка гексапода своїми руками з нуля (частина 1)

Відповідь на поверхні. Не ганяти через LoRa купу службового трафіку протоколів поверх RS-485.

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

У цього методу є два мінуси:

  • Такий радіомодуль вимагає певних обчислювальних ресурсів. Це не велика проблема на поточному рівні розвитку технологій.
  • Такий радіомодуль споживає більше енергії. Але у випадку прозорого каналу ми змушені використовувати клас, який так само не від батарей живе. То на те й виходить.

Зате ми отримуємо всю необхідну нам інформацію в 2-3 пакетах. А то і в один все поміститься, якщо потрібно буквально кілька параметрів. Адже часто буває, що нам не потрібно передавати ВСЕ, досить обмеженого набору значень.

Радимодуль може передавати дані, припустимо, раз на годину. А на стороні сервера ми будемо складати їх у сховище. Якщо потрібно звернутися до архіву, то серверу навіть не доведеться опитувати пристрій.

Зрозуміло, що потрібно мати якийсь універсальний радіомодуль, який завантажуються різні скрипти. І інтерфейс, здатний сприймати таку інформацію. Це не простий шлях, але тільки він відповідає всім вимогам і обмеженням.

В даний момент, до цього рішення приходять все більше виробників. Готуються подібні пристрої у Веги, вже є у icbcom, ОРІОН М2М та інших.

Оскільки ми використовуємо самописний інтерфейс, то подібні розробки є і у нас. У якийсь момент стало ясно, що якщо не поліземо глибше, просто не зможемо працювати.

Крім хитрості з економією трафіку, як і раніше нам потрібна хороша мережа, в якій пристрої працюють на мінімальному SF і максимальної швидкості. Я підкреслю – не така мережа, у якій всі пристрої з SF=7. Ви цього все одно не доб’єтеся.

Така мережа, яка прагне до SF=7. Це означає грамотне планування і ADR.

На виході отримаємо достатні швидкості для ходіння пакетів, як і раніше велике число радіомодулів на одну БС і можливість працювати з інтерфейсами рівня вище імпульсного виходу. Що і потрібно було.

P. S. Колеги, я вдячний всім за зворотній зв’язок. Скажіть, що вам ще цікаво дізнатися про LoRaWAN або Інтернет Речей? Відповіді можете писати мені в лічку або в коментарях. По самим цікавим або масовим запитам будуть виходити статті.

Степан Лютий

Обожнюю технології в сучасному світі. Хоча частенько і замислююся над тим, як далеко вони нас заведуть. Не те, щоб я прям і знаюся на ядрах, пікселях, коллайдерах і інших парсеках. Просто приходжу в захват від того, що може в творчому пориві вигадати людський розум.

You may also like...

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *