Форум РадиоКот

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

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

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

ага.
всё так.

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

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

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

[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:

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

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

ARV писал(а):NRF сама по себе ничего отправить не может

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

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

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

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

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

[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 по входу...

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

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

NiTr0 писал(а):в том же эзернете вполне нормально обработка коллизий например реализована. сотня хостов, разнесенных на расстояние до 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 или старом изернет. Тогда всё будет хорошо))

Теперь считаем потребляемый ток 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

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

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

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

Итого: 4,5 мс

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

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

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

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

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

roman.com писал(а):в нормальном состоянии питание на МК и NRF отсутствует

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

ARV писал(а):ТС об этом ни слова не говорил.

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

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

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

ARV писал(а):есть третий участник процесса?

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

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

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

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

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

NiTr0 писал(а):можно что-то типа домофона даже прикручивать в ту же сеть

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

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

[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]
зависит от длины таймслота. несколько десятков (сотен) милисекунд - немного.

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

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

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

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

[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мс для реакции на кнопку предостаточно.

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


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

roman.com писал(а):Надо чтоб слейвы инициировали соединение и передачу

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