Комментарии 38
Павел, у тебя получилась очень крутая и полезная статья!!!
Я тот самый Евгений на которого есть ссылки и я просто хотел добавить что у нас есть небольшой чатик в телеге где мы обсуждаем трекеры и проблемы при сборке.
Не хочется светить публичной ссылкой чтобы потом не вычищать спамеров, но если вам это интересно то напишите Павлу или мне в личку свое имя, мы вас в него добавим.
1) а нужно именно в реалтайме? может достаточно собирать данные черной коробочкой и сдавать оргам?
2) если нужно в реалтайме смотреть за участниками, посмотрите в сторону радио меток - такие были у тиньков марафона — это просто антенна которая считывалась бесконтактно. Фото ниже.
если нужно в реалтайме смотреть за участниками, посмотрите в сторону радио меток - такие были у тиньков марафона — это просто антенна которая считывалась бесконтактно. Фото ниже.
В отличии от спортивного ориентирования участники марафона перемещаются по строго определённому маршруту, где в некоторых точках маршрута можно поставить не маленькие антенны (размером с лист А4 и больше) и так определять примерное местоположение участника.
Организаторы проверяют прохождение дистанции по отметкам на контрольных точках, трек в принципе им не нужен, в качестве отметок ещё встречаются компостеры и картонные карточки, но чаще это электронные системы, коих не одна и не две.
Трек, тем более онлайн, даёт возможность организовать трансляцию.
Лора она ведь помехоустойчивая, мешать друг другу они не должны. У нас в доме 1000шт счетчиков , все шлют данные и не особо друг другу мешают. Была вроде тема еще на метровых волнах, та вообще из подвалов работала , а в лесу должна большие расстояния пробивать.
Зы жирный плюс в карму
Они шлют показания не каждые 10 секунд, а гораздо реже
Ну и это скорее всего Lorawan, там 7 каналов на шлюзе, плюс разный "спрединг фактор" может быть на самих устройствах, это позволяет нескольким одновременно на одной частоте быть услышанными. Плюс в самом модуле есть настроечка "слушать эфир перед передачей". Магия там конечно есть, но умеренная. Но тащить Lorawan в лес это дорого, сложно и ненужно )
По опыту скажу что тащить аппаратно это дешево и легко, самое дорогое это шлюз от какого-ниубдь Heltec тысяч за 7-10 и малинка для Chrpstack. Другой вопрос в портировании стека оконечного устройства, если не брать устаревший LMIC, а современный SWL2001 то пара месяцев совокупления для стабильной работы гарантировано.
Еще как будет мешать, потому что это физика. Я делал Airsoft Tracker (https://github.com/ddv2005/AirsoftTracker ) и мне удалось сделать так чтобы десяток устройств передавали и принимали свое положение несколько раз в секунду и могли ретранслировать сигнал на подобии mesh. Во-первых, для этого нужен чип sx1262, который умеет детектировать и рапортовать preamble, чтобы как можно раньше понять что эфир занят. Кроме того нужен модуль с прямым доступом к sx1262 (типа E22) , а не эти недо модули с UART (E32) . Дальее я реализовал что то типа TDM поверх Lora. Я разбил 5 секундный интервал на таймслоты. Длительность таймслота - это увеличенное значение времени, нужное для передачи пакета максимальной длинны при заданных параметрах передачи. Далее, каждое передающее устройство имеет свой ID в зависимости от которого и количества устройст вокруг оно знает какие тайм слоты оно может использовать. Время начала таймслотов синхронизируются от устройства с минимальным ID. Если интерестны детали реализации, то вся логика TDM лежит в файлах atNetworkProcessor.h / atNetworkProcessor.cpp
Немного по-меньше
За MapNav мегареспект! Лет 10 назад я активно пользовал его на кнопочном телефоне для велопокатушек)
В не думали взять за основу MESHTASTIC?
https://meshtastic.org/
Готовые недорогие железки разной степени навороченности.
Готовая экосистема.
А не думали перейти в режим получения координат от трекеров "по запросу"? Т.е. когда не трекер что-то посылает сам, а центральный сервер по кругу опрашивает трекеры. Т.е. передает в эфир идентификатор трекера и ждет (установленный таймаут) ответа. А трекер, получив свой идентификатор, передает координаты.
Использовали такую схему когда было много устройств (правда не на радиоканале, а на RS485, но не суть) и нужно было всех опрашивать. Так не нужно заниматься разрешением коллизий в сети.
Так проблема с коллизиями только из-за желания получать данные максимально часто. А опрос каждого по очереди будет еще медленее
Сдается мне что проблема именно в желании получать данные максимально часто. Ответьте себе на вопрос: Что конкретно решает отправка с каждого устройства каждые 10 секунд?
Если не нравятся скачущие по карте участники - сделайте в ПО плавное перемещение метки по карте.
Если же важен сам подробный трек, то трекер может отсылать не текущий отсчет, а пакет с несколькими отсчетами сделанными ранее (там по идее можно подумать над эффективной упаковкой на основе метки+[дельты]). Но как по мне, полный трек можно просто в локальную память писать и получить его на "красивой распечатке" на финише.
А вот именно позиции на карте района проведения соревнований - тут мне кажется можно заметно реже отправлять данные - раз в несколько минут. Люди - не ракеты и даже не автомобили. По моему опыту ориентирования, всю дистанцию даже пробежать не все могут, значительную часть маршрута проходится пешком. Средняя скорость от силы километров 5-7 в час.
ПО умеет сглаживать перемещение, для этого оно отображает данные специально с небольшой задержкой и потом усредняет, убирая дергания из-за погрешности некоторых разовых координат. Да, трек можно писать на карту... Но для этого есть хорошие готовые решения, переизобретать не нужно.
Часто получать координаты хочется потому что живая картинка привлекает гораздо больше внимания зрителей, это уже тоже знаем. Поэтому на соревнования часто накапливают трек и потом быстро показывают прохождение некоторого участка дистанции.
А так да, можно раз в полминуты отправку настроить и общая картинка будет достаточно точно передавать ситуацию. Но будет ли за этим интересно смотреть..
В этом случае трекер вынужден держать включенным приёмник постоянно, что высаживает батарею гораздо быстрее, чем периодические кратковременные включения передатчика на короткое время.
К тому же, в случае LoRa, коллизии в эфире не сильно страшны, так как многоканальная базовая станция при демодуляции "цепляется" одним каналом приёма за конкретный пакет, при этом остальные пакеты, "пробегающие" в это время по эфиру являются для неё шумом. И свободные каналы приёма, если они есть, могут принять другой пакет.
И ещё нужно учитывать, что базовая станция обладает гораздо более совершенной антенной и более высокой мощностью передачи, поэтому вероятность получения трекером запроса от станции гораздо выше, чем наоборот, получения станцией полезных данных от трекера. Что сводит на нет идею периодического поллинга трекеров станцией.
В этом случае трекер вынужден держать включенным приёмник постоянно, что высаживает батарею гораздо быстрее, чем периодические кратковременные включения передатчика на короткое время.
Потребление в режиме приема несоизмеримо с потреблением в режиме передачи.
Те же 70см балалайки с небольшим (1000мАч) аккумом в режиме приема спокойно тянут весь день. А вот интенсивная передача высаживает аккум очень быстро.
И ещё нужно учитывать, что базовая станция обладает гораздо более совершенной антенной и более высокой мощностью передачи, поэтому вероятность получения трекером запроса от станции гораздо выше, чем наоборот, получения станцией полезных данных от трекера. Что сводит на нет идею периодического поллинга трекеров станцией.
Конечная цель - получить данные от трекера. И если передатчик трекера не способен "донести" их до станции, то уже все равно в каком режиме все это работает.
Здесь, как я понял, речь идет о работе в режиме разделенного времени. И разница будет только в том - нужно вам настраивать каждый трекер на свой интервал времени или нет. В режиме опроса это совершенно не надо. Но и так и этак - если у вас на полный цикл получения данных отведено заданное время - вы в это время сможете впихнуть только ограниченное количество трекеров. Вне зависимости от режима в котором они работают.
Дальше, при увеличении количества трекеров, вам придется разносить их по группам, каждая из котроых будет работать на своей частоте. Или увеличивать время между получением данных с каждого отдельного трекера. О чем выше уже говорилось.
Если хотите получить плавный трек - 10 секунд очень много. Если просто видеть примерное положение всех участников - излишне часто.
Реализация работы в режиме опроса будет намного проще. В том числе и в настройках трекеров. И намного гибче.
А при большом количестве трекеров все равно потребуется деление их на группы и, возможно, каскадирование - промежуточные контроллеры, каждый из которых работает со своей группой трекеров на своей частоте и потом сбрасывает информацию пачками на центральный сервер.
Когда занимался подобными вещами, мы в своих сетях делали именно так - с промежуточными контроллерами (два уровня было). А количество конечных устройств у нас исчислялось тысячами.
Кроме того, сеть промежуточных контроллеров позволит расширить зону покрытия.
Потребление в режиме приема несоизмеримо с потреблением в режиме передачи.
Приёмник потребляет примерно 12-15 мА, передача на 20 dBm около 100 мА. Примерно 1:7, но передача небольшого пакета, даже на SF12, длится 1-2 секунды, а приёмник включён постоянно, и не отменяет циклов передачи, а идёт плюсом в расход батареи.
Реализация работы в режиме опроса будет намного проще. В том числе и в настройках трекеров. И намного гибче.
При увеличении количества трекеров период опроса будет сильно падать, так как окно опроса сделать маленьким не получится. Из моей практики, порядка 5 секунд на 1 цикл опроса. Добавьте сюда необходимость постоянно обновлять и следить за списком опроса, чтобы не сжирали время трекеры, которые сейчас в ремонте / на зарядке / просто не используются.
Гораздо эффективнее использовать ACK-подтверждения от базовой станции, при этом приёмник включается в строго определённые временные "окна" после передачи пакета. С последующей новой передачей, если ACK не получен, соответственно. Это уже всё решено, если следовать протоколу LoRaWAN. Как и переключение частот передачи из выбранной сетки частот.
Добавьте сюда необходимость постоянно обновлять и следить за списком опроса, чтобы не сжирали время трекеры, которые сейчас в ремонте / на зарядке / просто не используются.
Это-то тут при чем вообще? Опрашиваются только те идентификаторы, кто зарегистрировался на старте.
Гораздо эффективнее использовать ACK-подтверждения от базовой станции, при этом приёмник включается в строго определённые временные "окна" после передачи пакета.
У вас на старт вышло 100 человек. И каждому надо настроить приемник на свое временное окно чтобы все разом не ломились передавать свои данные. Т.е. вам придется каждый раз конфигурировать 100 трекеров разнося им время передачи. Иначе начнутся коллизии. При этом любая перепосылка в случае коллизии будет сжирать аккумулятор несоизмеримо с тем, если бы он просто ждал на приеме пока его спросят.
Это уже всё решено, если следовать протоколу LoRaWAN. Как и переключение частот передачи из выбранной сетки частот.
Да, но все это крайне энергонеэффективно.
Нет, никакие окна настраивать трекерам не нужно, они выходят в эфир псевдослучайным образом и утилизируют эфир, насколько это возможно. Стек LoRaWAN "размазывает" пакеты по частотам и/или Spreading Factor-у, минимизируя вероятность коллизий. К тому же модуляция LoRa позволяет многоканальным станциям вести приём нескольких пакетов одновременно.
И вообще, мы отклонились от главной цели - доставить пакеты на сервер. В случае опроса, для того, чтобы трекер отправил пакет, нужно, чтобы он сначала принял запрос от БС. Что тоже далеко не гарантировано, это радиоканал, человек именно в этот момент может оказаться в "глухой" зоне или просто антенна будет перекрыта телом.
В случае произвольного выхода в эфир улучшение трекинга легко достигается просто добавлением ещё одной или нескольких БС, разбросанных по местности. А что делать в случае поллинга? Несколько станций будут мешать друг другу или "договариваться" между собой о разделении времени эфира. И как поделить список опроса, если непонятно, кто где сейчас? Какое уж тут улучшение...
Зачем каждый раз конфигурировать? Один раз их настроил и всё.
В эфире и так не очень свободно, а вы предлагаете ещё и базовой станции передавать. Причем каждый трэкер надо запрашивать, это ещё в 2 раза увеличит время в эфире. Плюс потери пакетов обычное дело, в обе стороны, ещё и повторные запросы тогда надо делать. С коллизиями нет большой проблемы, время передачи пакета доли секунды. Время передачи делается немного разным у разных трэкеров. И как вариант использовать тайм-слоты, в каждом трэкере ведь есть PPS с GPS, от него и отсчитывать таймслоты.
Прочитал с интересом. Но, всё же, решение получилось костыльное. Как уже выше написали для решения вашей задачи придумали базовые станции LoRaWAN и опен сорс сервера, наподобие chirpstack.
Это банально сокращает трудозатраты и увеличивает емкость сети: 8-миканальная БС протащит заведомо больше, чем модуль лора, предназначенный для применения в конечных устройствах лораван.
Прототипировал в своё время похожее решение:
Чтобы увеличить дальность можно рассмотреть следующие варианты:
Для увеличения дальности LoRA:
1) Взять модули на чипах Si1278-433 или на CC68-433.
2) Сделать Mesh
3) В Центре установить антенну на мачту или дерево (можно на воздушный шар с гелием)
Для увеличения дальности BLE и сделать решение более компактное взять ESP32C3 (мощность BLE больше, чем у JDY. До кучи убираем модуль Arduino )
> Взять модули на чипах Si1278-433
А почему sx1278, а не sx1262? sx1262 это более продвинутый чип с большей дальностью передачи.
С дальностью ble нет особо проблемы, есть USB-свистки с большой внешней антенной. А то что в центре приемник на дерево поднять - это да, само собой. Про шар тоже почему-то шутили (у нас тут был один ночной старт в грозу), хотя сейчас это легко если погода позволяет. Возможно, с шара высотой хотя бы метров 50 будет прием в радиусе нескольких км, не 500м. Если рельф позволяет.
Поясняю:
Про BLE...
У ESP32 мощность передатчика BLE 100 мВт. У JDY-19 максимум 4мВт. Т е мощность передатчика в 25 раз больше. Это означает, что при одинаковой антенне, дальность при ESP будет примерно в 5 раз больше.
Кроме того, можно выкинуть модуль микроконтроллера и получится более компактное решение и дешевле.
--------------------
Про антенну на шаре...
Это не шутка. Вполне серьезно, прорабатывал такой проект для связи с бпла и улучшения связи в отдаленной местности.
Оптимальной высотой является 20 метров. В этом случае прямая видимость увеличивается примерно в 3 раза. При этом сигнал LoRA ,будет распространяться не горизонтально через весь лес, а под углом к поверхности в сторону шара, что существенно снизит поглощение сигнала.
----------------------
Можно сделать сеть с узлами на воздушных шарах. Тогда зона покрытия может быть практически любая.
Как я делал LoRa + GPS-трекер для соревнований по спортивному ориентированию