Как стать автором
Обновить

Комментарии 71

Всегда смущала мода пихать все в радио канал. Почему данные со счетчика не перекинуть по проводке до хаба и дальше отправить по оптике или GSM до центра обработки?

1) Оптики у нас в ТРК нет.
2) Какой смысл использовать GSM, если мы имеем свой гарантированный канал радиосвязи?
3) Мы постарались прикрепить максимум материалов, чтобы вы оценили размер ТРК. Стащить кучу проводов к хабу там задача малореальная. Даже если это удастся технически, затраты будут просто капитальные. Через Лору дешевле.
крупнейшего торгово-развлекательного комплекса в Челябинске

А «Горки» и «Алмаз» не крупнее?

Горки точно нет, насчет Алмаза уже не так уверен. В любом случае, Родник если и не самый большой, то второй по размерам)
LoRa гарантированный канал радиосвязи? Любой желающие легально может включить 8 передатчиков на 8 LoRa каналах, передающих непрерывно поток данных и сеть LoRa будет загрушена в радиусе ~5 км. Кому-то хочется файлы передавать по сети, и с точки закона все равны, телеметрия и мультимедиа канал. Надо только уточнить по допустимому времени работы, иногда указывается 5-10% время активное ко времени пассивному.
Частотный диапазон там ограничен, кроме злоумышленника может жилой дом рядом перейти на сеть LoRa и передавать непрерывно данные со счетчиков, забив эфир.
Скоро будет статья про последние изменения в частотном законодательстве.
Круглосуточно спамить вы сможете, но это не по закону. По закону от 0,1 % до 10 % времени в эфире, в зависимости от поддиапазона.

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

Что же касается других абонентов без злого умысла — да, так и будет. Число устройств будет расти и в эфире скоро всем станет тесно. Но уже расширяют границы дозволенных частот. Будет примерно как с вафлей. Сейчас в многоквартирном доме в 2,4 творится просто ад. И что, никто не работает? Да работают, пусть не так эффективно, но в целом хватает. Плюс — есть пятерка.
Согласен. Число абонентов будет расти, диапазон пока свободен и привлекателен этим. Но каждая статья на Хабре будет привлекать всё больше пользователей ))
Даже при времени работы 0.1% тысяча абонентов как-раз плотно займут канал. Впрочем для телеметрии хватит вполне.
Хорошо бы тут упомянуть о какой-то культуре пользования каналом, передавать минимум информации, на минимальной мощности, чтобы не мешать окружающим.
По закону от 0,1 % до 10 % времени в эфире, в зависимости от поддиапазона.


Кажется, иногда все-таки 100% :-)
Ссылку на нормативный документ?
Сам жду, пока в какой-нибудь юридической базе актуальная редакция появится.
А не, появилось.
www.consultant.ru/cons/cgi/online.cgi?req=doc&base=EXP&n=652036&rnd=65F54082882AD50FBFC6C908A2A7CA1F&from=527972-4#00012731402012002846

868.7 — 869.2. на 25 мВт никаких ограничений на рабочий цикл. На 100 мВт — 10% или LBT.
мда, я бы бегал с перфоратором тащил бы по зданию rs-485 ))))
ухахах…
Во-во. Тот случай, когда по радио всем проще)
Ага, протянуть такую шину с километр на несколько сотен приборов, а потом обнаружить, что данные не передаются, т.к. где-то обрыв или замыкание проводников.
У меня был случай. Монтажники протянули шину 485, подключили все приборы, кроме одного, поставка которого задержалась. Ну и эти прекрасные люди просто скрутили между собой хвосты A B интерфейса, замотали изолентой и спрятали в короб. Вот было весело искать почему данных нет.
Можно активные репитеры ставить, проблема с КЗ ушла бы. Да и второй раз такую проблему найдете намного быстрее )) Сложнее когда одно из устройств сходит с ума и начинает спамить в общую шину непредсказуемо.
Сложнее когда одно из устройств сходит с ума и начинает спамить в общую шину непредсказуемо

Это проблема для любого канала и протокола связи.
Буквально на днях общался с разработчиками системы для учёта энергоресурсов. Довольно известных. На вопрос получения данных с приборов учёта (счётчики, расходомеры и т.д.). Они используют ТОЛЬКО API приборов, даже, если производитель может предоставить OPC сервер. Объясняют тем, что при использовании программной прослойки теряется метрологическая составляющая полученных данных.
Что интересно, в нашей области деятельности (газ) применение OPC технологии наоборот всячески приветствуется и рекомендуется на уровне отраслевых регламентирующих документов.
Что-то забавное они про метрологию говорят. Если всерьез вопросом занимаются, им все равно систему через метролога прогонять. И на этом этапе все «потерянное» можно «найти».
Мы делали на zigbee от ЭФФА. Внутри там чип от Rexenta, документирован очень хорошо. Сбор показаний написали на коленке. Провода в ТРЦ работают не очень, потому что арендаторы часто меняются и помещения перепланируются, делятся, сливаются. Как следствие, счетчики гуляют как те кошки.
По масштабам у нас не Родник конечно, но тоже немаленький. На сегодня подключено 220 приборов к трем координаторам.
А зачем вам три сети?
Просто для страховки что ли. Поставщик не советовал вешать больше полутора сотен приборов на координатор, да и ТРК поделен на три очереди.
НЛО прилетело и опубликовало эту надпись здесь
Заглушить можно все, что угодно. Вопрос только в том, дадут ли вам надзорные органы долго спамить в 868. LoRa имеет хорошую помехозащищенность, может работать ниже уровня шума и чтобы ее заглушить, надо спамить очень сильно. Настолько сильно, что вас не оставят без внимания.

А новая прошивка от Веги позволяет не терять пакеты с данными даже если в конкретный час связь не состоялась.
вроде как с ней все проще, можно на ней же самой преамбулой просто молотить в эфир, тогда она всегда будет считать что канал занят, точнее 8-ю преамбулами
каналЫ :-) И, как выяснилось, можно даже четырьмя обойтись, а то и двумя, если полосу пошире взять.
Хотя со всеми этими способами есть свои тонкости.
>дадут ли вам надзорные органы долго спамить в 868.

Вы прекрасно знаете, что куча контор работает на EU868. И никакие «люди в черном» за ними пока не приходят :-) Так что дадут.
Ну и про отсутствие duty cycle limitations в полумегагерце частот тоже знаете.
Я имел ввиду именно ситуацию с глушением канала каким-нибудь передатчиком Ватт на 50. Если будете делать это в 868, то я думаю, быстро заинтересуются.

С EU868 иная ситуация. Там народ работал своими крошечными (25-100 мВт) мощностями и никому особо не мешал. И, как показали события 11 сентября сего года, решили выбрать несколько иной путь. Сейчас EU868 частично легализован. Возможно, легализуют полностью.

Насчет отсутствия duty cycle, очевидно, в 868,7-869,2 — первый раз слышу) По моей информации там сейчас 10%. Раньше 1% был)
Насчет отсутствия duty cycle, очевидно, в 868,7-869,2 — первый раз слышу


А мне кажется, мы даже с Вами это обсуждали на одном другом сайте. По спеке-то 1%. А по разрешению ГКРЧ — 100%.
Последние изменения добавили работу на 100 мВт с DC 10%. На 25 мВт все так же 100%.

Сейчас EU868 частично легализован. Возможно, легализуют полностью.

Ну, mandatory channels не разрешены. И не похоже, чтобы разрешили, там уже вполне серьезные заинтересованные лица против. Не LoRaWAN'ом единым страна живет-то.
Да, было дело) Но я все же ссылаюсь на это свежевыпеченное решение. minsvyaz.ru/uploaded/files/prilozhenie-12-k-reshenyu-gkrch-18-46-03-1.pdf

Честно — пока только изучаем его и ищем подводные камни. По мне, так формулировка на наши спорные полмегагерца теперь трактуется именно как 10 процентов занятия эфира на ЭИИМ не более 100мВт. Если вы мне укажете, как можно занять весь эфир на 25 мВт буду признателен. Кроме шуток.
В этой бумажке вот непонятно, дополнения или изменения. А вот заявку, на базе которой это решение принято, мне пересказывали :-)
Я имел ввиду именно ситуацию с глушением канала каким-нибудь передатчиком Ватт на 50. Если будете делать это в 868, то я думаю, быстро заинтересуются.


Не могу представить, зачем такое может понадобиться.
А зачем молотить в эфир преамбулами?) Злоумышленники)
Недоброжелатели и правонарушители — все-таки не одно и то же.
Если верить ГКРЧ, то последний раз 868,7-869,2 МГц присутствует в приложении 11 (устройства любого назначения) к решению от 28 апреля 2008: 23.rkn.gov.ru/docs/23/GKRCH08-24-01-001.doc и там о duty cycle не сказано, только выходная мощность.
Можно и без злого умысла заспамить, например рядом жилой дом переходит на LoRa со своей базовой станцией и их передатчики глушат связь с более удаленной базовой станцией. Если несколько сотен приборов учета, они могут непрерывно слать данные и более слабый сигнал будет заблокирован полностью.
там жилые дома довольно далеко.
Автор, видимо, имеет более общую ситуацию.
На самом деле, да, можно, все к этому и идет, что скоро в эфире будет очень много устройств. Но так и частотных каналов становится больше.
Там довольно интересные collision rules, может получиться, что и более сильный сигнал будет заодно заблокирован.
Разбираться нужно, полезный сигнал имеет длинный кадр, который передается до 13 секунд, а помеха может 1 бит исказить за миллисекунду работы и больше не нужно. Ну или больше, если есть избыточное кодирование полезных данных, которое тоже не всесильно.
Если передача данных двунаправленная, обмен данных ограничится самым слабым звеном, уровень сигнала или помехи у оконечного устройства или базовой станции.
который передается до 13 секунд,

Это откуда такая цифра?
Автор исследовал Lora на предмет максимальной дальности, и вроде как с его настройками скорости обмен данными занимал 13 секунд. Там скорости ~2400 бит/с и менее, передать кадр 200 байт весьма долго, это не WiFi многомегабитный.
www.youtube.com/watch?v=-7OmGcjkO_Y&t=0s&list=PLCbcCJDLvTuJSVg9IqiBu9yR8akk0Sj91&index=51
Автор грамотен, но пока весьма в начале пути в части LoRa, надо сказать. Впрочем, он, кажется, это сам говорит.
Ну и можно без проблем подобрать настройки, длину преамбулы, если конкретно, при которых передача будет занимать более получаса.
На практике в LoRaWAN параметры подбираются так, чтобы в три секунды укладываться. Если свой протокол придумать, можно почудить. Но не нужно.
LoRa вообще далеко не идеальна, не самый лучший способ использования частотного ресурса. Стриж кажется более качественным в этом плане, узкополосный сигнал, больше каналов в том же частотном ресурсе
strij.tech/publications/tehnologiya/lpwan-strij-lora.html
Так и UNB неидеальна во всех своих изводах. Равно как и все остальные технологии. На конкретную задачу надо смотреть и под нее подбирать.

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


Чисто попридираться: узкополосный у LoRa. У «Стрижа» — сверхузкополосный.
Можно и шлюз поставить размером с СИ-21 и передавать с него на сервер.
Софта может у этого продавца нет, но его можно и сделать самому.
Это Вы какой-нибудь single channel имеете в виду?
Обычный шлюз. На RAK831 + RPi Z (или STM32). Размер с пачку сигарет. Отправлять можно через ту же LORA. Только разместить правильно — что бы и сенсоры его видели и он видел базовую станцию. Конечно немного сложнее, чем взять готовые. Можно добавить отдельный LORA модуль с большим усилением и направленной антенной на базу. А для сенсоров на стене можно взять антенны, которые только полусферой излучают.
Не совсем идею тогда понял. Зачем вот в данном случае эта конструкция? Которая, кстати, требует нормального питания?
А еще направленную антенну уж тогда проще разместить на самой базе.
В целом, тоже не совсем понял идею.
Сенсоры не видят базу.
Сенсоры видят промежуточный шлюз. Шлюз видит базу. Конечно с направленной ещё больше дальность.
Чем, в вашем понимании, шлюз отличается от базы в архитектуре LoRaWAN?

только софтом (переделанным packet_forwarder'ом).
Короче, репитер для аплинков Вы предлагаете сделать. Можно, но реально непонятно, зачем нужно. И там уж на packet forwarder надо переделывать тогда, а написать приложение, которое от него будет по UDP пакеты получать и тут же по UDP же его просить отправить их обратно в эфир.
Но раз уж все равно там нормальное питание, можно и сразу на этом устройстве на сотовый модем разориться и не придумывать чудес таких.
Да — репитер.
Был у меня вариант и с GSM/LTE аплинком (совсем просто делается) и с NB-IoT (не в России). В общем-то ничего сложного и чудес никаких.
Однажды понадобятся даунлинки в классе А с четкими таймингами, и тут уже и будут чудеса :-)
Когда был GSM чудеса уже были и с аплинком и с даунлинком. Решенная проблема. Исходники то есть на github.
Исходники чего? Как вы передадите таймстемп с репитера нетворк серверу?
Исходники packet_forward. В случае с медленным аплинком логика работы немного другая. При получении пакета шлюз сразу его отправляет ACK, если есть down pack, то он отправляется устройству. Принятый пакет попадает в очередь на шлюзе. Пакеты из очереди отправляются на network server и при получении ACK от NS удаляются из очереди. Если приходит от NS down package, то оно попадает в очередь для последующей отправки устройству. Если пакеты приходят в пределах по времени, то всё работает как обычно.
Я не вижу, где в Вашем тексте репитер-то.

А с медленным backhaul для начала стоит задержку для первого окна выкрутить на максимум в 15 секунд. С джойном, правда, не поможет, но и Ваша схема тоже не очень поможет.

При получении пакета шлюз сразу его отправляет ACK,


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

RSSI Вы приводите — это то, что на БС видно, я так понимаю?
Ну, RSSI мы формально видим на сервере. Но смысл вы поняли правильно.
ZigBee бы потребовал некого контроллера, который смотрел бы во вне через какой-то шлюз, к примеру тот же 4g. Это как минимум.
Ну да, я имел в виду, что вы не считывали те условные попугаи, которые возвращает чип на конечном устройстве, с самого устройства. Мало ли, что «Вега» в прошивку там добавила…

А мощность какая выходная? Без деталей, на уровне «спортивно»/«не спортивно» :-)
ZigBee там много, чего мог потребовать, в зависимости от ситуации. Одними батарейными устройствами бы не обошлись, например (я не про шлюз, тот уж точно не на батарее).
>Методом подбора нашли наилучшее расположение антенны и просто наклеили ее на стену

Кстати, не очень идея. Про наклеить на стену. Боюсь, отчасти поэтому там и связь на грани.
Методом проб и ошибок) Но в том месте правда яма какая-то. Для одного датчика не критично, если бы их было много таких, то пересматривали концепцию. Скажем, установили на БС секторную антенну.

Какие дальности LoRa Link(ов) удалось достичь на разных битовых скоростях LoRa?

Мы исходим из того, что на SF12 максимальная гарантированная дальность в городе 2, иногда 3 км. В поле до 5 км.

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

Какая у Вас была ширина LoRa канала bandwidth?

Тут интересены именно прецеденты когда на конкретной битовой скорости была конктерная дальность LoRa Link(а). Какие у вас были прецеденты?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории