Сеть радиодатчиков, 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, то сбой вам обеспечен. Поскольку время помехи больше чем ваше время пакета. Тракт приема будет забит. Это уж проверял ранее при тестировании своих систем. А если ваш участок забит кучкой других устройств в этом диапазоне, что тогда делать будете с вашей широкой полосой и малой вероятностью?