Конечно периодическое пробуждение. Прочитайте мой пост внимательнее. В моём случае приёмник почти всё время полностью выключен. Если связь у Вас возникает редко, то таймслоты можно сделать большими (несколько секунд, а то и минут; в зависимости от требуемого времени реакции на опрос), а время вкл. состояния приёмника - миллисекунды. В этом случае потребление включенного приёмника размазывается в тысячи и десятки тысяч раз.

Читал внимательно.


Я про то и говорю, что ваше периодическое пробуждение "Когда у него есть данные на передачу" да ещё и с прослушкой эфира, ничем не экономичнее моих "случайных пробуждений от помех", которых возможно на практике не будет

Приемник по-любому надо включить, чтобы понять, передается что-то или нет. Если и опрос эфира будет привязан к жестко заданным тайм-слотам, то это можно реализовать экономичнее, что просто периодический опрос (ну, от частоты опроса зависит, конечно - вот, к примеру, в бытовых метеостанциях приемник беспроводных датчиков один раз в минуту после "прописки" датчика). Наличии помехи (несущей) ухудшает картину - если несущей нет, то приемник может это сразу определить, и перейти RX->IDLE, а иначе надо дождаться по крайней мере появления синхронизации и (опционально) преамбулы. На потреблении это сказывается весьма существенно.

Сообщение отредактировал rx3apf - Jan 5 2016, 09:41

А как можно привязать сканирование эфира к тайм-слотам? Шкала реального времени у мастера и слэйвов?

Сообщение отредактировал Yogen - Jan 5 2016, 10:01

Как вариант - да. У себя я использовал ежесекундный опрос для активации обмена, в случае активации оставлял приемник в режиме непрерывного приема для сеанса связи с отключением по таймауту (ну и по команде завершения сеанса, разумеется). При скорости 125 kbps среднее потребление радиоканала при отсутствии посторонних несущих было менее 15 uA.

Режим Wake-on-Radio в CC1101 совсем не то, что я думал. Обычный переход в режим приёма по программируемому таймеру на программируемое время, при отсутствии несущей назад в сон.

Получается, если я буду просыпаться каждую секунду на время большее, чем периодичность запросов мастера, их я могу сделать хоть каждые 10 ms, то я гарантированно приму запрос. И среднее потребление будет равно длительности нахождения в RX/1 сек. Время настройки на мастера будет от 0 до 1с?

Сообщение отредактировал Yogen - Jan 5 2016, 10:26

Это на каком таком чипе у приёмника потребление менее 15 uA и какой бэнд? Средне за сколько таймслотов? 1:1000, ...
И у какого приемника непрерывное потребление меньше 6-8mA? ... с той вашей широкой полосой еще и чувство укажите, может он Rx совсем тупенький?


10 ms получить трудно, если из сна или из выключенного состояния, кварцу нужно примерно столько времени или поболее на разгон или выбег на стабильную частоту генерации.

Ничем????
Я не знаю каково потребление в Вашем чипе, но например в одном из самых экономичных (имхо) - nRF24L01+ приёмник потребляет около 10мА, а в выключенном состоянии - менее 1мкА.
Если для Вас разница в 10000 раз - это ничто, то и разговаривать дальше бессмысленно.
И хоть мне и лень читать даташит на Ваш МК, но я сильно сомневаюсь, что потребление его приёмника будет существенно меньше. И что он сможет определить хоть что-то происходящее в эфире, не включая приёмник.

А то что Вы выделили, если разжевать, означает что:
в начальное время инициализации, когда слэйв только включился и ещё не принял ни одной метки таймслота от мастера, он находится в непрерывном приёме (либо в непрерывно-периодическом режиме -
например: каждые 20 секунд включается на время немного большее длительности одного таймслота и непрерывно слушает эфир ищя хотя-бы один таймслот от мастера). Получив хотя-бы одну метку таймслота от мастера, он уже:
во-первых - знает время мастера и имея RTC-может просыпаться синхронно с его метками;
во-вторых - может определить расположение своего таймслота и просыпаться не на каждый таймслот, а только непосредственно пеерд своим таймслотом.
Таким образом, получив метку от мастера, слэйв будет включаться только тогда, когда действительно необходимо.
Если длительное время от мастера не получена ни одна метка таймслота, то слэйв также должен переходить в режим непрерывного приёма (см. выше - это не означает что приёмник должен быть постоянно включен),
ну или назовём это - "режим поиска мастера". А время работы приёмника в этом случае и периоды его просыпания тоже определяете Вы, и можете период сделать большим, да и время прослушивания эфира уменьшить.
И тоже получить небольшое потребление.


Я для себя, в качестве хобби, делал домашнюю погодную станцию на MSP430 + nRF24L01+. Она периодически просыпается, делается замер и ложится спать.
Кроме того, у неё есть связные просыпания - каждые 20сек она просыпается, включает приёмник и 4.5мсек ждёт команды "Старт сеанса" от центра сбора.
Если команда получена - начинается обмен и тогда времена таймаутов ожидания увеличиваются до 13мсек, но сеансы бывают редко.
Так что среднее потребление примерно == 4.5/20000*11 мА (приёмник nRF24L01+ в непрерывном режиме потребляет вроде 11мА насколько помню).
Полоса там - или 1 или 2 мБита/сек.
Конечно тратится время на включение/выключение приёмника и есть потребление в "power down" (0.1мкА), но в сумме у меня, по измерениям, среднее потребление nRF24L01+ получалось немного больше 7 мкА.


10 мсек период просыпания для задачи ТС - это конечно глупо, но не невозможно.
Например у nRF24L01+ время просыпания из "power down" == 1.5мсек.

Рисунок из описания режима Wake-on-Radio CC1101. Чип за за 14.4 мс успевает проснуться, послушать эфир и снова уснуть на 11мс.



Почему глупо? Ведь чем меньше тем лучше? Если я правильно понял за время нахождения слейвов в RX мастер должен успеть передать как минимум один запрос, поэтому их нужно посылать как можно чаще, у мастера питание неограничено. А вот слэйв может слушать уже раз в секунду, всё равно поймает, ведь время прослушки будет больше периода запросов.

P.S. RTC в устройстве не будет.

Сообщение отредактировал Yogen - Jan 5 2016, 11:53

Как во многом, - "палка о двух концах". Когда не понимаете и гонитесь за малым временем приема то забываете кучку других проблем. 1- обработка такого быстрого потока как 1...2 Мбита это не простой выбор микроконтроллера, который кушает поболее, если нужно обработать скоростной поток, не каждый пик, атмел, да и арм успеет сделать обработку и не покушать хорошо батарейку. 2- широкая полоса приема дает низкую чувствительность, а мощность передатчика размазана по широкой полосе, это сокращает расстояние для уверенной работы, 3 - ловля бо'льшого количества помех при большей полосе, увеличение битых пакетов при приеме ... 4 - зеркальный канал приема, который и так не ахти какой, при широкой полосе доп проблема. В городе при наличие пром помех проблем много будет у таких устройств. Поэтому нужно искать середину используя эти простенькие модемы или пользовать HFSS.

Я сейчас глянул свои времянки - 1.7 ms от вывода из POWERDOWN до окончания приема синхропосылки.... Но я WOR не использую, все принудительно от часов MCU.

Мегабитов тут не будет. Чип максимум на 500кб/c. А для предполагаемого трафика хватит и 100кб/с за глаза. МК планирую STM32. Но вариант автономного датчика предполагает однократный съём данных раз в месяц или реже, либо однократный суточный запуск для записи данных на SD. Всё остальное время МК спит. Просыпаться каждый раз вместе с CC1100 вроде как не нужно, он сам пишет принятые данные в FIFO и если там корректный пакет пробуждает МК через GPIO.

Из сообщения Aner я понял, что под 10мсек понималась периодичность просыпания слэйвов.
Если же это период запросов мастера - вполне нормально. Тогда Aner написал бессмыслицу - зачем мастеру просыпаться, включать/выключать кварц если у него неограниченное питание??


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


Кто сказал про поток? У меня например радиочип (nRF24L01+) имеет скорость 1/2 Мбита/сек. Это не говорит о том, что я передаю непрерывный поток. Я передаю всего несколько десятков байт за сеанс связи на этой скорости.


Другой конец палки: меньшее время передачи пакета - меньшая вероятность попадания помехи в него

jcxz догадаться, додумать самому никак? От проблемы с кварцем никуда не дется. Если кварц у модема то это и доп потребление и доп время для его раскачки. Если внешнее тактирование, то тоже процик кушает батарейку при запущенном кварце.
Проблема мастера слейва не тут. Тут нужно понять, что пользуется асинхронный протокол с временным разделением, типа временных окон (т.н. тайм слотов). И все становится понятно. Проблема синхронизации решается не просто при наличии различных помех.


потоки разные, про непрерывный поток, то о чем вы пишите я не говорил. Вот возмите и прикиньте какой контроллер успеет обработать те 1 ... 2 Мбита/сек. И какую ему нужно иметь скорость на SPI и какую тактовую для десятков байт, ... хотя лукавите, поболее будет та же преамбула и сихра, црц добавятся + обработка ...

А про вероятность начнёте говорить ... , то и от ЭМ обстановки зависит в вашем случае. Если помеха узкополоснее, большей мощности чем ваш Tx, то сбой вам обеспечен. Поскольку время помехи больше чем ваше время пакета. Тракт приема будет забит. Это уж проверял ранее при тестировании своих систем. А если ваш участок забит кучкой других устройств в этом диапазоне, что тогда делать будете с вашей широкой полосой и малой вероятностью?

Даже при таком тайминге 10/1000 ms и потреблении RF 15mA, от аккумулятора 1000 mah всего 9,5 месяцев. Маловато будет.

Сообщение отредактировал Yogen - Jan 5 2016, 14:28