Русский
Русский
English
Статистика
Реклама

Lora

Перевод Создаем собственный GPS-Трекер на технологии LoRa

07.11.2020 18:20:02 | Автор: admin


В этой статье вы узнаете, как создать собственный GPS-трекер с помощью микроконтроллеров Pycom LoPy, а также научитесь настраивать одноканальный LoRa Nano-Gateway.
Здесь я изложу ключевые этапы со всеми необходимыми ссылками.

Если вас интересуют подробное руководство и пояснения, то можете посмотреть видео запись моего выступления на технологическом подкасте IBM Developer Europe Crowdcast.

Начнем с общей схемы архитектуры, на которой показаны все компоненты, участвующие в процессе настройки трекера.

Узел LoPy служит в качестве GPS-устройства, отправляющего данные на LoRa Nano-Gateway.

Сам шлюз LoRa подключен к TheThingsNetwork по WiFi.

В конечном итоге мы получим Node-RED, выполняющийся в IBM Cloud, который будет принимать MQTT сообщения от TheThingsNetwork, сохранять их в базе данных Cloudant и отображать точки GPS-данных на карте.

Оборудование:


1 LoPy в качестве узла LoRa + антенна (868MHz/915MHz) + аккумулятор 3.7V LiPo;
Последовательный GPS-модуль 1 uBlox NMEA с антенной;
1 LoPy в качестве LoRa Nano-Gateway + антенна (868MHz/915MHz);
2 платы расширения Pycom.

Ссылки на используемое оборудование здесь: pycom.io/products/hardware

Программная часть:


Для программирования микроконтроллеров LoPy мы будем использовать Pymakr плагин для редакторов Atom и VS Code.

LoPy от Pycom.io это мульти-сетевой аппаратный модуль на базе микроконтроллера ESP32. Большинство из используемых в нем функций и библиотек собраны на MicroPython.

1. Настройка LoRaWAN Nano Gateway и подключение к TheThingsNetwork


Исходный код для LoRaWAN Nano-Gateway ждет вас здесь.

Распакуйте скачанный файл, после чего найдите каталог lorawan-nano-gateway в директории examples.

Все подробности по настройке Nano-Gateway изложены в следующей ссылке.

Следуя этому руководству, вы определите шлюз в TheThingsNetwork, настроите параметры конфигурации в соответствии с вашим регионом, загрузите код на плату и убедитесь в ее работоспособности через консоль TheThingsNetwork.

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

2. Настройка LoRa-узла с GPS-трекером


Приступаем к работе с The Things Network:
core-electronics.com.au/tutorials/pycom/getting-started-on-the-things-network-tutorial.html

Следуйте инструкциям TheThingsNetwork для регистрации и активации вашего устройства LoPy.

Есть два способа активации LoPy: либо через OTAA (активация по воздуху), либо ABP (активация путем персонализации). Первый вариант считается предпочтительным, если вы используете несколько устройств, но не подойдет для работы с LoRa Nano-Gateway.

Следующий образец кода использует активацию ABP и после установки LoRa-соединения отправляет 10 байт в виде 10 отдельных пакетов.

1 from network import LoRa2 import binascii3 import struct4 lora = LoRa(mode=LoRa.LORAWAN)5 dev_addr = struct.unpack(">l", binascii.unhexlify('XXXXXXX'))[0]6 nwk_swkey = binascii.unhexlify('XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')7 app_swkey = binascii.unhexlify('XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX')8 # удаляем все каналы кроме предустановленных9 for i in range(3, 16):10       lora.remove_channel(i)11 # настраиваем 3 предустановленных канала на одну частоту12 lora.add_channel(0, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)13 lora.add_channel(1, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)14 lora.add_channel(2, frequency=config.LORA_FREQUENCY, dr_min=0, dr_max=5)15 # подключаемся к сети с помощью ABP 16 lora.join(activation=LoRa.ABP, auth=(dev_addr, nwk_swkey, app_swkey))17 # создаем сокет LoRa18 s = socket.socket(socket.AF_LORA, socket.SOCK_RAW)19 # устанавливаем скорость обмена данными LoRaWAN20 s.setsockopt(socket.SOL_LORA, socket.SO_DR, config.LORA_NODE_DR)21 # делаем сокет неблокирующимся22 s.setblocking(False)23 for i in range (10):24    pkt = b'PKT #' + bytes([i])25    print('Sending:', pkt)26    s.send(pkt)27    time.sleep(4)28    rx, port = s.recvfrom(256)29    if rx:30        print('Received: {}, on port: {}'.format(rx, port))31    time.sleep(6)

Теперь узел LoRa настроен, и мы должны увидеть поступающие пакеты как через консоль Nano-Gateway, так и в консоли TheThingsNetwork.

Далее мы можем добавить код для считывания фиксированных данных о местоположении GPS.
Образец этого кода лежит здесь.

В данном примере мы используем библиотеку adafruit_gps и отправляем пакет данных только, когда устанавливаем фиксированное местоположение GPS.

Это, конечно, здорово, но все полученные нами данные в байтах. Как же их перевести в доступный для использования формат? Конечно же декодировать.

Направляйтесь в консоль TheThingsNetwork и выберите ваше приложение, в котором перейдите во вкладку Payload Formats и определите декодер, не забыв также сохранить его.

1 function Decoder(bytes, port) { 2   console.log(bytes)3   return {4       GPSCoordinates: String.fromCharCode.apply(null, bytes)5   };6 }

Теперь, когда наш GPS-трекер подключен через LoRaWAN, перейдем к самому интересному, а именно настроим сохранение в БД и начнем показывать данные на карте.

Этот процесс я привык реализовывать в среде IBM Cloud при помощи Node-RED.
Здесь можно быстро и легко зарегистрировать бесплатный Lite-аккаунт.

По умолчанию потоки Node-RED сохраняются в БД Cloudant, поэтому можно без проблем использовать эту же БД для сохранения наших GPS-данных.

Образец потока Node-RED находится здесь.

GPS-данные через MQTT собираются с TheThingsNetwork и сохраняются в Cloudant.

Для получения этих данных вам потребуется создать/сгенерировать новый ключ доступа. Снова направляйтесь в консоль TheThingsNetwork и выберите свое приложение, перейдите во вкладку settings и найдите среди прочих настроек access keys. Сгенерированный ключ будет находиться в нижней части страницы окна просмотра приложения.

Более подробное о взаимодействии MQTT с TheThingsNetwork рассказано здесь.

Заключение


Эта статья поможет вам лучше ознакомиться с основами использования Интернета Вещей (IoT) при помощи LoRa-соединения.

Если вам не терпится увидеть все это в действии, то еще раз напомню про свое выступление на технологическом подкасте IBM Developer Europe Crowdcast.

В этом видео я также показываю, как подключить LoRa GPS-трекер к публичному бельгийскому провайдеру этой технологии Proximus.

А какие еще, на ваш взгляд, есть варианты применения LoRa для Интернета Вещей?



Подробнее..

Снова о автономной Arduino-метеостанции на батарейках

03.03.2021 00:13:52 | Автор: admin

Еще донедавна мне не удавалось найти в Интернете любительскую метеостанцию с питанием от батареек. Я имею ввиду бытовую автономную метеостанцию с измерениями параметров в помещении, на улице и отображением информации на дисплее метеостанции. Любители не заморачиваются на этой проблеме, а питают свои автономные девайсы от солнечных батарей, аккумуляторов и т.п. Уточню проблема касается только одного из узлов метеостанции базы, а первые проекты малогабаритных беспроводных автономных выносных датчиков на Ардуино появились 10 лет назад. Вместе с тем, промышленные устройства такого плана бытовые метеостанции, комнатные термостаты годами работают от пары батареек АА и этот факт является той целью, которой хотелось бы достичь.


Это было донедавна. Несколько дней назад меня поразил очередной проект @Berkseo, как поражают все его проекты: "Беспроводная мини погодная станция с e-paper экраном на батарейках". Тут все на уровне промышленного продукта. Удивляет единственное в устройстве нет внешнего датчика.


Год назад разместил статью Автономная метеостанция на контроллере ATMEGA328P и питанием от батареек с беспроводным выносным датчиком. Хотя прототип и выполнял свои функции, но имел серьезные недостатки слишком малая частота обновления данных и большое энергопотребление. Ниже другой вариант метеостанции с новым алгоритмом, элементной базой и кодом с низкоуровневыми вставками. Все это позволило выйти на время работы метеостанции от одного комплекта батареек даже несколько больше, чем гарантируют производители некоторых товаров такого плана.



Что сделано:


Датчики DHT22 и DS18B20, которые использовались в предыдущем проекте, заменены энергосберегающим модулем это датчик температуры и влажности HTU21D. Период измерений, отправки/приема данных уменьшен с 15-ти мин до 53,5 сек. Сделан переход на устойчивую частоту работы контроллера (8 МГц) при напряжении питания ниже 3В. Для уменьшения объемов занимаемой памяти в скетчах использованы некоторые функции С/С++. И главное, принципиально изменен алгоритм передачи пакетов с выносного датчика и алгоритм приема этих пакетов базой метеостанции. Теперь для обеспечения надежного приема пакетов с выносного датчика в нем формируется и отправляется с интервалом около 0,3 сек не один, а три пакета с данными о параметрах воздуха на улице и состоянии батареек. Только после отправки третьего пакета контроллер в. датчика вместе с периферией уходит в сон. База метеостанции уходит спать после приема одного из 6-ти пакетов с выносного датчика и просыпается за полсекунды до поступления очередной серии пакетов с выносного датчика.


Метеостанция состоит из двух автономных узлов с питанием от двух батареек AA: базы и выносного датчика. Назовем их для простоты анализатором (по-другому база) и беспроводным в.датчиком (выносным датчиком).


Анализатор, построен на контроллере ATMEGA328P, измеряет температуру и влажность (датчик температуры и влажности HTU21D) в помещении, а также измеряет и анализирует величину напряжения питания узла, которое обеспечивают две батарейки АА 1,5 В. На контроллер также поступает сигнал с приемника LoRa, который по эфиру принимает информацию с выносного датчика. Вся инфа с контроллера выводится на ЖК-дисплей NOKIA 5110.


В в.датчике, тоже собранном на контроллере ATMEGA328P, измеряется температура и влажность воздуха на улице (модуль HTU21D), а также напряжение питания выносного узла, организованного на двух батарейках АА 1,5 В. Передатчик LoRa этого узла передает инфу о температуре, влажности и состоянии батарейки на анализатор. С в.датчика выполняется отправка 3-х пакетов с интервалом около 0,3 сек, затем контроллер ATMEGA328P, передатчик LoRa и модуль HTU21D для экономного расходования заряда батареек переводятся в режим сна. Измерения и отправка данных с в.датчика выполняется с циклом несколько меньше 1-ой минуты.


Работа анализатора построена по следующему алгоритму:


Вначале, при включении обеих узлов метеостанции, контроллер анализатора подает команды на измерение температуры и влажности внутри помещения и выводит эти параметры на дисплей, затем устанавливает приемник LoRa в режим прослушивания эфира. После приема сигнала с в.датчика и успешной дешифрации принятых данных контролер подает команду на повторное измерение температуры, влажности и выводит инфу в полном объеме на экран. Затем анализатор уходит в сон, просыпаясь примерно за полсекунды до планируемого поступления сигнала с в.датчика. Приняв и дешифровав один из трех пакетов с в.датчика, повторно выполняет свои измерения, выводит информацию на экран и снова уходит спать. Если по каким-то причинам сигнал с в.датчика отсутствует около одной минуты (например, сели батарейки), что по времени соответствует отправке 6-ти пакетов с в.датчика, анализатор проводит измерения только в помещении, изредка сканируя эфир: а вдруг в.датчик появился в эфире?! Это сделано для того, чтобы постоянно работающий на прием модуль LoRa не посадил за короткое время батарейки анализатора.


Для сборки устройства понадобятся радиодетали:


  1. Контроллер ATMEGA328P-PU 2 шт.
  2. Датчик влажности и температуры HTU21D/SHT21/Si7021 2 шт.
  3. ЖК-дисплей NOKIA 5110 1 шт.
  4. Приемник-передатчик LoRa Rа-01 2 шт.
  5. Макетная плата (стеклотекстолит), монтажные провода, батарейки АА, кварцевые резонаторы 8 МГц, резисторы, конденсаторы, другие мелочи.

Ориентировочная стоимость компонентов по ценам AliExpress примерно $25.


Для работы с контроллерами ATMEGA328P в качестве программатора я использую плату Arduino UNO. На Youtube есть хорошее видео по установке загрузчика и загрузки скетчей в контроллер ATMEGA328P с помощью платы Arduino UNO.


На этот раз мы не будем устанавливать новые фьюзы программой SinaProg, а воспользуемся, на мой взгляд, более универсальным способом созданием новых конфигураций плат в платформе Arduino IDE.


В новые контроллеры надо установить загрузчик Arduino as ISP и надо учитывать то, что контроллеры ATMEGA328P поступают в продажу с заводской настройкой фьюз для мониторинга (контроля) напряжения питания не ниже 2,7 В. Мы же будем работать от батареек, напряжение на которых при разряде может быть ниже установленного заводского порога 2,7 В, и с кварцем 8 МГц. Установим загрузчик и изменим фьюзы под наши условия, используя в качестве программатора плату Arduino UNO, в такой последовательности:


  1. Найти по адресу c:\Program Files\Arduino\hardware\arduino\avr\ файл boards.txt и открыть его текстовом редакторе с форматированием, например, AkelPad.
  2. Дополнить файл блоком, который приведен под спойлером, и сохранить файл.

    блок установок 1
    ##############################################################

    amega.name=Mega Low (8 MHz, >1.8V)

    amega.upload.tool=avrdude
    amega.upload.protocol=arduino
    amega.upload.maximum_size=32256
    amega.upload.maximum_data_size=2048
    amega.upload.speed=57600

    amega.bootloader.tool=avrdude
    amega.bootloader.low_fuses=0xFF
    amega.bootloader.high_fuses=0xDA
    amega.bootloader.extended_fuses=0xFE
    amega.bootloader.unlock_bits=0x3F
    amega.bootloader.lock_bits=0x0F
    amega.bootloader.file=optiboot/optiboot_atmega328.hex

    amega.build.mcu=atmega328p
    amega.build.f_cpu=8000000L
    amega.build.board=AVR_UNO
    amega.build.core=arduino
    amega.build.variant=standard

  3. В плату Arduino UNO загрузить скетч ArduinoISP.ino из примеров платформы Arduino IDE (Файл > Примеры > ArduinoISP).
  4. Собрать схему (плата Arduino UNO, контроллер ATMEGA328P, кварц 16 МГц) для установки в контроллер загрузчика ArduinoISP (инструкции тут), подключить ее компьютеру и записать в контроллер бутлоадер Arduino as ISP.
  5. Заменить кварц в схеме 16 МГц на 8 Мгц. В меню ИНСТРУМЕНТ выбрать из списка плату Mega Low (8 MHz, >1.8V), которая появилась в меню после дополнения файла boards.txt новым блоком, выбрать тут же Программатор: Arduino as ISP и, нажав Записать загрузчик изменить фьюзы и другие установки в контроллере.
  6. Далее загружаем в контроллер необходимый скетч, используя ту же схему, что и для установки загрузчика (п.4), через Скетч > Загрузить через программатор.

Выносной датчик


В.датчик построен на контроллере ATMEGA328P. В нем осуществляется прием данных с HTU21D по протоколу I2C, измерение и анализ величины напряжения питания узла и управление передатчиком LoRa.


скетч в.датчика
/*   Снова о автономной Arduino-метеостанции на батарейках, выносной датчик   http://personeltest.ru/aways/habr.com/ru/post/544936/*/#include <avr/io.h>#include <util/delay.h>#include <SPI.h>#include <LoRa.h>#include <LowPower.h>#include <Wire.h>#include <avr/power.h>#include "HTU21D.h"#define VccHTU 8  //питание и подтяжка HTU21D (pin 14 AtMega328P, D8)HTU21D myHTU21D;float Tout; // температураint Hout;  // влажностьunsigned int sleepCounter, sleepCounter0; // счетчик, задающий время снаint pct;  //счетчик числа пакетов перед уходом в сонString messageOut; // LoRa-сообщениеfloat BatOut; // напряжение батареекconst int batteryPin = A0; // pin 23 (Atmega328P), к которому подключена батарея для измерения напряженияconst float typVbg = 1.132; //калибровачная константа, 1.0 - 1.2int counter = 0;// измерение опорного напряженияfloat readVcc() {  byte i;  float result = 0.0;  float tmp = 0.0;  for (i = 0; i < 1; i++) {    // Read 1.1V reference against AVcc    // set the reference to Vcc and the measurement to the internal 1.1V reference#if defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)    ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);#elif defined (__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)    ADMUX = _BV(MUX5) | _BV(MUX0);#elif defined (__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)    ADMUX = _BV(MUX3) | _BV(MUX2);#else    // works on an Arduino 168 or 328    ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);#endif    _delay_ms(3); // Wait for Vref to settle    ADCSRA |= _BV(ADSC); // Start conversion    while (bit_is_set(ADCSRA, ADSC)); // measuring    uint8_t low  = ADCL; // must read ADCL first - it then locks ADCH    uint8_t high = ADCH; // unlocks both    tmp = (high << 8) | low;    tmp = (typVbg * 1023.0) / tmp;    result = result + tmp;    _delay_ms(5);  }  return result;}void Measurement () {  // измерение температуры и влажности  Hout = myHTU21D.readHumidity();  Hout = 62;  //delete!  float Tout_p = myHTU21D.readTemperature();  Tout = 0.1 * int(Tout_p * 10 + 0.5);  //округление до десятых  // измерение напряжения батареек  BatOut = 0.1 * int(readVcc() * 10 + 0.5);  if (BatOut < 2.2) {    BatOut = 0.0;  } else {    BatOut = 2.2;  }}void SendMessage () {  // отправка данных (температура, влажность, состояние батареек)  if (BatOut > 2.1) {    messageOut = String(Tout) + "#" + String(Hout) + "$" + String("BGood");  }  else {    messageOut = String(Tout) + "#" + String(Hout) + "$" + String("BLow");  }  LoRa.beginPacket();  LoRa.print(messageOut);  LoRa.endPacket();}void setup() {  Serial.begin(9600);  Serial.println("Power ON");  analogReference(DEFAULT);  pinMode(VccHTU, OUTPUT);  digitalWrite(VccHTU, 1);  _delay_ms(200);  myHTU21D.begin();  int counter = 0;  while (!LoRa.begin(433E6) && counter < 10) {    Serial.println("Не удалось найти LoRa-передатчик!");    counter++;    _delay_ms(500);  }  LoRa.setTxPower(4); //мощность передатчика, 2...20 дБ  LoRa.setSyncWord(0xF3);}void loop() {  digitalWrite(VccHTU, 1);  if (pct < 3)  { // измерения, отправка пакетов    Serial.println(messageOut);    Measurement ();    SendMessage ();  } else {// измерения, отправка пакета и длительный сон    Serial.println(messageOut);    Serial.println("sleep ...");    Measurement ();    SendMessage ();    for (sleepCounter = 6; sleepCounter > 0; sleepCounter--)    {      digitalWrite(VccHTU, 0);      digitalWrite(VccHTU, 1);      LoRa.sleep ();      LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);    }    pct = 0;  }  pct++;  if (pct >= 3) pct = 3; //защита от переполнения счетчика}int main() {  init();  setup();  for (;;) {    loop();  }}

Электрическая схема в.датчика:



Питание и подтяжка выводов модуля HTU21D осуществляется с пина 14 контроллера ATMEGA328P. Это сделано для того, чтобы программно обнулить питание HTU21D и перевести этот датчик в режим низкого энергопотребления во время сна.


Изначально в схеме в.датчика планировалось использовать барометр-термометр BMP280, но мне не удалось программно перевести BMP280 в режим низкого потребления во сне. Хотя по даташиту BMP280 для перехода в режим низкого потребление требуется, как и для HTU21D, кратковременное обнуление питания. Разрыв питания BMP280 во время сна снижает потребляемый ток в схеме ATMEGA328P + BMP280 с 130 мкА до 5 мкА, но, повторюсь, смоделировать этот разрыв питания программно у меня пока не получилось.


В в.датчике формируется и отправляется с интервалом около 0,3 сек три пакета с данными о температуре и влажности на улице и состоянии батареек. Если напряжение на батарейках выше установленного порога (2,2 В), то в коде пакета присутствует BGood, а ниже BLow. После отправки третьего пакета контроллер в.датчика вместе с периферией уходят в сон. Цикл отправки серий пакетов 53,5 сек.


Анализатор


Мозг анализатора контроллер ATMEGA328P. Он принимает сигналы с датчика HTU21D по протоколу I2С и по SPI взаимодействует с приемником LoRa и дисплеем NOKIA 5110.


скетч в.датчика
/*   Снова о автономной Arduino-метеостанции на батарейках, анализатор   http://personeltest.ru/aways/habr.com/ru/post/544936/*/#include <avr/io.h>#include <util/delay.h>#include <SPI.h>#include <LoRa.h>#include <LowPower.h>#include "HTU21D.h"#include <LCD5110_Graph.h>#define VccHTU 8  //питание и подтяжка HTU21D(pin 14 AtMega328P, D8)HTU21D myHTU21D;float Tin; // температура в помещенииint Hin;  // влажность в помещенииLCD5110 myNokia(3, 4, 5, 6, 7);extern uint8_t SmallFont[];extern uint8_t MediumNumbers[];float BatIn = 0; // напряжение батареиconst int batteryPin = A0; // pin 23(Atmega328P), к которому подключена батарея для измерения напряженияconst float typVbg = 1.132; //калибровачная константа, 1.0 - 1.2unsigned int sleepCounter;  //счетчик, задающий время снаint r; //счетчик циклов прослушивания эфираint mlc;  //счетчик циклов работы без в.датчикаString LoRaData, Tout_str, Hout_str, BatIn_str, BatOut_str;// измерение напряжения батареекfloat readVcc() {  byte i;  float result = 0.0;  float tmp = 0.0;  for (i = 0; i < 1; i++) {    // Read 1.1V reference against AVcc    // set the reference to Vcc and the measurement to the internal 1.1V reference#if defined(__AVR_ATmega32U4__) || defined(__AVR_ATmega1280__) || defined(__AVR_ATmega2560__)    ADMUX = _BV(REFS0) | _BV(MUX4) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);#elif defined (__AVR_ATtiny24__) || defined(__AVR_ATtiny44__) || defined(__AVR_ATtiny84__)    ADMUX = _BV(MUX5) | _BV(MUX0);#elif defined (__AVR_ATtiny25__) || defined(__AVR_ATtiny45__) || defined(__AVR_ATtiny85__)    ADMUX = _BV(MUX3) | _BV(MUX2);#else    // works on an Arduino 168 or 328    ADMUX = _BV(REFS0) | _BV(MUX3) | _BV(MUX2) | _BV(MUX1);#endif    _delay_ms(3); // Wait for Vref to settle    ADCSRA |= _BV(ADSC); // Start conversion    while (bit_is_set(ADCSRA, ADSC)); // measuring    uint8_t low  = ADCL; // must read ADCL first - it then locks ADCH    uint8_t high = ADCH; // unlocks both    tmp = (high << 8) | low;    tmp = (typVbg * 1023.0) / tmp;    result = result + tmp;    _delay_ms(5);  }  return result;}void Measurement() {  float Tin0;  // измерение напряжения батареи:  BatIn = readVcc();  // измерение температуры  и влажности в помещении  Hin = myHTU21D.readHumidity();  // Hin = 58; // delete!  float Tin_p = myHTU21D.readTemperature();  Tin = 0.1 * int(Tin_p * 10 + 0.5);  //округление до десятых  //  Tin = 21.4; // delete!}void draw() {  myNokia.enableSleep();  myNokia.clrScr();  //Tin  char chr_Tin [5];  String Tin_str = String(Tin);  myNokia.setFont(SmallFont);  myNokia.print("            C", LEFT, 0);  myNokia.print("In", LEFT, 8);  myNokia.setFont(MediumNumbers);  Tin_str.toCharArray(chr_Tin, 5); //количество знаков+1  myNokia.print(String(chr_Tin), CENTER, 0);  //Tout  char chr_Tout [5];  myNokia.setFont(SmallFont);  myNokia.print("            C", LEFT, 16);  myNokia.print("Out", LEFT, 24);  myNokia.setFont(MediumNumbers);  Tout_str.toCharArray(chr_Tout, 5);  myNokia.print(String(chr_Tout), CENTER, 16);  // Hin, Hout  char chr_Hout [5];  Hout_str.toCharArray(chr_Hout, 4);  myNokia.setFont(MediumNumbers);  myNokia.print(String(Hout_str), RIGHT, 32);  myNokia.setFont(SmallFont);  myNokia.print("    In Out", LEFT, 40);  myNokia.print("      %", LEFT, 32);  myNokia.setFont(MediumNumbers);  myNokia.print(String(Hin), LEFT, 32);  myNokia.setFont(SmallFont);  // Battery Level  if (BatIn < 2.2) {    myNokia.setFont(SmallFont);    myNokia.print("Bat", LEFT, 0);  }  if (BatOut_str == "BLow") {    myNokia.setFont(SmallFont);    myNokia.print("Bat", LEFT, 16);  }  myNokia.disableSleep();  _delay_ms(5);}void drawStart() {  myNokia.enableSleep();  myNokia.clrScr();  //Tin  char chr_Tin [5];  String Tin_str = String(Tin);  myNokia.setFont(SmallFont);  myNokia.print("            C", LEFT, 0);  myNokia.print("In", LEFT, 8);  myNokia.setFont(MediumNumbers);  Tin_str.toCharArray(chr_Tin, 5); //количество знаков+1  myNokia.print(String(chr_Tin), CENTER, 0);  // Battery Level  if (BatIn < 2.2)  {    myNokia.setFont(SmallFont);    myNokia.print("Bat!", RIGHT, 28);  }  //Hin  myNokia.setFont(SmallFont);  myNokia.print("         %", LEFT, 18);  myNokia.print("In", LEFT, 28);  myNokia.setFont(MediumNumbers);  myNokia.print(String(Hin), CENTER, 18);  //No signal!  myNokia.setFont(SmallFont);  myNokia.print("Out - - -", CENTER, 40);  myNokia.update();  myNokia.disableSleep();  _delay_ms(5);}void setup() {  Serial.begin(9600);  pinMode(VccHTU, OUTPUT);  digitalWrite(VccHTU, 1);  Serial.println("Power ON!");  analogReference(DEFAULT);  // инициализация дисплея  myNokia.InitLCD();  myNokia.setFont(SmallFont);  myNokia.clrScr();  myNokia.print(">>>>>", CENTER, 20);  myNokia.update();  _delay_ms(1000);  myNokia.setFont(SmallFont);  myNokia.clrScr();  myNokia.print("))-->", CENTER, 20);  myNokia.update();  if (!LoRa.begin(433E6)) {    Serial.println("Ошибка загрузки LoRa-приемника!");    while (1);    myNokia.setFont(SmallFont);    myNokia.clrScr();    myNokia.print(" ->  ->", CENTER, 20);    myNokia.update();  }  // Диапазон для синхрослова  между "0-0xFF".  LoRa.setSyncWord(0xF3);  Serial.println("Прослушивание эфира. Ожидание пакета с в.датчика ...");  myHTU21D.begin();  Measurement();  drawStart();  digitalWrite(VccHTU, 0);  _delay_ms(1000);  myNokia.clrScr();  myNokia.print("Waiting", CENTER, 10);  myNokia.print("Message from", CENTER, 22);  myNokia.print("OUTSIDE", CENTER, 34);  myNokia.update();}void loop() {  r++;  digitalWrite(VccHTU, 1);  if (r < 600)  // 8 MHz;  {    mlc = 0;    // Прослушивание эфира, прием, дешифрация, если сигнал с в.датчика принят,    // то измерения в помещении, вывод инфы на экран и - в спячку.    {      int packetSize = LoRa.parsePacket();      if (packetSize) {        while (LoRa.available()) {          LoRaData = LoRa.readString();        }        int pos1 = LoRaData.indexOf('#');        int pos2 = LoRaData.indexOf('$');        Tout_str = LoRaData.substring(0, pos1);        Hout_str = LoRaData.substring(pos1 + 1, pos2);        BatOut_str = LoRaData.substring(pos2 + 1, LoRaData.length());        if ((LoRaData).substring(pos1, pos1 + 1) == "#") {          Serial.println("Принято, декодировано! r = " +  String(r));          r = 0;          Measurement();          draw();          digitalWrite(VccHTU, 0);          // sleepCounter = 49; 16 MHz          // sleepCounter = 48; 8 MHz          for (sleepCounter = 48; sleepCounter > 0; sleepCounter--)          {            digitalWrite(VccHTU, 1);            LoRa.sleep ();            LowPower.powerDown(SLEEP_1S, ADC_OFF, BOD_OFF);          }        }      }    }  } else {    r = 600;    if (mlc < 250) //4 часа, время работы без датчика    {      Serial.println("Работа без в.датчика.");      LoRa.sleep ();      Measurement();      drawStart();      digitalWrite(VccHTU, 0);      for (sleepCounter = 6; sleepCounter > 0; sleepCounter--)      {        digitalWrite(VccHTU, 1);        LowPower.powerDown(SLEEP_8S, ADC_OFF, BOD_OFF);      }      mlc++;    } else {      r = 0;      mlc = 0;    }  }  _delay_ms(110); }int main() {  init();  setup();  for (;;) {    loop();  }}

Работа анализатора начинается в setup'e с инициализации модулей, измерения параметров воздуха, анализа напряжения на батарейках и вывода этой инфы на дисплей. Далее уже в loop'e прослушивается эфир приемником LoRa. После приема и дешифрации сигнала с в.датчика повторно проводятся измерения, анализа напряжения на батарейках и вывод измеренной и принятой инфы на дисплей. Выполнив эту работу все элементы схемы уходят поспать примерно на полсекунды меньше, чем период отправки пакетов с в.датчика. В следующем цикле контроллер просыпается и включает приемник приблизительно за 0,5 сек до ожидаемого прихода сигнала с в.датчика. Таким образом, контроллер и периферия анализатора работают около полсекунды с периодом (циклом) меньше минуты (53,5 сек). Если радиосигнал с в.датчика не поступает на приемник анализатора на протяжении приблизительно одной минуты (время, достаточное для приема одного из 6-ти пакетов), то анализатор переходит в режим работы без в.датчика на 4 часа, измеряя параметры воздуха и оценивая состояние батареек только в помещении с индикацией на дисплее этих данных. Период обновления данных в режиме работы без в. датчика 56,7 сек. В конце четырехчасового цикла работы анализатора без в.датчика он прослушивает эфир: а вдруг в.датчик снова в эфире?




Для перевода модуля HTU21D в режим низкого энергопотребления во время сна его питание также, как и в в.датчике, организовано с контроллера ATMEGA328P (пин 14).


В целом, на дисплее анализатора видна такая картинка:



Дисплей из-за низкого разрешения и малого размера экрана плотно забит символами. Эта картинка смотрелась бы намного лучше на современном дисплее с электронными чернилами. В будущем в своих проектах буду использовать e-paper дисплей.


Ресурс батареек и другое


Для расчета срока работы батареек понадобится время и потребляемый ток во время выполнения работы (операционное время) и сна. Операционное время и рабочий ток измерялись с использованием тестовых скетчей, идея которых взята отсюда.


Рабочий ток измерялся с использованием тех же тестовых скетчей. Для исключения разрывов цепи питания или значительного увеличения величины выходного сопротивления батареек можно использовать шунт 3,9...5,6 Ом и параллельно подключенный к нему цифровой мультиметр с механическим переключением в режиме вольтметра на диапазоне 2000 мкВ. Это критично при измерении потребления тока сна анализатора, поскольку разрыв питания или значительное ограничение тока приводят к цикличесому ресету анализатора. Да и выносной датчик может переходить в постоянный рестарт. По мере возможности необходимо проверять ток потребления разными способами на разных диапазонах шкал прибора и с батарейками, которые планируется использовать, притом, обязательно без вывода результатов на монитор порта Ардуино. Невыполнение этих правил сказались на результатах измерений тока в предыдущем моем посте на тему метеостанции в одних случаях они занижены, в других завышены.


Результаты измерений сведены в таблицу:


в.датчик анализатор
Операционное время функции измерений параметров воздуха, состояния батареек 0,25 сек 0,39 сек
Операционный ток функции измерений параметров воздуха, состояния батареек 3,4 мА 3,5 мА
Операционное время функции передачи/приема сигнала 42 мсек 83 мсек
Операционный ток функции передачи/приема сигнала 30,0 мА

(4 дБ)


11,5 мА
Ток сна 10 мкА 190 мкА

Что бросается в глаза, глядя на эту таблицу. Операционный ток передачи сигнала 30,0 мА при мощности передатчика LoRa 4 дБ. Для сравнения, ток передачи для модуля nRF24L01 13,5 мА. Вывод очевиден: надо переходить на nRF24L01, но не все так просто.


В режиме приемника в nRF24L01 используется так называемыйLNA (малошумящий усилитель). Разработчик библиотеки предполагает, что нет никакого программного обеспечения, которое могло бы повлиять на режим LNA.В режиме приема модуль постоянно демодулирует сигнал для поиска входящего пакета. Именно по этой причине Berkseo не поставил внешний датчик. У меня задача, вроде, попроще организовать режим сна с библиотекой LowPower.h. Сомневаюсь, что задача имеет решение. Буду благодарен за ваши мнения на этот счет.


Средний ток потребления по данным таблицы в. датчика 0,13 мА. Емкости батареек типа АА GP Litium для выносного датчика должно хватить на 2,5 года.


Средний ток потребления анализатора 0,27 мА. Ресурс батареек АА GP Litium в анализаторе 1,2 года. Для беспроводного комнатного термостата Computherm Q7RF, например, срок действия батареек: около 1 года.


Еще на тему энергопотребления долго копался в этой теме и хочется выговориться.


Составил код на С в Atmel Studio и эмулировал его в Proteus'е для для барометра-термометра.



На картинке ниже показаны результаты сравнения кода для одного и того же устройства на языке С и в среде разработки Arduino IDE.



Объем флеш-памяти, занимаемой в коде в Ардуино 12968 байт, на С 5954 байта и оценочно на Ассемблере не больше 200 байт.


Из этих чисел сделал несколько выводов, в которых убедился на собственном опыте:
Код на Ассемблере уменьшает размер памяти на порядки. Соответственно пиковое потребление падает в сотни раз. С десятков миллиампер при прошивках контроллеров устройств на Ардуино или С, С++ до десятых миллиампера на Ассембере.
Поиск компромисса. Так благодаря использованию компилируемых в Arduino IDE библиотек и функций на С/С++ в некоторых скетчах этого поста удалось уйти от предупреждения: Недостаточно памяти, программа может работать нестабильно. Притом, чем проще код, тем выше соотношение: размер памяти в Arduino IDE к памяти на С/С++. Для простейшего кода мигания светодиодом в несколько строк это соотношение составит 6 раз, а проигрыш в производительности 28 раз.


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


И, наконец, искренне благодарю AlexanderS, который донес до меня идею виртуальной шкалы времени или синхронизации, а также других участников обсуждения статьи Автономная метеостанция на контроллере ATMEGA328P и питанием от батареек с беспроводным выносным датчиком (ittakir, Javian, smart_alex, Polaris99, gerasimenkoao, igrushkin, enjoyneering) за предложения, конструктивную критику и замечания.


Спасибо, кто дочитал. Всем отличного иммунитета во времена коронавируса и не только.


Ссылки по теме


Узел беспроводного датчика с низким энергопотреблением


Беспроводная мини погодная станция с e-paper экраном на батарейках


Превращаем Arduino в полноценный AVRISP программатор


LoRa и сон


Узнайте о битах конфигурации ATmega328P и о том, как использовать их с внешним кварцевым резонатором


Калькулятор фьюзов AVR


Почему многие не любят Arduino

Подробнее..

Использование LoRa для интеграции кота в IoT

09.05.2021 16:23:04 | Автор: admin
Duivendrecht, вид на ферму и церковьDuivendrecht, вид на ферму и церковь

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

А в дом с садом просто необходимы коты.

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

Поэтому через некоторое время у нас появился Барсик, по паспорту Эскобар.

Эскобар - британский голубой кот, который своё имя оправдывает полностью. Способен находить лазейки и убегать практически из любых ситуаций.Эскобар - британский голубой кот, который своё имя оправдывает полностью. Способен находить лазейки и убегать практически из любых ситуаций.

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

Вариант превратить сад в клетку не устраивал никого. Вариант через некоторое время расклеивать объявления про потерянного кота, или же найти Барсика раскатанного по асфальту - тоже не казался слишком привлекательным.

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

Протестированы были устройства Invoxia, Findster, Tractive и некоторые другие. Invoxia это сеть SigFox, Tractive и прочие - GPRS с симкой, Findster - собственное радио.

  • Симочные все требуют денег, минимум 5 евро в месяц абонемент. При этом видимо используются какие-то дешёвые IoT симки с 2G connectivity. Задержки сигналов 1-2 минуты.

  • На SigFox возлагались надежды - но сеть теряет сигналы как-то уж очень часто, локации приходят в перемешанном порядке. Качество фикса позиции ужасное.

  • Findster - хороший фикс и реалтайм отслеживание. Производитель рекламирует радиус 900 метров в городе, реально 100+ метров - трекинг теряется. Его я использовал дольше всего - пока Барсик вокруг дома уже всё не изучил, ему не стало скучно и он отправился в более дальние экспедиции.

  • Жизнь батарейки - реалтайм GNSS трекинг выжирает часа за 2-3 батарейку у всех трекеров.

LoRa и The Things Network

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

  • LoRa использует EU 868MHz нелицензированные частоты, которые доступны и в РФ.

  • LoRa использует chirp модуляцию, изначально придуманную для военных целей, которая позволяет энерго-эффективную радио коммуникацию в отсутствии прямой видимости.

  • LoRa поддерживает различные сети - можно делать частную сеть со своей базовой станцией, или пользоваться сетью провайдера. KPN предоставляет покрытие по всем Нидерландам.

  • Устройства LoRa не стоят индустриальных денег

Стандартных решений для трекеров с LoRa сетью на рынке не было - и нет - но почему бы и не сделать собственное?

Gateway и антенна


Нидерландская компания The Things Network предлагает TTN Indoor gateway за 70 евро. Установка и конфигурация (gateway передаёт через wifi на сеть TTN всё, что ловит на радио сам) была завершена за 10 минут.

TTN консоль сделана с любовью, всё понятно и удобно.TTN консоль сделана с любовью, всё понятно и удобно.

Единственная проблема - gateway содержит внутреннюю напечатанную антенну, которая не обеспечивает связи вне дома.

Решение проблемы - подключить внешнюю антенну. Благо дом свой, можно лезть на крышу и ставить что угодно.

Aurel GP 868 антенна на крышеAurel GP 868 антенна на крыше

Решение по частям

  • заказать внешнюю антенну с ground plane диаграммой (например Aurel GP 868, EUR 40,-)

  • заказать IPEX кабель-адаптер (для Aurel был нужен IPEX-to-BNC-female, EUR 3,-)

  • вскрыть корпус gateway, отсоединить IPEX кабель от печатной планы и воткнуть свой кабель внешней антенны

Наверное можно было сделать аккуратнее, но и так работает.Наверное можно было сделать аккуратнее, но и так работает.

После такого хака я увидел на гейтвее трафик с нескольких LoRa устройств поблизости. Это колхозный принцип организации TTN - каждый любитель, типа меня, с гейтвеем ловит и передаёт трафик от всех устройств, активированных в TTN. В сутки где-то 100 тысяч сообщений, но каждое меньше 100 байт, поэтому +10 мегабайт в сутки на фоне всего остального незаметно, от слова вообще.

В результате получается бесплатная (и без SLA) колхозная сеть. Покрытие не 100% и даже не близко, но сам факт, почему бы и нет?

Бесплатное покрытие TTN в АмстердамеБесплатное покрытие TTN в Амстердаме

С антенной как есть - покрытие порядка 1 км радиус, планирую поднять антенну на 6 метров, посмотрю насколько увеличится радиус. Фанаты устанавливают рекорды LoRa связи в несколько сотен километров.

На рынке LoRa трекеров есть несколько устройств, но единственное устройство можно было использовать в качестве кото-трекера. Это BroWAN Object Locator, которые делает тайваньская фирма Browan. Кроме этих сенсоров, они делают ещё десятки других LoRa устройств, от CO2 до протечек воды. Очень милые ребята, хорошая техническая поддержка.

Другие сенсоры были либо слишком тяжёлые (для авто или мотоциклов), либо с батарейкой, которая не перезаряжается, либо не позволяли сконфигурировать себя под TTN.

BroWAN tabBroWAN tab

Вес 28 граммов, батарейка 540mAh, которой хватает на передачу позиции раз в минуту в течение 8 часов, или дольше, если реже.

Но если бы я был котом, мне бы с такой блямбой на шее бегать было бы неудобно. К тому же кот носил Findster и теперь носит два BroWAN tab - TTN с моей антенной и KPN, который тестируется.

Поэтому я купил шлейку для прогулок котов, отрезал всё лишнее и пришил как умел два кармашка, получился такой типа жилетик-разгрузка.

Пришлось ещё удлинить лямку вокруг шеи, чтобы не затягивать сильно, но и не расстёгивалось.

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

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

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

Ещё Барсик таскает в одном из кармашков маленькую круглую таблетку Tile- она не умеет в GNSS и из радио всего лишь Bluetooth. Но зато она умеет громко пиликать, когда ты от неё в 10 метрах или ближе (в рекламе 30-40, но с 10 точно берёт). Это позволяло мне находить жилетик в 6 случаях, когда кот его сбрасывал и гулял дальше голый.

Эскобар в боевом облаченииЭскобар в боевом облачении

Программное обеспечение

Пока что было всё про железки, теперь про софт немного. Архитектура решения выглядит примерно так:

Кот начинает гулять, трекер активируется акселерометром и начинает посылать позиции раз в минуту. Пакеты ловятся каким-то gateway (иногда несколькими) и пересылаются в сеть TTN.

Каждый пакет это примерно 50 байт, содержит заголовки, метаданные, локация и напряжение батарейки.

Приложение в консоли TTNПриложение в консоли TTN

Gateway добавляет свою информацию, в частности отношение сигнал/шум и посылает всё в сеть TTN. В консоли TTN каждое устройство (device) конфигурируется как честь приложения (application) - группа устройств, парсер входящих пакетов + дальнейшие интеграции - MQTT, HTTP и прочие.

Конфигурация устройстваКонфигурация устройства

В TTN application можно добавить функцию-парсер для преобразования байтов из устройства в структуру типа JSON. Для BroWAN трекеров код выглядит так:

function Decoder(bytes, port) {    var params = {        "bytes": bytes    };    bytes = bytes.slice(bytes.length-11);      if ((bytes[0] & 0x8) === 0) {        params.gnss_fix = true;      } else {        params.gnss_fix = false;      }      // Mask off enf of temp byte, RFU      temp = bytes[2] & 0x7f;      acc = bytes[10] >> 5;      acc = Math.pow(2, parseInt(acc) + 2);      // Mask off end of accuracy byte, so lon doesn't get affected      bytes[10] &= 0x1f;      if ((bytes[10] & (1 << 4)) !== 0) {        bytes[10] |= 0xe0;      }      // Mask off end of lat byte, RFU      bytes[6] &= 0x0f;      lat = bytes[6] << 24 | bytes[5] << 16 | bytes[4] << 8  | bytes[3];      lon = bytes[10] << 24 | bytes[9] << 16 | bytes[8] << 8  | bytes[7];      battery = bytes[1];      capacity = battery >> 4;      voltage = battery & 0x0f;      params.latitude = lat/1000000;      params.longitude = lon/1000000;      params.accuracy = acc;      params.temperature = temp - 32;      params.capacity = (capacity / 15) * 100;      params.voltage = (25 + voltage)/10;      params.port=port;      return params;}view rawttn-browan hosted with  by GitHub

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

Приложение состоит из Scala/Akka сервиса, фронтенда на голом TypeScript, Azure DevOps CI и Kubernetes дескриптора.

Полный код доступен в https://github.com/jacum/catracker.

Сегодня был дождь и Барсик не ходил далекоСегодня был дождь и Барсик не ходил далеко

Интерфейс минималистичный но вполне MVP - показывает проценты батарейки, позицию кота и время с апдейта последней позиции, если прошло больше двух минут. Скриншот сделан после 1 часа и 53 того, как кот пришёл домой - трекер не посылает событий, если акселерометр не показывает движения.

Большое спасибо TTN за надёжное и недорогое оборудование, и добротную консоль, и BroWAN за лучшие LoRa трекеты.

И конечно же коту Барсику за ежедневные усилия по тестированию решения.

Мяу!Мяу!

Оригинал (моей же) статьи

Подробнее..

Как мы прокачали телеметрию крупного металлургического комбината

22.12.2020 16:08:30 | Автор: admin

Привет, Хабр! Я Ольга Пешина, эксперт по развитию новых технологий. Когда нашему производству огромной металлургической компании Северсталь требуется поиск, проработка и внедрение инновационных идей или прорывных информационных технологий, обращаются к нам.


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


Как сейчас: сбор данных по оптике


Для сбора информации с наиболее критичного оборудования мы используем оптическую сеть. У такого решения есть масса преимуществ. Это отличная среда передачи для сценария, где важны объёмы транслируемой информации и гарантии доставки с минимальными задержками.


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


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


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


В попытках снизить стоимость инфраструктуры и повысить оперативность подключения новых датчиков мы начали смотреть на беспроводные решения. В некоторых цехах задействовали промышленный Wi-Fi. Однако сигналы его частотного диапазона уж очень хорошо экранируются металлическими конструкциями внутри цехов, так что требования к бесперебойности сигнала не удовлетворяются. Пришлось искать альтернативу.


Пилот на LoRaWAN


Мы рассматривали несколько вариантов, в том числе Private LTE и NB-IoT. Смотрели и в сторону проприетарных решений. Но в итоге остановились на LoRaWAN, на базе которого и развернули пилотный проект. Он показал неоспоримые плюсы.


Частотный диапазон


Главный плюс, пожалуй, заключается в том, что сеть LoRaWAN, в отличие от Wi-Fi, работает в частотном диапазоне до 1 ГГц (кстати, нелицензируемом) с возможностью изменения параметров передачи. Высокая проницаемость субгигагерцевых сигналов позволяет передавать данные даже из подвала, который находится под металлопрокатным станом. Именно этот результат вдохновил нас больше всего.


Производители оборудования LoRaWAN заявляют дальность связи до 5 км в сложных условиях. В ходе пилотного внедрения в условиях повсеместного металла удалось получить устойчивый сигнал в радиусе 2,5 км от базовой станции. Для этого проекта мы ставили условие потери не более 5 % пакетов при передаче, но в течение полугода эксплуатации потери не превышали 1 %. Наши расчёты показывают, что 9 базовыми станциями, установленными на высоких объектах завода (трубах и т. п.), мы покроем сетью всю территорию, при этом будем работать не на предельных расстояниях, а с запасом.


Стоимость технологии


Подсчёты показали, что развертывание сети LoRaWAN для решения нашей задачи более чем в 10 раз дешевле аналогичной оптической.


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


Открытый протокол


Но даже получив хорошие результаты в частотном диапазоне LoRaWAN, мы всё ещё смотрели и на проприетарные протоколы того же участка спектра, которые заявляют большую скорость передачи данных. Они действительно работают: передают более серьёзные объёмы информации или значительно уменьшают интервал дискретности передачи. Но зависимость от вендора в условиях нашего зоопарка технологий не лучшая идея. Да и с точки зрения конкурентоспособности мы не хотели бы замыкаться на конкретных производителях, когда есть классическая открытая LPWAN-система.


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


Автономность устройств


Автономность LoRa-устройств закрывает проблему невозможности монтажа проводных решений на некоторых узлах. Но при этом мы упираемся в энергопотребление. Если нет проводной сети, то, как правило, нет и электрического кабеля. Поэтому новый вопрос замена батарей, которые обеспечивают эту автономность. Обидно будет, если дешёвая технология сбора информации с датчиков существенно поднимет затраты на обслуживание, например на штат сотрудников, которые целыми днями будут ходить по предприятию и менять, менять, менять батарейки.


Устройства LoRaWAN, которые мы тестировали в рамках пилота, при передаче раз в 5 минут продержали заряд более 3 месяцев. А это как раз минимальный срок, который нас устраивает.
Конечно, кому бы не хотелось, чтобы батареи работали год? Но тут многое зависит от условий работы. Очевидно, что при частой отправке данных или при минусовых температурах (если датчики находятся на улице зимой) длительность автономной работы будет меньше. Но мы не оставляем надежд найти партнёров, которые будут производить более энергоэффективные устройства или использовать новые типы батарей.


Безопасность


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


Ложка дегтя


Безусловно, у LoRaWAN есть недостатки. Главный заключается в невозможности передавать большие объёмы информации у стандарта очень низкая пропускная способность. К тому же сигнал дискретен, то есть данные не льются онлайн. Сейчас устройства отправляют информацию раз в 5 минут минимально возможный промежуток времени между пакетами на нашем пилотном стенде. Это ограничивает сферу применения LoRa, но не заставляет нас полностью отказываться от дешёвого и удобного по многим показателям стандарта.


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


Боевой проект


Масштабное внедрение на промплощадке в Череповце только стартует. Активная фаза проекта запланирована на 2021 год.


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


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


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


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


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


Хабравчане, а вы работали с LPWAN-решениями? Расскажите про свой опыт и кейсы применения.

Подробнее..

Перевод DLMS поверх LoRaWAN что это такое и почему это важно

08.11.2020 10:13:36 | Автор: admin


На вебинаре проведенном LoRa Alliance под эгидой компании Semtech, президент ассоциации пользователей DLMS анонсировал будущий выпуск первого коммуникационного профиля на базе протокола LoRaWAN. Более двух лет ассоциация пользователей DLMS и LoRa Alliance взаимодействуют друг с другом для того, чтобы определить надежный и безопасный способ поддержки протокола DLMS в сети LoRaWAN.


Возможность передачи данных с помощью нового коммуникационного профиля была продемонстрирована в 2018 году, а также в последующие годы на European Utility Week 2019 и Indian Smart Utility Week 2020.


Новый коммуникационный профиль на базе протокола LoRaWAN это главный результат взаимодействия DLMS UA и LoRa Alliance, который обеспечит надежность и интероперабельность в будущих реализациях устройств с поддержкой DLMS, работающих в сети LoRaWAN.


Что такое DLMS/COSEM?


Стек DLMS/COSEM это набор стандартов, разрабатываемый и поддерживаемый ассоциацией пользователей DLMS. Впервые опубликованный в 1999 году, он был принят в 2002 году Международной Электротехнической Комиссией (МЭК) и Европейским Комитетом по Стандартизации (CEN) в виде серии стандартов IEC 62056, а в 2019 году принят Американским Национальным Институтом Стандартов (ANSI). Стек DLMS/COSEM получил широкое распространение: он применяется в более чем ста миллионах приборов учёта по всему миру и используется многими глобальными компаниями, например, EDF, Ibedrola, EDP и др.


Стек DLMS/COSEM поддерживает различные стандартны проводной и беспроводной связи, включая сотовую связь, PLC, Zigbee, WMBUS и PRIME-PLC. Его гибкость, обусловленная независимостью прикладного уровня от среды передачи данных, позволяет компаниям, предоставляющие ресурсы (например, электроэнергия, вода, тепло и др.) для коммунального сектора и конечным потребителям иметь одно и тоже приложение, обеспечивающее связь по одной или нескольким коммуникационным технологиям.


Зачем добавлять LoRaWAN в список коммуникационных профилей?


На вебинаре было озвучено, что по мере распространения решений интернета вещей (IoT), основанных на малопотребляющих технологиях радиосвязи большого радиуса действия, таких как LoRa компании Semtech, компании предоставляющие ресурсы для коммунального сектора становятся все более и более заинтересованными в использовании широкополосных сетей с низким энергопотреблением (LPWAN) для реализации своих собственных решений IoT. Таким компаниям выгодно быстро развертывать энергосберегающие и экономичные решения для сбора данных, которые LoRa обеспечивает для традиционных приложений интернета вещей, например, интеллектуальный учёт, а также новые приложения, связанные с удаленным управлением и мониторингом, например, управление интеллектуальной сетью. Помимо этого, многие компании видят потенциально новые рынки, например, умные города и умные дома, где возможность использовать один протокол прикладного уровня, такой как DLMS, для нескольких приложений значительно упрощает сбор данных, которые раньше были разрознены (например, данные о энергопотреблении и данные от датчиков умных зданий), предлагая при этом клиентам более комплексные решения.


Почему важна поддержка DLMS в сетях LoRaWAN?


Многие игроки рынка, такие как компании предоставляющие ресурсы для коммунального сектора, сетевые операторы, производители приборов учёта и системные интеграторы, высказывают свою поддержку и заинтересованность в обеспечении работы DLMS в сетях LoRaWAN. Французская энергетическая компания EDF, оператор LoRaWAN и системный интегратор Lar.Tech (который развернул в России 50 тысяч приборов учёта, поддерживающих протокол DLMS), а также компания занимающаяся сетевой инфраструктурой American Tower, сказали следующее:


EDF решительно поддерживает создание DLMS профиля для сетей LoRaWAN и предвидит в коммунальном секторе множество полезных решений интернета вещей с DLMS. Винсент Одеберт, эксперт интернета вещей компании EDF и участник LoRa Alliance. Пресс-релиз LoRa Alliance от 3 апреля 2019 года

В Бразилии развернуто около 85 миллионов приборов учёта электрической энергии и используется три стандарта: ABNT, DLMS и Американский стандарт. DLMS является наиболее часто используемым. В компании ATC понимают, что прозрачная и простая в реализации совместимость между DLMS и LoRaWAN, а также возможность FUOTA, являются ключом к созданию и развитию этой вертикали. Даниел Лапер, руководитель направления интернета вещей компании ATC, 9 апреля 2020 год

Будучи одной из первых компаний, которая реализовала поддержку протокола DLMS в сетях LoRaWAN для обмена данными с приборами учёта электрической энергии, Lar.Tech очень заинтересована в дальнейшем развитии сотрудничества между двумя сообществами. Мы твердо верим в то, что совместные усилия и открытый диалог помогут нашим клиентам и рынку быстро принять новые технологии и развивать экосистему в будущем. Дмитрий Полторак, генеральный директор компании Lar.Tech, 14 апреля 2020 год

Участник вебинара Александр Пелов, генеральный директор Acklio, член LoRa Alliance и автор технологии SCHC (Static Context Header Compression) подробно рассказал о том, как в новом коммуникационном профиле DLMS для сетей LoRaWAN, применяется комбинация проверенных стандартов и SCHC, являющаяся основой этого профиля.


Технология SCHC описана в документе RFC 8724, который недавно был опубликован Инженерным советом интернета (IETF). Описание этой технологии в виде документа RFC является ключевым отличием от других подходов, основанных на проприетарных решениях в виде моста, который перехватывает сообщения DLMS и извлекает из них полезное содержимое. Таким образом, уровень SCHC обеспечивает прозрачный и стандартизированный неразрывный IP-канал, позволяющий передавать данные по протоколу DLMS в сети LoRaWAN с прозрачной поддержкой объектной модели COSEM и OBIS-кодов.


Новые и улучшенные решения для интернета вещей


С новым коммуникационным профилем, компании предоставляющие ресурсы для коммунального сектора могут в полной мере использовать все возможности DLMS, начиная от обеспечения безопасности и заканчивая двунаправленной отправкой сообщений и получением команд. Безопасность также обеспечивается и сетью LoRaWAN.


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


Отметим, что это один из первых случаев, когда стандартный протокол на основе IP может использоваться поверх LoRaWAN в рамках полной спецификации. Теперь мы с нетерпением ждем возможности помочь LoRa-разработчикам и членам ассоциации DLMS извлечь как можно больше пользы из этой синергии.


Более подробная информация о передаче DLMS поверх LoRaWAN доступна в техническом документе на сайте LoRa Alliance.

Подробнее..

Дальность работы безлицензионныхLPWANсистем

20.04.2021 00:18:08 | Автор: admin

Привет всем уважаемым читателям Хабра!

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

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

Например, если оценить дальностьLoRaWANв городе порядка 5 км, аBluetooth35 метров, то уBluetoothплощадь покрытия будет в 20 тысяч раз меньше. При этом энергия сообщенияLoRaWANбольшеBluetoothпримерно во столько же раз это означает, что энергоэффективность приведенная к площади покрытия уLoRaWANиBluetoothимеют примерно одинаковые значения.

Такой результат полностью согласуется с физическими законами распространения информации по радиоканалу. Известное ограничение Шеннона на скорость передачи информации в эфире можно трактовать в следующей формулировке:

Площадь зоны покрытия приемника при прочих равных условиях обратно пропорциональна скорости передачи информации и практически не зависит от типа применяемой модуляции.

Bluetoothработает быстро, но на маленькое расстояние; для обеспечения связи на площади работы одного шлюзаLoRaWANпридется поставить огромное количествоBluetoothшлюзов, примерно равное как раз отношению площадей покрытия - 20000.

Так какую же дальность имеют распространенныеLPWANсистемы? Если погуглить, то можно найти очень противоречивую информацию, с одной стороны:

  • 766 км новый рекорд дальности для LoRaWAN!

  • Радиус действия: 30-50 км (3-10 км в зашумленных и труднодоступных районах)

  • В городской черте превышает 10 км, а за пределами города ограничивается видимостью горизонта и составляет в среднем 50 км

Есть и другая информация:

  • большое расстояние до 10 км от шлюза

  • максимальная успешная дальность связи 3.8 км

  • в результате испытаний удалось получить устойчивую связь в радиусе 500 метров от базовой станции

Попробуем немного прояснить ситуацию. Есть общее понимание, что дальностьLPWANв первую очередь определяется чувствительностью приемника шлюза. На самом деле одной чувствительности совсем не достаточно, но об этом будет в следующей статье.

ЧувствительностьLPWANприемника

В интернете активно гуляют следующие картинки обосновывающие уникально высокую чувствительностьLoRa.

Давайте проверим, так ли это на самом деле. Возьмём характеристикиLoRaWANприемников и для сравнения возьмём качественный чип приемника в диапазоне 868 МГц с возможностью медленной передачи информации. Идеальным примером является приемникAX5243 производстваONSemiconductor. Результаты приведены в таблице 1 и на рисунке 2.

Рис 2. Зависимость чувствительности приемника от скорости передачи данных для LoRaWAN и AX5243Рис 2. Зависимость чувствительности приемника от скорости передачи данных для LoRaWAN и AX5243

Наша картинка на рис 2 несколько отличается от популярных изображений на рис 1. Как видим, разница чувствительности приемников незначительна, что еще раз подтверждает: чточувствительность приемника обратно пропорциональна скорости передачи информации и, при правильно спроектированном приемнике, не сильно зависит от типа применяемой модуляции.Современная элементная база позволяет проектировать приемники шлюза с чувствительностью, приближающейся к ограничению Шеннона.

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

Зависимость дальности от чувствительности приемника

Для сравнения дальности работы радиоканала обычно используют специально разработанные модели оценки, например модель распространения радиоволн Хата, которая работает при условии размещения антенн шлюзов выше соседних крыш, что как раз важно при установкеLPWANшлюзов. Потери в канале в условиях города определяются по формуле:

Для потерь в условиях сельской местности и открытого пространства в модели вводятся соответствующие поправочные коэффициенты. Подробности модели Хата можно посмотреть в Википедии или других источниках в интернете, там же можно найти калькуляторы расчета дальности радиоканала в городе, основанные на этой модели.

Оценим по модели Ханта дальность работы для нескольких типичных вариантов использования в частотном диапазоне 868 МГц. Рассмотрим несколько типичных случаев использованияLPWANв плотной городской застройке и сельской местности. Мощность излучения примем равной 14dbm. Коэффициент усиления антенны шлюза будем считать равным 6dbi, дополнительные потери 3db, а конечное устройство расположенным на высоте 1 метр над землей. Чувствительность приемника будем считать -137dbmдляLoRaWAN, -142dbmдляSigFoxи -145dbmдля продвинутыхUNBсистем типа Стриж, Вавиот,GoodWAN(почему в последнем случае указано -145dbmи при каких условиях такую чувствительность можно получить обсудим в одном из следующих постов). Для оценкиindoorпокрытия примем величину ослабления на излучение из помещений на первых и полуподвальных этажах зданий равным 15db(грубая оценка, реально эта величина слишком зависит от местных условий).

Важно, что модель Ханта корректно работает только в случае плоского рельефа местности, с антенной шлюза, расположенной над ближайшими крышами домов, для дальностей 1-20 км (последняя строка таблицы 2 выходит за пределы 20 км, но для примерной оценки полученные цифры достаточно адекватны). В условиях открытого пространства обычно работает такое эмпирическое правило: если от антенны шлюза видны крыши ближайших к конечному устройству домов, то связь будет обеспечена.

Обратите внимание, что дальность очень сильно зависит от высоты подъема антенны. В большом городе можно установить шлюз на крыше жилой высотки, обычно это 60 метров и более, в сельской местности высоко разместить антенну обычно не получается и для расчета мы взяли 15 метров. В результате дальность в селе оказалась меньше, чем в городе! Это, казалось бы, полностью противоречит распространенным утверждениям, что за городом дальностьLPWANсильно больше. Да, сильно больше, но при одинаково высоко установленных антеннах, в реальности же обычно имеем теже 10 кмoutdoorпокрытия.

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

Эти цифры легко запомнить, они нам пригодятся при дальнейшем анализе эффективности различныхLPWANсистем.

В настоящее время активно обсуждается возможность использованияLPWANв диапазоне 433 МГц. В распоряжении Ассоциации Интернета Вещей появился опросникМинцифры России от 06 апреля 2021 года об оценке необходимости новых полос радиочастот для внедрения узкополосных беспроводных сетей связи Интернета вещей в диапазонах 400 МГц и 800 МГц. Основным аргументом для использования 433-го диапазона является утверждение о значительно лучшем в этом диапазоне распространении радиоволн в городе. Основным отрицательным фактором является необходимость использовать значительно большие по габаритам антенны в конечных устройствах.

Оценим увеличение площади покрытия при переходе на 433. Разрешенная мощность излучения в этом диапазоне 12,5dbm, дополнительные потери на конечном устройстве увеличим на 3db(скорее всего будут использоваться укороченные антенны), но дополнительные потери наindoorпокрытие, наоборот, уменьшим на 3db.

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

Дальность работы и соответствующая площадь покрытия очень сильно уменьшается в случае необходимостиindoorпокрытия на первых и подвальных этажах зданий. Оценочные значения приведены в таблице 2 и обобщены в таблице 5.

Как связана дальность и энергоэффективность системы? Возможно такое сравнение.

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

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

Выводы

  1. Площадь покрытия шлюза один из ключевыхLPWANпараметров, он позволяет определить стоимость вложений в инфраструктуру сети. Обычно сеть покрытия строят с пересекающимися зонами покрытия шлюзов, в таком случае увеличение площади одновременно позволяет повысить надежность доставки информации.

  2. Зона покрытия сильно зависит от высоты подъема антенны шлюза, она должна располагаться выше ближайших крыш.

  3. Площадь покрытия правильно спроектированныхUNBсистем в 2-3 раза большеLoRaWAN

  4. Indoorиoutdoorпокрытие две большие разницы, дальностьindoorпокрытия на первых и полуподвальных этажах в 2-3 раза меньше. Когда говорят о дальностиLPWANвсегда требуется уточнять о какой дальности идет речь.

  5. Переход на более низкий частотный диапазон с 868 на 433 МГц сопряжен с необходимостью использовать на конечных устройствах антенны с большими габаритами, но позволяет увеличить площадь покрытия, порядка в 2,4 раза дляindoorустройств на первых и полуподвальных этажах зданий.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru