Пейджинговая сеть на основе ESP32 и модулей LoRa

mike84

Всем добрый день!
Очень заинтересовала вот эта СТАТЬЯ. Она вкратце задает идею создания пейджеров, не зависящих от каких бы то ни было операторов связи.

Основой этой сети будут служить радиомодули на основе технологии LoRa. Они могут быть на различные частоты как на 433 МГц, 868 МГц или 915 МГц. Ранее я сам имел дело с конструированием устройств на ESP32 и модулях LoRa, но там я передавал данные телеметрии и Базовая станция сама запрашивала данные от каждой точки измерений.

Тут же, так себе представляю, также будет Базовая станция, которая в случае необходимости будет рассылать на пейджеры те или иные предопределенные сообщения (которые, кстати, уже могут быть заранее прописаны в каждом пейджере и не будет необходимости передавать полностью все сообщение, а только его номер) или не предопределенные сообщения, которые могут набираться исходя из той или иной необходимости.
После того как сообщение или его номер будет разослано всем абонентам, абонентский пейджер его принимает и дает звуковой сигнал об этом до тех пор, пока абонент не прочитает это сообщение и не подтвердит это прочтение. Вот в этом и кроется самая проблема.
Задачей этой пейджинговой радиосети является не только отправка абонентам сообщений, но и сбор сигналов от абонентов о подтверждении прочтения сообщений - это важно!
Так вот, когда произошла рассылка, абоненты начали читать сообщение и нажимать кнопки отправки сигнала о подтверждении прочтения сообщения, то в любом случае эти сигналы будут накладываться друг на друга и Базовая станция может не понять и не разобрать эти сигналы, кто прочитал, а кто нет... В общем возникнет "каша", которую не сможет разобрать Базовая станция.

В этом и кроется мой вопрос: "Как упорядочить обратные сообщения от абонентов, чтобы Базовая станция приняла все подтверждающие прочтение сообщения сигналы?".

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

Какие у кого на этот счёт будут мысли? Очень будет интересно послушать, ну и я тоже буду параллельно думать над этим вопросом. Тема интересная и хочу обязательно сделать примерно такую систему.

Реклама

roman.com

во первых если уже есть на борту ESP32 то почему бы не сделать связь ещё и через Wi-Fi ?
будет как в обычном телефоне... когда есть Wi-Fi - связь через Wi-Fi... если нет Wi-Fi то связь по LTE (в нашем случае LoRa).
добавить сервер в Интернете... и совсем будет хорошо))

Добавлено after 6 minutes 36 seconds:
во вторых... в сотовой связи GSM уже давно решили эту проблему))
технология TDMA

TDMA.jpg: (42.33 КБ) 137 скачиваний

радио канал поделён на 8 так называемых тай-слота... каждый сотовый телефон работает в своём тайм-слоте... при этом 8 телефонов работают на обной частоте и не мешают друг другу))
базовая станция непрерывно передаёт сигнал маяка... с указанием свободных тайм-слотов...
старый сотовый телефон не имеет никаких GPS)) он просто включается на приём и слушает маяк базовой станции... затем занимает свободный тайм-слот...
это кратко))

Добавлено after 8 minutes 22 seconds:
в третьих... я бы думал в сторону не базовых станций... а в сторону например так называемых Mesh сетей...

Mesh.jpg: (23.34 КБ) 128 скачиваний

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

покрытие.jpg: (41.27 КБ) 98 скачиваний

Добавлено after 7 minutes 6 seconds:
для управления Mesh сетью... я бы например использовал стандартный протокол маршрутизации сети Интернет - автоматическое построение таблиц маршрутизации... выбор оптимального маршрута... контроль сети... и т.д.
Короче стандартные, отработанные за много лет протоколы маршрутизации в сети Интернет.

алгоритм построения маршрута.jpg: (39.21 КБ) 118 скачиваний

Реклама

mike84

roman.com писал(а):будет как в обычном телефоне... когда есть Wi-Fi - связь через Wi-Fi... если нет Wi-Fi то связь по LTE (в нашем случае LoRa).

Я LoRa и хочу использовать, потому как она позволяет передавать низкоскоростную информацию на дальние расстояния.... Wi-Fi совсем для другого и связываться параллельно и с LoRa и c Wi-Fi смысла нет...

roman.com писал(а):во вторых... в сотовой связи GSM уже давно решили эту проблему))

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

roman.com писал(а):радио канал поделён на 8 так называемых тай-слота... каждый сотовый телефон работает в своём тайм-слоте... при этом 8 телефонов работают на обной частоте и не мешают друг другу))
базовая станция непрерывно передаёт сигнал маяка... с указанием свободных тайм-слотов...
старый сотовый телефон не имеет никаких GPS)) он просто включается на приём и слушает маяк базовой станции... затем занимает свободный тайм-слот...
это кратко))

За этот дельный совет спасибо! Вот над этим подумаю.

roman.com писал(а):в третьих... я бы думал в сторону не базовых станций... а в сторону например так называемых Mesh сетей...

Я также и думаю в этом направлении, но на основе LoRa. Но вначале буду решать ту проблему, о которой обозначил.

roman.com

mike84 писал(а):связываться параллельно и с LoRa и c Wi-Fi смысла нет...

смысл есть...
если я нахожусь в городе то проще связаться по Wi-Fi...

1.jpg: (39.78 КБ) 92 скачивания

если я нахожусь в городском парке то проще связаться по Wi-Fi...

wi-fi.jpg: (64.42 КБ) 81 скачивание

даже если я нахожусь за городом... то тоже можно связаться по Wi-Fi... ))

поле.jpg: (40.64 КБ) 84 скачивания

достаточно иметь простейший булит...

булит.jpg: (40.11 КБ) 94 скачивания

а вот если я нахожусь в лесу... то лучше связываться по LoRa...

лес.jpg: (77.58 КБ) 89 скачиваний

Добавлено after 19 minutes 45 seconds:
информация и принцип работы GSM с подробным описанием есть в Интернете в открытом доступе)) никакой военной тайны там нет))

вообще сама идея с базовой станцией... которая непрерывно передаёт сигнал маяка... мне не нравится...
базовая станция должна непрерывно передавать маяк тем самым впустую занимая частоты... и создавая помехи другим участникам радио обмена... На частотах 433 МГц, 868 МГц или 915 МГц работают и другие устройства))

у операторов сотовой связи таких проблем нет)) они купили выделенные частоты и никто кроме них на этих частотах не работает. Поэтому операторы сотовой связи никому не мешают)) и им никто не мешает.
У операторов сотовой связи базовая станция с маяком оправдана... потому что у оператора сотовой связи миллионы абонентов))

абоненты.jpg: (60.68 КБ) 79 скачиваний

для нормальной работы сотовой связи нужна базовая станция с маяками... иначе никак не синхронизируешь работы миллионов абонентов))

Реклама

tonyk

В этом и кроется мой вопрос: "Как упорядочить обратные сообщения от абонентов, чтобы Базовая станция приняла все подтверждающие прочтение сообщения сигналы?".

Странный человек. Пишешь,что работал с ЛоРа, а протоколов LoRAWAN не знаешь. Есть там class B, вот он и отвечает на поставленный вопрос.
Тут вопрос в другом: как организовать разнос пейджеров по разным каналам в условиях, когда ими будут пользоваться все кому не лень?

Реклама

roman.com

вряд ли у нас Пейджинговая сеть будет насчитывать миллионы абонентов))

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

для мелкой частной сети есть варианты по проще)) например диспетчерская / радиолюбительская связь.

Добавлено after 22 minutes 15 seconds:

tonyk писал(а):протоколов LoRAWAN не знаешь. Есть там class B...

я с LoRAWAN не работал)) class B... не знаю))

https://lora-developers.semtech.com/doc ... b-devices/

слоты LoRa.jpg: (30.57 КБ) 104 скачивания

теперь знаю))

Добавлено after 3 minutes:
по сути те же самые маяки что в сотовой связи... только интервал другой))

ничего принципиально нового)) и это не идеальное решение...

Добавлено after 17 minutes 26 seconds:
ещё есть радиолюбительская связь...

в радиолюбительской связи все частоты поделены на каналы. Есть два типа каналов:
1- вызывной канал.
2- рабочий канал.

если например радиолюбитель_1 хочет передать сообщение радиолюбителю_2, то он первым делом переключается на вызывной канал (По умолчанию все радиолюбители непрерывно слушают вызывной канал). После того как радиолюбитель_2 ответит радиолюбителю_1 они оба переключаются на рабочий канал. Далее весь обмен сообщениями происходит на рабочем канале. Обмен сообщениями на вызывном канале запрещён.

1- радиолюбитель_1 >> радиолюбителю_2 (вызов на вызывном канале).
2- радиолюбитель_1 << радиолюбителю_2 (ответ на вызывном канале).
3- радиолюбитель_1 << >> радиолюбителю_2 (переключение на рабочий канал).
4- радиолюбитель_1 << >> радиолюбителю_2 (обмен сообщениями на рабочем канале).

Поэтому в радиолюбительской связи нет "каши" в эфире))

Добавлено after 5 minutes 52 seconds:
в соседней теме по этому принципу работает наше самодельное радиоуправление))
https://www.radiokot.ru/forum/viewtopic ... 8&t=148087

PCM-256.jpg: (150.85 КБ) 79 скачиваний

там несколько радио управляемых моделей используют один вызывной канал (общий для всех) и 124 рабочих каналов.
1- пульт (при включении) вызывает свою модель (по номеру ID) на общем вызывном канале...
2- после ответа модели...
3- пульт и модель переходят на рабочий канал...
4- не мешая остальным радио управляемым моделям ))
короче... технология проверена в железе))

Добавлено after 1 minute 20 seconds:
ЗЫ ))
и всё таки я бы добавил Wi-Fi... раз он уже всё равно есть))

Добавлено after 1 hour 35 minutes 30 seconds:
далее)) синхронизация может быть разной ))

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

пейджер.jpg: (53.78 КБ) 84 скачивания

начало_пакета | сообщение_абоненту_1 | сообщение_абоненту_2 | сообщение_абоненту_3...

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

аналогично было и в RDS радио...

rds.jpg: (36.73 КБ) 80 скачиваний

и телетекст на телевизоре...

телетекст.jpg: (46.18 КБ) 74 скачивания

и т.д.

при этом не важно в какой момент включится пейджер... приёмник... телевизор... синхронизация работала автоматически по заголовку пакета (она же преамбула)...

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

это самый простой и легко реализуемый алгоритм... на любом МК )) без всяких высокоточных часов синхронизации и GPS))

Добавлено after 32 minutes 31 second:
ну хорошо... допустим у нас есть одна базовая станция...
все абоненты синхронизировались по маяку базовой станции и никто никому не мешает))

а что если у нас нет базовой станции ?

репитеры.jpg: (21.65 КБ) 80 скачиваний

например в старом wi-fi все абоненты передавали как попало)) без синхронизации...
точнее сначала абонент слушал эфир... если эфир свободный то абонент начинал передачу...

старый wi-fi.jpg: (35.45 КБ) 76 скачиваний

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

совсем старый wi-fi.jpg: (43.88 КБ) 77 скачиваний

в новом wi-fi (версии 6) устранили эту проблему...
добавили синхронизацию... и сделали рассылку сообщений всем абонентам одним большим пакетом)) ... и т.д.

wi-fi 6.jpg: (27.94 КБ) 87 скачиваний

благодаря этому (и не только этому) скорость нового wi-fi заметно возросла...

скорость.jpg: (39.61 КБ) 76 скачиваний

так что вопрос синхронизации - это важный впорос.

Добавлено after 56 seconds:
а как это всё сделать в сети LoRa... я пока не до конца представляю))

Реклама

tonyk

roman.com писал(а):а как это всё сделать в сети LoRa... я пока не до конца представляю))

Достаточно прочитать стандарт.

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

roman.com

да читал я спецификацию... ничего нового для себя не нашёл))
все друг у друга крадут технологии... только названия меняют... и выдают за новую технологию))

думал развернуть свою сеть... только у меня на первом месте Интернет. А радио - просто запасной канал связи))
и к LoRa я не привязан)) я не фанал LoRa...

Добавлено after 2 minutes 41 second:
мы ещё шифрование не обсудили... как вы там его собираетесь делать...

Morroc

для каши нужно еще абонентов наделать, а то может и банальная рандомная задержка решит проблемы разнесения абонентов во времени

roman.com

это не важно))
без выхода в Интернет вы и трёх абонентов не соберёте))
[uquote="mike84",url="/forum/viewtopic.php?p=4266063#p4266063"]Wi-Fi совсем для другого и связываться параллельно и с LoRa и c Wi-Fi смысла нет...[/uquote]
будете вокруг дома бегать... со своими пейджерами...

покрытие сети без выхода в Интернет.jpg: (38.23 КБ) 81 скачивание

))

в наше время никто не строит локальные изолированные сети...

mike84

roman.com, большое спасибо Вам за информацию

, критику и предложения!!!

[uquote="roman.com",url="/forum/viewtopic.php?p=4266081#p4266081"]смысл есть...
если я нахожусь в городе то проще связаться по Wi-Fi...[/uquote]
Все-таки не вижу смысла замарачиваться с Wi-Fi. Пароли на Wi-Fi изменяются, сети включаются/выключаются и т.д. Всю эту информацию нужно корректировать в мобильной станции (далее - МС) и т.д. К тому-же не так уж и много этих сетей Wi-Fi... Лучше установить еще несколько ретрансляционных станций LoRa (далее - РС) и вопрос закроется.

roman.com писал(а):Тут вопрос в другом: как организовать разнос пейджеров по разным каналам в условиях, когда ими будут пользоваться все кому не лень?

Тут вообще не вижу проблем... Все устройства будут работать на одной частоте и кому не лень использоваться не будут.

roman.com писал(а):базовая станция будет по кругу рассылать сообщения для всех абонентов... а все абоненты сами синхронизируются по заголовку пакета (она же преамбула)...
а в паузах между пакетами базовой станции абоненты могут передавать сообщения другим абонентам... напрямую или через базовую станцию...

Эту логику я обдумал, но предложу немного иную...

roman.com писал(а):мы ещё шифрование не обсудили... как вы там его собираетесь делать...

Шифрование AES256 уже отработано на таких устройствах, библиотеки есть, так что проблем не составит.

Morroc писал(а):для каши нужно еще абонентов наделать, а то может и банальная рандомная задержка решит проблемы разнесения абонентов во времени

Такая логика не подойдет, так как все равно есть вероятность наложения сообщений от МС.
---е------------------------е---------------------------------------------------------е------------------------е----------------------

На первых парах накрапал вот такую логику.
Сама сеть состоит из базовой станции (далее - БС) и нескольких РСх и определенного количества МСх (скажем до 50 штук).

1) Рассылка БС необходимого сообщения всем МСх.
2) Рассылка РС1 этого же сообщения всем МСх.
3) Рассылка РС2 этого же сообщения всем МСх. И т.д.
Если МС получает повторно тоже сообщение, то игнорирует его и повторно на экран пейджера не выводит и звуковой сигнал не дает.
То есть таким образом мы сделали рассылку БС и всеми РСх необходимого сообщения.
4) Запрос БС у каждой МСх подтверждения о получении сообщения. Номера тех МСх, которые не дали такого подтверждения отправляются на РС1 (далее - Номера 1).
5) Запрос РС1 у каждой МСх под Номерами 1 подтверждения о получении сообщения.
Номера тех МСх, которые не дали такого подтверждения отправляются на РС2.
Номера тех МСх, которые подтвердили получение сообщение, отправляются на БС.
6) и так далее...

Добавлено after 22 minutes 5 seconds:
Такая логика, например:
Групповое сообщение от БС | ответ МС1 | ответ МС 2 | ответ МС3, -
не получится, так как в этом случае необходимо, чтобы каждая МС знала свой момент времени для отправки своего ответа.... А как она это будет то знать? Устанавливать счетчики времени (от момента времени конца сообщения БС до момента времени своей передачи) и выделять фиксированное время на ответ для каждой МС думаю нецелесообразно... это усложнит алгоритм. А с большим количеством МС это станет в принципе невозможным. Все равно же это время, выделяемое на ответ МС, мы будем давать с неким запасом, так лучше время на этот запас использовать на индивидуальный запрос от БС на МС. Так будет четче логика и будет последовательно понятно что кто должен.

Morroc

[uquote="mike84",url="/forum/viewtopic.php?p=4267815#p4267815"]Такая логика не подойдет, так как все равно есть вероятность наложения сообщений от МС.[/uquote]
это неважно, коллизии в этом случае норма, нужно просто учесть этот момент

mike84

[uquote="Morroc",url="/forum/viewtopic.php?p=4267821#p4267821"][uquote="mike84",url="/forum/viewtopic.php?p=4267815#p4267815"]Такая логика не подойдет, так как все равно есть вероятность наложения сообщений от МС.[/uquote]
это неважно, коллизии в этом случае норма, нужно просто учесть этот момент[/uquote]
Так а зачем заранее закладывать в алгоритм возможное возникновение неких коллизий?, если можно сразу от этого уйти?

roman.com

Шифрование AES256... это хорошо))
а как происходит обмен ключами ? в двух словах...

коллизии это не норма)) коллизии были в старых системах связи... В современном Интернете и сотовой связи коллизий нет.
В интернете полный дуплекс на разнесённых линиях связи (пара проводов TX и пара проводов RX)...
А в оптике разнесённые частоты (В одномодовом волокне на котором работает вся сотовая связь и мобильный Интернет: 1310 нм TX и 1550 нм RX).

Медиаконвертер.jpg: (28.68 КБ) 78 скачиваний

И т.д.

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

схема.jpg: (33.94 КБ) 70 скачиваний

а когда коммутатору надо передать пакет конкретному абоненту то коммутатор знает где находится абонент...
(коммутатор знает в зоне действия какой базовой станции находится абонент в данный момент).
поэтому коммутатор сразу передаёт пакет на конкретную БС (указав номер ID базовой станции + номер ID абонента).

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

Добавлено after 5 minutes 39 seconds:
осталось почитать тайминги... и прикинуть как это всё будет работать на одной частоте))
у меня все пакеты фиксированной длины... и время передачи одного пакета известна... поэтому я без труда могу всё посчитать))

PCM-256.jpg: (150.85 КБ) 80 скачиваний

и что будет с 50 абонентами... можно прикинуть))

Добавлено after 2 hours 6 minutes 41 second:
тайминги... тайминги... тайминги... с 50 абонентами...))

mike84 писал(а): 1) Рассылка БС необходимого сообщения всем МСх.
2) Рассылка РС1 этого же сообщения всем МСх.
3) Рассылка РС2 этого же сообщения всем МСх. И т.д.
Если МС получает повторно тоже сообщение, то игнорирует его и повторно на экран пейджера не выводит и звуковой сигнал не дает.
То есть таким образом мы сделали рассылку БС и всеми РСх необходимого сообщения.
4) Запрос БС у каждой МСх подтверждения о получении сообщения. Номера тех МСх, которые не дали такого подтверждения отправляются на РС1 (далее - Номера 1).
5) Запрос РС1 у каждой МСх под Номерами 1 подтверждения о получении сообщения.
Номера тех МСх, которые не дали такого подтверждения отправляются на РС2.
Номера тех МСх, которые подтвердили получение сообщение, отправляются на БС.
6) и так далее...

Добавлено after 29 minutes 54 seconds:
ааа ! не так... а вот так ! ))

1) Рассылка БС необходимого сообщения всем МСх... одним большим пакетом...

БС > TX | МС1 | МС2 | МС3 | МС4....

допустим))

4) Запрос БС у каждой МСх подтверждения о получении сообщения (далее ACK - англ. Acknowledge — подтверждение).

Tак ???

БС > TX ACK | МС1.............
БС < RX ACK | МС1.............

БС > TX ACK | МС2.............
БС < RX ACK | МС2.............

получилась фигня)) сначала отправляем пакет... потом отправляем ACK ... Слишком много бесполезных пакетов ))

Тогда лучше не одним пакетом... а адресовать каждый пакет на каждый пейджер отдельно))

БС > TX | МС1.............
БС < RX ACK | МС1.............

БС > TX | МС2.............
БС < RX ACK | МС2............

так нормально))

если в установленное время (тайм-аут) ACK нет... то переадресуем пакет на РС ... ))

отправка сообщения БС > МС1
БС > TX | МС1.............
тайм-аут............

переадресация БС > PC1
БС > TX | PС1.............

отправка сообщения PС1 > МС1
PС1 > TX | МС1...........
PС1 < RX ACK | МС1....

отправка ACK PС1 > БС
БС < RX ACK | PС1....

уже лучше))

а ещё добавим передачу сообщений об ошибках... (далее IMCP).

отправка сообщения БС > МС1
БС > TX | МС1.............
тайм-аут............

переадресация БС > PC1
БС > TX | PС1.............

отправка сообщения PС1 > МС1
PС1 > TX | МС1...........
тайм-аут............

отправка IMCP PС1 > БС
БС < RX IMCP | PС1.... "заданный узел не найден".... ))

совсем хорошо))

получился стандартный Интернет протокол))

Добавлено after 2 minutes 11 seconds:
осталось решить что делать PС1 если он захочет отправить сообщение БС... на той же частоте... при отсутствии синхронизации))

mike84

roman.com писал(а):а как происходит обмен ключами ? в двух словах...

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

.

roman.com писал(а):1) Рассылка БС необходимого сообщения всем МСх... одним большим пакетом...

Обычным пакетом с флагом о том, что он предназначен для всех.

roman.com писал(а):4) Запрос БС у каждой МСх подтверждения о получении сообщения.
Как ???

По принципу: Вопрос - ответ.
Вопрос: БС шлет запрос каждой МС, состоящий из двух вопросов: 1) получила ли ты сообщение?; 2) подтвердил ли клиент получение сообщения (нажал ли кнопку)?).
Ответ: МС отвечает: 1) Да, я получила сообщение; 2) клиент нажал кнопку о прочтении сообщения.
Это будет происходить быстро, так что это много времени не займет (если конечно на Lora не будет выставлена самая минимальная скорость, тогда реально будет не быстро. Хотя так как сам пакет будет короткий, то и это будет быстро).

roman.com писал(а):получилась каша))

В чём "каша"?

Вначале передаём один раз (пакет) для всех, потом спрашиваем каждого о его статусе (Получило ли МС сообщение: да/нет; если получило, то абонент нажал ли кнопку о подтверждении: да/нет?)?

roman.com писал(а):получилась фигня))

почему?

roman.com писал(а):если в установленное время (тайм-аут) ACK нет...

Если после того как последняя РС приняла ответы от МС и все-таки кое-какие МС не получили (не путать с тем, что если МС получила сообщение, а клиент просто не прочитал), то она (последняя РС) отсылает информацию на БС, что, к примеру, 25-й и 34-й не получили сообщение (тут можно устроить повторную рассылку именно этим МС). Если получили ответ от последней РС, что 25-й и 34-й получили сообщения, но клиенты их не прочитали, то повторную рассылку не производим, а производим повторные запросы (на 25-ю и 34-ю МС) о статусе вопроса: нажал ли клиент на кнопку подтверждения прочтения сообщения или нет?

roman.com писал(а):осталось решить что делать PС1 если он захочет отправить сообщение БС... на той же частоте... при отсутствии синхронизации))

Обратную рассылку сообщений (от МС к другой (-им) МС) я пока не рассматриваю, это нужно городить клавиатуру на МС. Конечно можно было связать МС со смартфоном и на смартфоне набрать сообщение, но я хочу, чтобы устройство МС было единое и ни от чего не зависело (ни от глюков смартфона и ни от его разряженной батареи и т.д.).

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

roman.com

каша будет в случае с автоматическим ACK...

автоматический ACK... это когда МС сразу после получения отправляет автоматически ACK...

в случае автоматического ACK нужен таймер...
[uquote="roman.com",url="/forum/viewtopic.php?p=4267843#p4267843"]4) Запрос БС у каждой МСх подтверждения о получении сообщения.

БС < RX | МС1.............
БС < RX | МС2.............
БС < RX | МС3.............
БС < RX | МС4.............

получилась каша))

добавим таймер...

БС < RX | МС1.............
БС < RX | ..........МС2...
БС < RX | ...................МС3............
БС < RX | ..........МС4...

а так нормально))[/uquote]
при отсутствии автоматического ACK каши не будет))

Если вначале передаём один раз (пакет) для всех, потом спрашиваем каждого о его статусе (Получило ли МС сообщение: да/нет; если получило, то абонент нажал ли кнопку о подтверждении: да/нет?)?
то получим в два раза больше пакетов...
а зачем нам передавать в два раза больше пакетов ? если мы можем отправлять по одному пакету данных каждой МС... с автоматическим ACK... ?

roman.com писал(а): БС > TX | МС1.............
БС < RX ACK | МС1.............

БС > TX | МС2.............
БС < RX ACK | МС2.............

БС тупо по кругу отправляет сообщения на все МС...
А все МС с автоматическим ACK...

в автоматическом ACK содержится ответ на вопрос:
(Получило ли МС сообщение: да/нет; если получило, то абонент нажал ли кнопку о подтверждении: да/нет?)?

Добавлено after 21 minute 22 seconds:
делить пакеты на данные и ACK имеет смысл если мы будем отправлять большие пакеты данных))

в этом случае выгоднее сначала отправить данные одним большим пакетом...

БС > МС1... 43578347583475893475348957348957438957343248209384023849023423048230489
БС > MC2... 09348534853485903509592398234897239847298342321315345645621893781273129
БС > MC3... 92323578934983458934589348598572983781748127828394782374823742374923789

а затем запросить ACK...

БС > МС1... ACK
БС > MC2... ACK
БС > MC3... ACK

в этом случае пакеты ACK намного короче пакетов данных...
тогда нормально))

автоматический ACK делать не будем... потому что у нас нет синхронизации))

Добавлено after 11 minutes 42 seconds:
все РС поддерживают IMCP...

IMCP.jpg: (91.4 КБ) 77 скачиваний

Добавлено after 2 minutes 20 seconds:
значит у нас будет пейджер... и несколько кнопок))

пейджер.jpg: (57.06 КБ) 71 скачивание

вкл-выкл...
прочитать...
прокрутить...

Добавлено after 4 minutes 19 seconds:
[uquote="mike84",url="/forum/viewtopic.php?p=4267883#p4267883"]Обычным пакетом с флагом о том, что он предназначен для всех.[/uquote]
далее... Broadcast
(Широковещательный канал, широковещание (англ. broadcasting) — метод передачи данных, при котором поток данных (каждый переданный пакет в случае пакетной передачи) предназначен для приёма всеми участниками сети).

Добавлено after 5 minutes 9 seconds:
[uquote="mike84",url="/forum/viewtopic.php?p=4267883#p4267883"]Обратную рассылку сообщений (от МС к другой (-им) МС) я пока не рассматриваю, это нужно городить клавиатуру на МС.[/uquote]

а как мы будем передавать сообщения ?

раньше пейджеры работали так...
1- был компьютер.
2- компьютер был подключён к БС.
3- набираем сообщение на компьютере... Компьютер передаёт наше сообщение в эфир.

схема.jpg: (55.76 КБ) 64 скачивания

за компьютером сидела... девушка))

оператор.jpg: (53.17 КБ) 70 скачиваний

я звонил по телефону девушке...
девушка набирала сообщение на компьютере...
сообщение передавалось в эфир...

а где мы найдём девушку ? ))

mike84

roman.com писал(а):каша будет в случае с автоматическим ACK...
автоматический ACK... это когда МС сразу после получения отправляет автоматически ACK...
в случае автоматического ACK нужен таймер...

Вас понял, ACK (подтверждение о получении пакета) мы получаем позже, после полной рассылки.

roman.com писал(а):БС тупо по кругу отправляет сообщения на все МС...
А все МС с автоматическим ACK...

Вас понял, но нам все равно нужно будет опрашивать МС для того, чтобы получить информацию о прочтении сообщения клиентом. Таким образом уже точно будет намного больше пакетов. Т.е. ответ АСК МС и потом еще один отдельный ответ МС о прочтении... Хотя после всеобщей рассылки я предлагаю один раз спрашивать у МС и получать сразу два ответа: о получении и о прочтении.

roman.com писал(а):в автоматическом ACK содержится ответ на вопрос:
(Получило ли МС сообщение: да/нет; если получило, то абонент нажал ли кнопку о подтверждении: да/нет?)?

Так как (как предлагаете Вы) ответ АСК от МС будет практически сразу же (т.е. МС получило сообщение и сразу дает ответ АСК), то клиент в большинстве случаев не успеет прочесть сообщение и нажать кнопку (Клиент: услышал что что-то там пикает

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

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

roman.com писал(а):делить пакеты на данные и ACK имеет смысл если мы будем отправлять большие пакеты данных))

в этом случае выгоднее сначала отправить данные одним большим пакетом...

БС > МС1... 43578347583475893475348957348957438957343248209384023849023423048230489
БС > MC2... 09348534853485903509592398234897239847298342321315345645621893781273129
БС > MC3... 92323578934983458934589348598572983781748127828394782374823742374923789

Первоначально БС не будет слать одно и тоже сообщение индивидуально каждой МС. В этом нет смысла. БС будет делать всеобщую рассылку сообщения для всех МС. Это уже в самом конце, если нужно будет "достучаться" до каких-либо МС, то да, будет индивидуальная рассылка для определенных МС.

roman.com писал(а):значит у нас будет пейджер... и несколько кнопок))

Да-да!

roman.com писал(а):далее... Broadcast
(Широковещательный канал, широковещание (англ. broadcasting) — метод передачи данных, при котором поток данных (каждый переданный пакет в случае пакетной передачи) предназначен для приёма всеми участниками сети).

да, Broadcast

roman.com писал(а): а как мы будем передавать сообщения ?

раньше пейджеры работали так...
1- был компьютер.
2- компьютер был подключён к БС.
3- набираем сообщение на компьютере... Компьютер передаёт наше сообщение в эфир.

Да, все верно! Я понял, что Вы хотите "Клаву", встроенную в МС... - это нет... А "Клава" на стороне БС будет обязательно!!!

roman.com писал(а):а где мы найдём девушку ? ))

ооо, дорогой друг

, с этим проблем не будет! Хорошую самочку

мы найдем всегда!

roman.com

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

Добавлено after 1 minute 14 seconds:
значит нужен типа автоматический сервер... с интернетом... и/или телефоном... который будет вместо девушки делать рассылки...

Добавлено after 17 minutes 24 seconds:
ну раз подключения к телефону не будет... ни Wi-Fi... ни блютуз...

блютус.jpg: (43.93 КБ) 82 скачивания

тогда не понятно зачем нам ESP32... всё это можно сделать на простой ардуино...

а клаву я бы всё таки добавил...

клава.jpg: (49.87 КБ) 75 скачиваний

можно из старого телефона...

телефон.jpg: (16.24 КБ) 66 скачиваний

а можно сенсорный экран...

сенсор.jpg: (30.66 КБ) 74 скачивания

и т.д.

так и не решили что с девушкой сервером ))

Добавлено after 1 minute 32 seconds:
экранчик совсем маленький... не видно нифига)) нужно чуть-чуть побольше))

эранчик.jpg: (64.05 КБ) 72 скачивания

mike84

roman.com писал(а):хорошая самочка... стоит денег)) её нужно кормить... и зарплату платить))
я так понимаю у нас проект некоммерческий... и спонсоров нет))

Добавлено after 1 minute 14 seconds:
значит нужен типа автоматический сервер... с интернетом... и/или телефоном... который будет вместо девушки делать рассылки...

Добавлено after 17 minutes 24 seconds:
ну раз подключения к телефону не будет... ни Wi-Fi... ни блютуз...

Да, проект конечно некоммерческий... Честно пока не думал каким образом сообщения загонять на БС. Думаю, что можно на БС сделать еще вэб-"морду", БС по Wi-Fi связать с сетью, в которой будет комп. На компе заходим по ip на вэб-"морду" БС и печатаем сообщение и отправляем. Либо прикрутить к БС Ethernet-модуль (это для того, чтобы можно было ESP32 вместе со всем борохлом вынести на крышу - т.к. ESP32 будет непосредственно соединяться с радиомодулем).

roman.com писал(а):тогда не понятно зачем нам ESP32... всё это можно сделать на простой ардуино...

На стороне МС думаю вполне может и хватить Arduino (смотря что еще прикручивать к МС), а БС точно нужно будет делать на основе ESP32.

roman.com писал(а):а клаву я бы всё таки добавил...

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

roman.com писал(а):а можно сенсорный экран...

Да, это вариант, согласен. Экранчик побольше и вперед!

roman.com писал(а):так и не решили что с девушкой сервером ))

Все решаемо!!! Девушку нужно использовать по назначению

, а потом уже ставить другие задачи!

roman.com писал(а):экранчик совсем маленький... не видно нифига)) нужно чуть-чуть побольше))

Да, экранчик ну очень маленький... Однозначно будем увеличивать!

Morroc

[uquote="mike84",url="/forum/viewtopic.php?p=4267824#p4267824"]Так а зачем заранее закладывать в алгоритм возможное возникновение неких коллизий?, если можно сразу от этого уйти?[/uquote]
так проще и при небольшом числе абонентов ничего плохого в этом нет