Разработал и изготовил 4 устройства на сс1101: устройства A1,A2,A3 посылают на устройство B пакеты, а устройство B квитирует их (передает своему Ax короткий пакет подтверждения). Все работает до тех пор, пока не наступит момент, когда два устрйства Ax пытаются передать свои пакеты одновременно (ну или почти одновременно, тактирование от внутреннего RC STM32F051). В этом случае устройство B "зависает", т. е. его сс1101 не может принять пакет от любого Ax. Помогает только сброс/переинициализация устройства В.
Сейчас усложнять протокол тайм-слотами нет времени, хотелось бы разобраться как можно выявить эту ситуацию коллизии в устройстве В с помощью регистров сс1101 и просто по этому событию перегрузить трансивер. Если такая возможность есть, подскажите в какую сторону смотреть?

В настройках СС1101 есть флажок, который позволяет очищать входной буфер в случае принятия битого пакета(несовпадения контрольно суммы). Но для этого пакеты должны быть фиксированной длины и включена проверка контрольной суммы. Посмотрите в этом направлении.

Какой у Вас формат пакетов? Фиксированная длина пакета? Один пакет помещается в приемный буфер?

Сообщение отредактировал Pasha_a13 - Feb 1 2014, 16:54

Все верно, софт сделал для пакетов от 4 до 64 байт. Устройство В проверяет адрес входящего пакета автоматически (регист ADDR в сс1101). Кроме того проверяется CRC входящего. Если эти две проверки ОК и пакет не более 64 байт, на GDO0 у меня встает 1 и контроллер считывает пакет.
Так вот, если например два Ax устройства одновременно передают пакеты, в RXFIFO скорее всего не пройдет проверка адреса и/или CRC. Но у меня установлены настройки автоочистки RXFIFO при битых пакетах и тогда прием пакетов восстановился бы, просто были бы пропущены несколько битых. А по факту прием в устройстве В встает навсегда! Что-то упускаю...

P.S. Причину нашел, но объяснить пока не могу: при одновременном/последовательном приеме нескольких пакетов устройство В вываливается в IDLE режим. Хотя после приема последнего пакета запрограммирован переход в RX режим.

Так это причина известная. И она не связана с одновременной работой с несколькими модулями.

Борюсь следующим образом - в один из моментов, когда трансивер точно должен быть в приеме вызываю следующую функцию


За сутки набегает до 10 ошибок, к зависанию не приводит.

Код бы приемника B показали. Как вариант борьбы с коллизиями добавить задержку статичную перед каждой отправкой по номеру устройства, например 1* 10мс., 2* 10 мс. и т.д. В каждом передатчике включите прерывание прослушивания несущей, как толька среда освободиться, выставится флаг, там и включайте передачу.

Я тоже об этом подумал - отслеживать состояние по регистру MARCSTATE. Единственное, не нравится постоянный поллинг к кристаллу - время реакции на другие события в программе критично. Кроме того в руководстве написано, что поллинг в режиме RX нежелателен, т. к. чувствительность приемника деградирует...
Хорошая мысль: устройства Ax должны использовать CCA перед началом "общения", если канал занят, это "общение" откладывается.

В приемнике B режим RX включен все время (главный цикл) и отслеживается состояние GDO0, по 1 на этом пине в RXFIFO имеем пакет с верным адресом и верным CRC. По уровню GDO0=1 трансивер автоматом переходит в IDLE. Далее пакет обрабатывается, переходим в режим TX, отправляем квитанцию для конкретного Ax и опять автоматом переходим в IDLE. Наконец, переходим в RX. Выходим в главный цикл программы с ожиданием нового состояния GDO0=1.

Посмотрите эррату, для 64 байт может быть похожий косяк с зависанием.

Написал функцию восстановления RX режима (все же решил использовать статус байт стробом SNOP) - теперь все работает прекрасно.

Просто раздирает любопытство, почему не связано с одновременной работой модулей? ИМХО, приемник может находится в режиме RX сколь угодно долго, если RX timeout не запрограммирован. У меня он вылетает в IDLE исключительно при коллизиях...
Теперь занялся реализацией CCA на устройствах Ax. Сейчас они просто начинают передачу по стробу STX и CCA отключен. Если его включить, то как я понимаю, нужно при желании начать передачу пакета сначала перейти в режим RX чтобы прослушать канал ("получить данные" CCA) и только потом начать передачу пакета. Вопрос: каково должно быть минимальное время нахождения в RX чтобы данные по CCA были валидны?

Элементарно, Ватсон, у меня работает один модуль и проблема имеет место быть.

Нигде о подобном не слышал, самому дико любопытно, хотя с зависаниями сталкивался, но так и не выяснил их природу.
Да, надо включать RX, у меня был включен переход автоматом на RX. Слушает среду недолго, если там тихо, а так почти всегда, только если в упор никто не вещает без умолку, сразу в передачу. У меня полное время передачи занимало 10-20 мс., т.е. с прослушиванием, подготовкой в TX и передачей в эфир 20 байт на 10к. Несколько мс. должно быть достаточно.

Сидел час отладчиком на приемнике B - не обнаружил ни единого вылета в IDLE при единственном передающем Ax. Как только передают несколько Ax сразу хорошо видно как передаваемые пакеты все ближе и ближе во времени становятся друг к другу и, в определенный момент ловлю вылет в IDLE на устройстве B. Очень интересная ситуация, выяснить бы, откуда ноги растут...
Дело в том, что мои устройства Ax - приборы с батарейным питанием, которые раз в минуту передают данные устройству B. Ясно, что для экономии батарейки время передачи и вообще активности нужно стремить к нулю. Даже протокол я построил вокруг этого требования. Поэтому, из режима сна нужно было бы сразу начинать передачу. Но после подключения CCA ясно, что сначала нужно прослушать канал. Все же сколько времени слушать??? Думаю миллисекунды - это много, предположительно - не более 1ms... Запрограммировал GDO1=0x09 на индикацию CCA но это ничего не решает - при переходе SLEEP->IDLE->RX неясно, когда данные на ноге GDO1 будут валидны...

P.S. Вот, надумал: время нахождения в RX должно быть примерно: T = T1 + T2, где T1 - время перехода SLEEP->IDLE->RX, T2 - время приема примерно ДВУХ байт на текущей скорости. У мну скорость 1200 бод/сек., т. е. время T = 1ms вроде должно быть оптимально минимальным )))

1 мс. хватит. Можно проверить имперически: выставить порт в 1 на входе IDLE->RX и сбросить уже в прерывании CCA. Глянуть осциллом. Боитесь, что будет долго слушать эфир и жрать батарею? Заведите таймер на требуемое максимальное время прослушивания эфира, при входе в IDLE->RX запускайте его, в прерывании CCA останавливайте. Если CCA висит долго, то оказываемся в прерывании таймера, где выключаем таймер и переводим радио в IDLE и вообще усыпляем систему на таймаут...и так далее.
Похоже, что у Вас сбор с датчиков, тогда вообще нет смысла собирать данные примерно в одно время, разграничьте время пробуждения Ax случайными задержками.


В том-то и дело, что это элементарно, когда работает 1 модуль. Видать что-то неправильно настроено.

Именно так! Сбор с датчиков. Причем если приемник B не примет очередной пакет - ничего страшного по ТЗ не произойдет.
Тогда встает вопрос, что меньше сожрет батарею при пробуждении датчика с необходимостью передать данные:
1. Слушаем канал, режим RX, 1ms. Если занят - не передаем пакет, иначе - передаем.
2. Да нафик этот CCA, просто сразу передаем - и все. Нужно все же делать тайм-слоты...
Сдается мне, что вариант 2 здесь более бережет батарейку...

Пробуждение по часовому таймеру? И каким образом разные датчики будут передавать одновременно, если их не синхронизировать? Т. е. если их не синхронизировать и использовать корявый источник тактирования часов, то вероятность одновременной передачи невелика. А если и будет коллизия, то и черт с ней, передадут через минуту.

Пользователь может вводить датчик в эксплуатацию (вставлять батарейку) в произвольный момент времени. Но в целом вы правы, по ТЗ возможно иногда терять пакеты, т. к. регистрируемые процессы вялотекущие. Так что редкие коллизии не страшны...