Сеть радиодатчиков, collision и SimpiciTI Опции

[turnon]

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

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

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

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

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

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

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

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

[Aner]

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

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

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

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

[jcxz]

jcxz догадаться, додумать самому никак? От проблемы с кварцем никуда не дется. Если кварц у модема то это и доп потребление и доп время для его раскачки.

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

Если внешнее тактирование, то тоже процик кушает батарейку при запущенном кварце.

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

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

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

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

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