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

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

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

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

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

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

ага.
всё так.

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

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

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

Всё работает одинаково)) и ZigBee тоже))
А вот кому это нужно... х.з. ))

Это вообще ни о чём... Всё зависит от отношения времени - радио модуль активный/не активный.
Цифры в студию ! ))


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

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


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

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


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

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

примеры в студию, с дальностью близкой к nRF24L01


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




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

при этом:


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

Добавлено after 10 minutes 21 second:

само собой лошадиный. но речь о том, что логика "мастер командует, слейвы все время слушают и исполняют" даже с таким лошадиным током не реализуема. ultra low power - они либо десятки мА кушают, либо - сугубо приемники со смешными -50..-60dBm по входу...

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

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

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


Коллизии были только в старом изернет 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 или старом изернет. Тогда всё будет хорошо))

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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

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 лет работы))

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

а кто сказал - без кодеков? тот же adpcm элементарно реализуется даже на раритетах типа 8051 и атмелов, про более свежие камни - молчу, те вполне и какой-нить GSM-FR пережуют...


а в чем проблема-то?


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


зависит от длины таймслота. несколько десятков (сотен) милисекунд - немного.

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

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

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

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

дык есть готовые библиотеки. ну а ADPCM - он и на коленке пилится по спецификации, никаких высших материй там нет. 8051 хватает чтобы с I2C флэшки играть ADPCM на 16КГц что ли...


а в чем проблема? вайфайка так и делает например (те самые beacon-ы точки доступа). и никто не умер.


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


100мс для реакции на кнопку предостаточно.

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


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

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