nRF24L01 - протокол для master/slave сети

[roman.com]

А чё там вчитываться))
На следующей странице показаны тайминги работы приёмника... Так называемый режим WOR

WOR.jpg

(69.01 КБ) 234 скачивания

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

Потребляемый ток в режиме WOR - 35 микроампер (зависит от того как часто приёмник просыпается).

ток.jpg

(92.84 КБ) 158 скачиваний

Ничего нового не изобрели)) В старых сотовых телефонах приёмник работал так же.
У них даже зелёный светодиод мигал каждую секунду (полторы) - это включался приёмник и опять уходил в сон.

старый сотовый телефон.jpg

(52.73 КБ) 218 скачиваний

Так же работали и домашние радиотелефоны... Panasonic... DECT... и даже рации так работали))
Короче ничего нового.

С таким же успехом можно подключить nRF24L01 , которая будет просыпаться каждые несколько миллисекунд отправлять пакет мастеру и опять уходить в сон.
nRF24L01 даже круче будет)) я подавал пинание на nRF24L01 с любого пина МК.
У меня nRF24L01 не просто уходила в сон а вообще отключалось питание nRF24L01.
При этом потребляемый ток nRF24L01 был 0 микроампер ! ))

[ARV]

ага.
всё так.

только есть нюансик

мастер может посылать пакеты в CC1101 раз в час, и все это время датчик будет потреблять 35 мкА, включая микроконтроллер в нем, который тоже будет спать глубоко-глубоко. а NRF сама по себе ничего отправить не может, поэтому впридачу к ее 14 мА каждые несколько миллисекунд надо прибавть еще минимум 5 мА потребления МК.

при этом если двум датчикам приспичит одновременно что-то послать, мастер на оба плюнет, чего в случае с CC1101 быть не может по определению... а так все хорошо, прекрасная маркиза. особенно когда сеть состоит из 3 узлов, включая мастера, а не из 30 или, тем паче, из 300.

[roman.com]

[uquote="jcxz",url="/forum/viewtopic.php?p=3992533#p3992533"]по такому алгоритму работают ведомые устройства в ZigBee-сети. Почитайте про ZigBee.
Раз ZigBee придумали - наверное оно кому-то нужно, правда?[/uquote]
Всё работает одинаково)) и ZigBee тоже))
А вот кому это нужно... х.з. ))
[uquote="jcxz",url="/forum/viewtopic.php?p=3992533#p3992533"]у меня вот собранный ещё в середине осени девайс на nRF24L01+ (всё время включенный, но большую часть времени - в PowerDown, только иногда выходящий на передачу) до сих пор работает от той же самой пары AA полудохлых.[/uquote]
Это вообще ни о чём... Всё зависит от отношения времени - радио модуль активный/не активный.
Цифры в студию ! ))


Добавлено after 26 minutes 13 seconds:

мастер может посылать пакеты в CC1101 раз в час, и все это время датчик будет потреблять 35 мкА

35 мкА потребляет НЕПРЕРЫВНО - это дофига !!!))

NRF сама по себе ничего отправить не может

А ей и не надо. За неё все сделает МК.

поэтому впридачу к ее 14 мА каждые несколько миллисекунд надо прибавть еще минимум 5 мА потребления МК.

Ничего подобного ! ))
У меня nRF24L01 не просто уходила в сон а вообще отключалось питание nRF24L01.
При этом потребляемый ток nRF24L01 был 0 микроампер ! ))
Остаётся только один МК.
А потребляемый ток МК в режиме глубокого сна - 3...5 мкА.
Хотя и ток МК можно уменьшить... Добавить пару транзисторов в схему для внешнего таймера - мультивибратора))

при этом если двум датчикам приспичит одновременно что-то послать, мастер на оба плюнет, чего в случае с CC1101 быть не может по определению... а так все хорошо, прекрасная маркиза. особенно когда сеть состоит из 3 узлов, включая мастера, а не из 30 или, тем паче, из 300.

Ну и что. Вероятность коллизии при отправки пакета раз в час - крайне низкая.
Для борьбы с коллизиями есть ACK.
Ничего страшного не случится, если с первого раза пакет не дойдёт и МК повторит передачу.
Просто увеличится потребляемый ток в два раза (т.к. время передачи пакета с повтором увеличится в два раза).
Но, повторяю, при передачи пакетов один раз в час вероятность коллизии крайне мала.
Сейчас даже почитаем сколько точно))

[NiTr0]

[uquote="ARV",url="/forum/viewtopic.php?p=3992373#p3992373"]если вам нужна экономичность, то надо искать приёмопередатчики, которые в режиме приема потребляют микроамперы, а не извращаться с тем, что жрет, как не в себя.[/uquote]
примеры в студию, с дальностью близкой к nRF24L01

[uquote="ARV",url="/forum/viewtopic.php?p=3992373#p3992373"]ваша идея все равно нежизнеспособна, т.к. при некотором количестве слейвов мастер все равно будет все пакеты сбрасывать, поскольку из-за коллизий не сможет разобраться в них.[/uquote]
в том же эзернете вполне нормально обработка коллизий например реализована. сотня хостов, разнесенных на расстояние до 500 метров, вполне себе уживается при активном обмене (до 10 мбит/с).


[uquote="ARV",url="/forum/viewtopic.php?p=3992373#p3992373"]или вот вариант: CC1101 https://amperkot.ru/products/radiomodul ... 48604.html - этот модуль может сам просыпаться по наличию радиосигнала, скорость поменьше, но экономичность побольше, а для передачи данных датчика скорость не так важна. в спячке вроде как 0,5 мкА потребляет[/uquote]

нет, не может сам просыпаться:

The optional Wake on Radio (WOR) functionality enables CC1101 to periodically wake up from SLEEP and listen for incoming packets without MCU interaction.

при этом:

Low current consumption (14.7 mA in RX, 1.2 kBaud, 868 MHz)

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

Добавлено after 10 minutes 21 second:
[uquote="jcxz",url="/forum/viewtopic.php?p=3992533#p3992533"]1мА - это уже какой-то лошадиный ток! [/uquote]
само собой лошадиный. но речь о том, что логика "мастер командует, слейвы все время слушают и исполняют" даже с таким лошадиным током не реализуема. ultra low power - они либо десятки мА кушают, либо - сугубо приемники со смешными -50..-60dBm по входу...

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

[roman.com]

Для начала ещё раз внимательно все прочитали даташит CC1101.
В двух словах:
CC1101 в режиме WOR:
-работает только RC-генератор (кварцевый генератор и встроенный процессор - отключены).
-RC-генератор через каждые несколько миллисекунд включает блок приёмника (кварцевый генератор и встроенный процессор - по прежнему отключены).
-если блок приёмника обнаруживает сигнал то включаются кварцевый генератор и встроенный процессор. CC1101 переходит в режим приёма и обработки пакета.
-в режим приёма и обработки пакета потребляемый ток 14 mA.
-в режиме WOR, когда работает только RC-генератор, который каждые несколько миллисекунд кратковременно включает блок приёмника - потребляемый ток 35 микроампер.
Думаю разобрались))

в том же эзернете вполне нормально обработка коллизий например реализована. сотня хостов, разнесенных на расстояние до 500 метров, вполне себе уживается при активном обмене (до 10 мбит/с).

Коллизии были только в старом изернет 10 мбит/с , который работал по коаксиальному кабелю в режиме симплекс.
Топология - общая шина.
В новом изернете 10 мбит/с и 100 мбит/с коллизий нет от слова совсем)) Новый изернет 10 мбит/с и 100 мбит/с работает работает в режиме дуплекс.
Топология - звезда.
С изернетом разобрались))

Коллизии есть в старом Wi-Fi. Там все дружно слушают одну частоту и пытаются передать кому как вздумается. Без общей синхронизации.
В новом Wi-Fi 6 (теперь он так называется) коллизии... свели к минимуму. Тем все устройства синхронизированы (только те что поддерживают Wi-Fi 6).
Теперь там другие коллизии... Например когда одно устройство Wi-Fi 6 не видет другое устройство Wi-Fi 6 и пытается передавать пакеты... Но это уже другая тема))
С Wi-Fi разобрались))

Теперь считаем потребляемый ток NRF.
-время передачи пакета NRF ~1,2 мс.
(при скорости 250 кБит/c один бит - 4 мкс) (преамбула 8 бит + адрес 40 бит + Data 256 бит + CRC 16 бит = 1,2 мc)
(+ PLL 0,13 мс + SPI МК + обработка пакета = 1,5 мс)
NRF: TX = 1,5 мс, RX = 1,5 мс
Итого: 3 мс

Если передавать пакеты каждую минуту:
1 минута = 60 секунд.
Отношение активный/не активный = 60 / 0,003 = 20.000
Потребляемый ток NRF (1 пакет каждую минуту) = 12 mA / 20.000 = 0,0006 mA. (Или 0,6 микроампер).

Вывод: при передачи пакетов каждую минуту общий потреблямый ток NRF составляет 0,6 микроампер !!! ))

Обратите внимание NRF отправляет пакет мастеру TX = 1,5 мс и получает от мастера подтверждение доставки пакета RX = 1,5 мс.
Гарантированная доставка пакетов с общим током потребления NRF = 0,6 микроампер !!! ))
Круто))
А если отправлять пакеты один раз в час ?

0,6 микроампер / 60 минут = 0,01 микроампер !!! ))

Дальше посчитайте сами))

На сколько нам хватит батарейки ? Батарейка Duracell 2 шт ёмкостью грубо 500 mA/час.
500 mA/час / (1 пакет каждую минуту) 0,0006 mA = 833.333 часов работы.
или 34.722 дня работы.
или 95 лет работы.))

Скорее батарейка просто сдохнет от старости))

Вероятность коллизии.
Какова вероятность коллизии при передачи одного пакета каждую минуту (отношение активный/не активный = 1/20.000) ?
Если в схеме два датчика, то вероятность того что они нажнут передавать одновременно = 1/20.000. Нормально.
Если в схеме 1000 датчиков, то вероятность того что они нажнут передавать одновременно = 1/20. Нормально.
Вообще то вероятность считается не так... Там всё через графики и коэффициенты... Ну да ладно))
Реально в схеме не будет 1000 датчиков. Максимум ~20 штук. ))
Поэтому предлагаю вообще забить на коллизии)) Достаточно простого ACK для гарантированной доставки пакетов.

На самом деле всё зависит от трафика. Если устройств мало (<1000) и время передачи один раз в минуту - то коллизии пофигу))
Важно ещё добавить во все устройства генератор случайных чисел. Чтобы все устройства передавали пакеты через случайное время. Чтоб не было "зацикливания коллизий" Точно так же как сделано в старом Wi-Fi или старом изернет. Тогда всё будет хорошо))

[TrumPIC]

Теперь считаем потребляемый ток NRF.
-время передачи пакета NRF ~1,2 мс.
(при скорости 250 кБит/c один бит - 4 мкс) (преамбула 8 бит + адрес 40 бит + Data 256 бит + CRC 16 бит = 1,2 мc)
(+ PLL 0,13 мс + SPI МК + обработка пакета = 1,5 мс)
NRF: TX = 1,5 мс, RX = 1,5 мс
Итого: 3 мс

Не совсем так. Ежели он был в спячке, то сперва надо раскачать кварц..

Tpd2stby Power Down Î Standby mode 1.5ms Internal crystal oscillator

После чего надо еще чтоб всё проинитилось внутри:

Tstby2a Standby modes Î TX/RX mode 130µs

..и лишь затем всё приёмы/передачи..

[ARV]

еще добавьте милиамперы самого МК, который будет рулить NRF-кой

[roman.com]

Ну хорошо. На раскачку кварца ещё 1,5 мс.
На самом деле всё зависит от добротности кварца (от 1,5 мс до 4,5 мс).

ВКЛ_NRF.jpg

(47.13 КБ) 205 скачиваний

Но как мы знаем китайцы экономят на всём)) Поэтому в NRF самый дешёвый кварц - от 1,5 мс ))

Итого: 4,5 мс

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

На сколько нам хватит батарейки ?
60 лет работы))

[ARV]

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

это почему вдруг не будем учитывать? NRF без МК - просто кусочек пластика с вкраплениями металла.

[roman.com]

патаму шо у нас схема с ультра низким потреблением. )))
питание на МК поступает от внешнего генератора импульсов (на полевых транзисторах).
в нормальном состоянии питание на МК и NRF отсутствует.

[ARV]

в нормальном состоянии питание на МК и NRF отсутствует

это откуда известно? ТС об этом ни слова не говорил.
далее: кто включает питание МК, когда надо мастеру что-то послать? есть третий участник процесса?

[roman.com]

ТС об этом ни слова не говорил.

он стесняется))

кто включает питание МК, когда надо мастеру что-то послать?

Если это датчик протечки

датчик.jpg

(34.13 КБ) 209 скачиваний

то питание МК включается каждую минуту (мультивибратор на полевых транзисторах):
датчик протечки передаёт мастеру:
-протечки нет...
-протечки нет...
-протечки нет...

есть третий участник процесса?

есть - вода))
при попадании воды питание МК включает постоянно (питание МК через полевой транзистор):
-протечка !...
-протечка !...
-протечка !...

Аналогично с датчиком сигнализации на дверь... и с датчиком температуры за окном... и т.д. и т.п.

Таким образом МК и NRF потребляют ток только при передачи пакета "всё нормально" или при срабатывании датчика.
В остальное время питание на МК и NRF отсутствует.

[ARV]

а сеть из датчиков протечек - это для кабинетов в сауне? или где может пригодиться?

[NiTr0]

[uquote="roman.com",url="/forum/viewtopic.php?p=3992913#p3992913"]В новом изернете 10 мбит/с и 100 мбит/с коллизий нет от слова совсем)) Новый изернет 10 мбит/с и 100 мбит/с работает работает в режиме дуплекс.
Топология - звезда.[/uquote]

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

[uquote="roman.com",url="/forum/viewtopic.php?p=3992913#p3992913"]Поэтому предлагаю вообще забить на коллизии)) Достаточно простого ACK для гарантированной доставки пакетов.
[/uquote]
проще уж как в эзернете - если не получен аск, засыпать на рандомное время и повторять отправку.

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

[roman.com]

можно что-то типа домофона даже прикручивать в ту же сеть

как ? передача звука через NRF ? Можно... Только звук займёт весь канал связи... Если без кодеков))

а мне идея TDMA не нравится...

Screenshot_1.jpg

(47.18 КБ) 200 скачиваний

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

[NiTr0]

[uquote="roman.com",url="/forum/viewtopic.php?p=3993853#p3993853"]как ? передача звука через NRF ? Можно... Только звук займёт весь канал связи... Если без кодеков))[/uquote]
а кто сказал - без кодеков? тот же adpcm элементарно реализуется даже на раритетах типа 8051 и атмелов, про более свежие камни - молчу, те вполне и какой-нить GSM-FR пережуют...

[uquote="roman.com",url="/forum/viewtopic.php?p=3993853#p3993853"]1 - мастер должен непрерывно передавать синхропакеты... тррррр))[/uquote]
а в чем проблема-то?

[uquote="roman.com",url="/forum/viewtopic.php?p=3993853#p3993853"]2 - слейвы должны постоянно просыпаться и слушать мастера...[/uquote]
зачем - постоянно? раз в минуту например. когда данные с датчиков актуализируют. и даже мастер может командовать слейву, когда примерно ему просыпаться.

[uquote="roman.com",url="/forum/viewtopic.php?p=3993853#p3993853"]3 - большая задержка передачи данных...
[/uquote]
зависит от длины таймслота. несколько десятков (сотен) милисекунд - немного.

[roman.com]

До самодельный кодеков я ещё не дошёл)) Передаю обычный PCM в RAW формате.

Не нравится мне когда мастер строчит пустые пакеты в эфир как из пулемёта))

Повторяю... всё зависит от трафика.
Если будет видеокамера которая будет занимать весь канал связи то общая синхронизация нужна. Иначе слейвы не смогут связаться с мастером.
А если трафик маленький (один пакет в минуты) то нафиг эта синхронизация вообще нужна))

У меня на первом месте задержки.
Мне надо чтоб нажал на кнопочку - и тут же включилась лампочка. Задержка пару миллисекунд допустима. ))
Или сработал датчик - мастер узнал об этом через пару миллисекунд.
При таких условиях общая синхронизация только мешает.

[NiTr0]

[uquote="roman.com",url="/forum/viewtopic.php?p=3994607#p3994607"]До самодельный кодеков я ещё не дошёл)) Передаю обычный PCM в RAW формате.[/uquote]
дык есть готовые библиотеки. ну а ADPCM - он и на коленке пилится по спецификации, никаких высших материй там нет. 8051 хватает чтобы с I2C флэшки играть ADPCM на 16КГц что ли...

[uquote="roman.com",url="/forum/viewtopic.php?p=3994607#p3994607"]Не нравится мне когда мастер строчит пустые пакеты в эфир как из пулемёта))[/uquote]
а в чем проблема? вайфайка так и делает например (те самые beacon-ы точки доступа). и никто не умер.

[uquote="roman.com",url="/forum/viewtopic.php?p=3994607#p3994607"]Если будет видеокамера которая будет занимать весь канал связи то общая синхронизация нужна. Иначе слейвы не смогут связаться с мастером.
А если трафик маленький (один пакет в минуты) то нафиг эта синхронизация вообще нужна))[/uquote]
ну я пока что не вполне представляю что там будет жить. точно будет кучка датчиков (типа метеостанции, комнатных и не только комнатных термометров, датчика уровня воды в колодце и т.п.), скорее всего кнопка звонка, а вот что еще захочется потом - пока не знаю.

[uquote="roman.com",url="/forum/viewtopic.php?p=3994607#p3994607"]У меня на первом месте задержки.
Мне надо чтоб нажал на кнопочку - и тут же включилась лампочка. Задержка пару миллисекунд допустима. ))
Или сработал датчик - мастер узнал об этом через пару миллисекунд.
При таких условиях общая синхронизация только мешает.
[/uquote]
100мс для реакции на кнопку предостаточно.

[roman.com]

Да, для Wi-F Интервал маяка: 40-1000мс.
И это не правильно)) Надо чтоб слейвы инициировали соединение и передачу.
Где-то такое видел...


А шифрование будет ? ))

[ARV]

Надо чтоб слейвы инициировали соединение и передачу

вы даже не видите противоречия в том, что пишите: слейв потому и называется так, что сам ничего не может инициировать! в сети с топологией "мастер-слейв" слейвы - полностью пассивные узлы. то, о чем вы постоянно говорите, не является такой сетью по определению! не знаю, как оно правильно, но это одноранговая сеть, все узлы которой равноценны по возможностям начинать передачу.