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

Собираюсь использовать CC1101 и протокол SimpliciTI, у него есть даже ретрансляторы, но они не нужны.

Но возникает одна проблема. Как избежать одновременной работы нескольких слейвов. Ведь при одновременной работе вместо пакета от одного слейва мастер получит кашу/мешанину и скорее всего не примет пакет вообще или отбросит его из-за несоответствия CRC.

И как я понял, в SimpliciTI эта проблема (коллизии) никак не решается.

Пока видится несколько вариантов решения, но ни один из них не вдохновляет.

1. В том же СС1101 есть технология под названием Clear Channel Assessment (CCA). Т.е. слейв перед отправкой может проверить, не занят ли канал другим слейвом. Но в этом случае при большом количестве слейвов некоторые могут очень долго ожидать свободного канала. К тому же во время ожидания будет использоваться батарейка. А слейв должен работать минимально возможное время, в отстальное время - сон.

2. Разделение по времени отправки пакета каждым слейвом. Непонятно как синхронизировать время. Даже если на каждом слейве есть RTC и время одинаковое, непонятно в какой момент слейв должен выполнять отправку.

Если у кого есть опыт реализации подобного, буду очень благодарен если поделитесь опытом/протоколом.

Рандомизируйте момент отправки пакета. Привязав к RTC или даже не привязывая. Другой вариант - с опросом. Мастер передает непрерывную посылку, в которой передается время до окончания посылки (отдельные пакеты с постоянно уменьшающимся счетчиком). Досчитал до нуля - мастер перешел на прием. Абонентам достаточно на короткое время прослушивать эфир, чтобы обнаружить несущую и один пакет этой посылки, после этого известно начало времени приема. А дальше - опять же или рандомизируя, или зафиксировав за каждым абонентом тайм-слот.

Это всё есть уже в SimpliciTi. задается #define ...
И слушать перед отправкой и случайный интервал для повторов

По прошествии некоторого времени датчики выстроятся во времени и коллизий не будет

Раз мастер имеет неограниченное питание, пусть управляет всем обменом - распределяет тайм-слоты в эфире. Выбираете некоторый период опроса, разбиваете его на тайм-слоты количеством равным максимальному кол-ву слэйвов. В начале каждого слота мастер пусть передаёт короткую посылку, содержащую номер слота и его длительность и общее кол-во слотов и после этого переходит на приём до конца слота. Каждый слэйв имеет свой уникальный номер. Когда у него есть данные на передачу, он слушает эфир, ловит ближайшую метку - начало слота, определяет по ней сколько осталось времени до слота с номером, равным его уникальному номеру и засыпает на время чуть меньшее, чтобы проснуться перед началом своего слота.
Для такого алгоритма не нужен никакой беспроводной протокол, достаточно простого приёмо-передатчика типа nRF24L01.

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

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

Похожая тема здесь

Ну или просыпаться через каждые N отправок для синхронизации меток (времени).

Здравствуйте.
Аналогичная задача – мастер с неограниченным питанием и слэйвы на аккумуляторах, всё на CC1101. Интуитивно пришёл к такому же алгоритму, какой предложили вы.
Но в чём необходимость обмена по тайм-слотам?
Возможен ли такой вариант (какие подводные камни):
1 Все слэйвы спят.
2 Включается мастер и рассылает широковещательный запрос.
3. Все слэйвы просыпаются по радио-запросу. Насколько я понял из доков на СС1101, у него есть соответствующий режим WOR (Wake-On-Radio).

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

5. Ну и на этом как бы всё, все спят дальше.


P.S. Может кто в курсе, при приёме пакета на CC1101, я получаю адрес того кто его отправил (на уровне драйвера)? В исходниках не нахожу соответствующего регистра.

Мне кажется что с 2.4GHz дальность больше 100 м - это иллюзия. По моим скудным знаниям вариант CC11XX + CC1190 более жизнеспособен. Или SX127x / RF9x с LORA (сейчас прямо звезда радиодизайна). Есть небольшая проблема с центральным узлом (SX1301 пока что то не идут в народ).
Для СС11xx есть SimpliciTI, для SX127x - LORA-MAC/LORAWAN или совсем простенький RadioHead.

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

1. Думаю так и есть. Но именно чтобы "что-то принял", а чтобы просто проснулся похоже достаточно запроса из эфира. А принять можно и при следующем запросе, через интервал, необходимый для полного пробуждения. Вот дока от TI по этой фитче CC1101 http://www.ti.com/lit/an/swra126b/swra126b.pdf. Планирую так будить RF, а он уже через GPIO Разбудит МК.

2. В моём случае не критично, т.к. к этим слэйвам мастер будет приезжать очень редко, раз в неск. недель. Фактически это летаргический сон.

Как определить "запрос" это или просто помеха прилетела из эфира? Без включённого приёмника, имхо - никак. А если рядом у Вас что-то работает в том-же диапазоне? Вафля например. Всё время просыпаться от неё будете.

Надеюсь, просыпается по осмысленным сигналам в эфире, например по преамбуле пакета, нужно вчитаться в доку.
Но предложенный вами вариант с тайм-слотами , если я правильно понял вообще, подразумевает постоянную прослушку эфира или периодическое пробуждение по таймеру на МК?! Лучше уж случайно/иногда от помехи, чем постоянно или периодически.

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

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


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

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

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

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

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

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

Это на каком таком чипе у приёмника потребление менее 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 в устройстве не будет.

Как во многом, - "палка о двух концах". Когда не понимаете и гонитесь за малым временем приема то забываете кучку других проблем. 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 месяцев. Маловато будет.

Ерунду говорите - если питание постоянное и не надо засыпать/просыпаться - пофиг на время раскачки кварца.
Вы когда за своим компом сидите, не задумываетесь какое у него время раскачки кварца?? А почему не задумываетесь?


Ещё раз большими буквами: У МАСТЕРА НЕОГРАНИЧЕННОЕ ПИТАНИЕ, т.е. - не батарейное (ну или батарейка ОЧЕНЬ большая).
Если разговор о слэйве, то для отмеривания периода сна/бодроствования, естественно следует не основной ВЧ-кварц использовать, а часовой на отдельном генераторе или входе RTC. Потребляет он крохи и выключать его естественно не надо. В моей погодной станции я именно так и сделал.


Прикинул. Любой даже самый дохлый 8-битный с программным SPI. Если нет речи об обработке потока про которую Вы всё время упорно талдычите.
Для передачи кадра на скорости 2 Мб/сек в nRF24L01+ надо в него вначале запихнуть ему в буфер этот кадр (можно даже три кадра сразу запихнуть) с SCLK SPI от нуля Гц и выше, потом поднять ножку TX на некоторое время. Всё.
Не вижу причин почему с этим не справится самый дохлый 8-битник.


Сделайте 10/10000 - проект Ваш и алгоритм сбора Ваш.

10 секунд на поиск доступных датчиков? Ну.. может быть. В принципе процедура разовая и запускается вручную. Сделаю наверное 5, но откажусь от WOR пусть рулит МК, в 10мс всё равно уложиться должен. Только нюанс: получается один запрос на все слэйвы, придётся фильтрацию по адресам отключать.

К вопросу «использовать режим WOR или запускать режим прослушки эфира микроконтроллером?».

STM32 можно затактировать от 1МГц XTAL и работать с него на время окна RX (всего лишь +1 mA потребления МК к стандартным 15 mA потребления RF-чипа в режиме RX) … а дальше, если что-то приняли разогнаться через PLL до 72МГЦ для дальнейшей обработки.

Чем не вариант экономии?!