Тогда не заморачивайтесь, разве что добавить повторную отправку Ошибки в работе таймеров всегда будут набегать, так что коллизии маловероятны. А почему не зигби?

Тогда нужно в сторону STM32Wxxx смотреть - у меня очень хорошо бы легло по ТЗ. Но я не уверен, что смогу обеспечить в этом диапазоне необходимую дальность. Такого опыта в Инете не удалось найти...

Какая дальность требуется? В помещении?

Соседние помещения, стены железобетон, 50-80метров.

Кстати, я вроде понял, почему трансивер вываливается в IDLE при обсуждаемых выше условиях!
Ответ дан на стр. 40 даташита сс1101 (ревизия I) в разделе CRC filtering.
Дело в том, что если принят битый пакет (одновременно или почти одновременно прилетели валидные пакеты), то CRC failed, RXFIFO autoflushed, и состояние трансивера определяется в MCSM1.RXOFF_MODE. А он у меня предполагает IDLE.
Но все равно, это не избавляет от функции контроля нахождения в режиме RX, приведенной выше...

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

1. Мой самопальный протокол предполагает IDLE после приема пакета. Изменять конфигурацию на лету не хотелось бы.
2. Длительное нахождение в RX не рекомендуется.

Если кому не трудно, подскажите еще по режиму WOR в CC1101: при скорости 1.2 кБод как правильно выбрать период пробуждений трансивера, если передача пакета начинается с преамбулы 30 бит и затем sync word 32 бита? Я изучил вроде соот разделы в даташите, но до конца не разобрался сколько времени должен находится сс1101 в режиме приема внутри WOR режима? Вроде он должен определить наличие N sync bits в эфире и выставить уровень на GDOx? Чему равно N? 32 бита sync word будут приниматься из эфира ~27ms при скорости 1200бод и период должен быть меньше? И возможно ли как-то использовать обработку преамбулы с целью увеличения периода пробуждений?

Зависит от наличия или отсутствия FEC, и я использовал внешнее, принудительное, задание времени приема, не пользуясь внутренними средствами. Можно и "живьем" измерить это время, и ориентироваться (с запасом) на полученные результаты. У меня скорость на два порядка выше, поэтому времянки совсем иные, на малых скоростях не рискну что-то советовать (но напомню, кстати, о высоких требованиях к точности установки частоты на низких скоростях при малой полосе). Использование высокой скорости существенно сокращает потребление при опросе эфира.

Никаких ограничений на время нахождения в состоянии приема нет, насколько помню. Устройства со стационарным питанием у меня находятся в приеме непрерывно, никаких проблем не наблюдалось.

Переходить или не переходить в idle - вопрос удобства. Я, например, в разных частях протокола поступаю по-разному, и переконфигурирование "на лету" происходит постоянно.

И все же. Передатчик передает 4 байта преамбулы и 4 байта синхрослова на скорости 1200 бод/сек. Сколько бит преамбулы и/или синхрослова требуется приемнику сс1101, чтобы определить это как начало пакета??? Это требуется для режима WOR (расчета периода пробуждений).
Я думаю, требуется 8 бит синхрослова минимум...

В регистре MCSM2 же задается таймаут поиска преамбулы для выхода из sleep.

Ну и как будете задавать?

Даташит, стр. 80, там есть пример, где сказано, что приемник слушает эфир 1.96 мс. с заполнением для пробуждения в 0.195%. Это же поясняется на рис. 28.

Я ведь даже ситуацию обрисовал:

Вопросы, если нужно максимально поберечь батарейку для вышеприведенных условий:
1. Чему будет равен максимальный период пробуждений (EVENT0)?
2. Из каких соображений определите содержимое С(RX_TIME,WOR_RES) (стр. 80 даташита)?

При этом учтем, что на скорости 1200 бод/сек время трансляции бита в эфире примерно ~0.8ms !!!

Выше имеется ввиду, что пакет передается в эфире лишь однажды и именно с этой позиции рассматриваются вопросы настроек WOR принимающей стороны...

Если я правильно понял, то устройство B у Вас со стационарным питанием. Зачем в таком случае использовать WOR.
А от коллизии действительно удобно использовать псевдослучайную задержку перед передачей (прослушивание канала не дает особых преимуществ, если только два передающих устройства не находятся близко друг к другу...если же они находятся на разные стороны от приемника, то они могут друг друга и не услышать), время которой находиться в пределах, например, 0..0,5*(длительность пакета).
Плюс, в случае если устройство А не приняло пакета подтверждения, то через какой-то промежуток времени оно делает еще одну попытку передать пакет, затем его отбрасывает(количество переповторов подбирается исходя из важности информации).

Да, со стац питанием. С WOR я ранее не работал, думал это поможет в моей задаче. Казалось бы, мастером должно быть устройство B, но это больно бьет по энергопотреблению устройств А (датчиков) - они должны отправлять свой пакет 1 раз в минуту - я так и не придумал, как это обыграть, если мастер - устройство В. Получается, датчики должны входить в прием на довольно длительный период + еще потребуется синхронизация... Поэтому мастером (а точнее Инициатором) выступают датчики. Но все не просто. Устройство В тоже должно передавать на датчики их конфигурацию и др данные (изредка). Итак, сделал следующее: датчик инициирует обмен и передает свои данные. База (устройство В) квитирует этот пакет, передавая помимо квитанции специальный служебный байт (команда датчику о его дальнейшем поведении). Если в этом байте передается 0, значит дальнейшие действия датчика - standby mode. Т. е. получается, что большую часть времени датчик передает один лишь пакет своих данных (макс сохр потребления). В итоге имеем "мультимастерную" систему, где база - слэйв, но логически все же база - мастер ибо она руководит обменом по факту... Придумать что-то лучшее пока не смог, может подскажете что-то. Мне не очень нравится "мультимастерность", вот в чем беда. Я думал, что WOR как то поможет эту проблему разрешить...

Датчики и так должны передавать инфу раз в минуту, по условиям ТЗ допускается один пропуск данных, но не реже...