не получается запустить cc1100 в режиме непрерывного приема Опции

[_3m]

постил на телесистемвх, но там народ озабочен другими проблемами, да и докторы туамосят.
повторяю здесь:
====
пытаюсь сделать следующее: посылается запрос, затем cc1100 переходит в режим непрерывного приема и принимает N пакетов от удаленных устройств, которые передают пакеты в своих тайм-слотах. Непрерывный прием не получается запустить.
конфигурирую чип так: RXOFF_MODE=Stay in RX, FEC=ON, Data Whitening=ON, Fixed Packet size, Address check =ON (no braodcast), Autoflush=ON, GDO0 в режиме 0x06. Таймаут приема не используется (делаю процессором).
При посылке нескольких пакетов вывод GDO0 индицирует поступление всех пакетов, однако процессор принимает только первый пакет, последующие пакеты почему-то не принимаются, из регистра RXBYTES для всех пакетов кроме первого считывается ноль. Пакеты передаются без коллизий и с достаточными для приема данных паузами.
Работает только если после каждого пакета перезапускать прием (IDLE->RX).
Пытался отключать Autoflush, Address check, Data Whitening, FEC - поведение чипа при непрерывной работе на прием не изменяется.
====

[Alex B._]

конфигурирую чип так: RXOFF_MODE=Stay in RX, FEC=ON, Data Whitening=ON, Fixed Packet size, Address check =ON (no braodcast), Autoflush=ON, GDO0 в режиме 0x06. Таймаут приема не используется (делаю процессором).
При посылке нескольких пакетов вывод GDO0 индицирует поступление всех пакетов, однако процессор принимает только первый пакет, последующие пакеты почему-то не принимаются, из регистра RXBYTES для всех пакетов кроме первого считывается ноль. Пакеты передаются без коллизий и с достаточными для приема данных паузами.
====

Судя по тому что написано, все должно работать. Как вариант - неправильный адрес или длина пакета (из-за этого не совпадает контрольная сумма). Может быть не до конца вычитываете из FIFO приемника, но это должно быть видно из RXBYTES. В общем как-то загадочно.
Кстати, контролируйте длину импульсов на GD0 - она должна соответствовать длине пакета начиная с поля адреса. Если импульс короткий - модем не принимает пакет (не совпадает адрес). Если длинный - то адрес в порядке, но может не совпасть CRC (если длину пакета не правильно установили).
На всякий случай - если включаете контроль адреса, то модем приемник принятый адрес кладет в FIFO. Это явно нигде не указано.
Кстати, кодирование с коррекцией ошибок (FEC) и убирание постоянной составляющей (Whitening) вместе можно не использовать. FEC сам по себе убирает длинные постоянные последовательности, потому что еще и перемежение используется.
Как совет на будущее - обязательно корректируйте частоту синтезатора, как написано в одном из AN

[_3m]

Судя по тому что написано, все должно работать. Как вариант - неправильный адрес или длина пакета (из-за этого не совпадает контрольная сумма). Может быть не до конца вычитываете из FIFO приемника, но это должно быть видно из RXBYTES. В общем как-то загадочно.

Адрес точно правильный - пробовал отключать проверку адреса, не помогло; кроме того если отвечает только одно устройство (любое) то пакет принимается нормально. Нет приема второго и последующих пакетов.

Кстати, контролируйте длину импульсов на GD0 - она должна соответствовать длине пакета начиная с поля адреса. Если импульс короткий - модем не принимает пакет (не совпадает адрес). Если длинный - то адрес в порядке, но может не совпасть CRC (если длину пакета не правильно установили).

Длина импульсов на выводе GDO0 идентична для первого пакета, который принимается и последующих, которые не принимаются, она совпадает с длиной и временным положением импульсов передатчика. Выглядит все идеально, но не работает.

На всякий случай - если включаете контроль адреса, то модем приемник принятый адрес кладет в FIFO. Это явно нигде не указано.

Указано в даташите, я это учитываю.

...
Как совет на будущее - обязательно корректируйте частоту синтезатора, как написано в одном из AN

Сейчас я это не учитываю но у меня точные кварцы, при отладке проконтролировал значение frequest. AN читал, но не до конца понял как это применить в боевых условиях при работе с множеством подчиненных устройств.



***

А после окончания сеанса приема что в регистре состояния ? Трансивер точно оставался в режиме приема, без всяких там FIFO overflow ?

после приема пакета:
status_byte = 0x1f
pktstatus = 0x26
когда есть сигнал приема пакета GDO0, но RXBYTES=0 значения те же.

Помню, что-то я путался с этим, и вроде пришлось поставить flush FIFO перед приемом.

Ставил. Эффект нулевой. Работает только если делать принудительный перезапуск RX после приема каждого пакета. Любые другие изменения не влияют вообще никак

А длина пакета какая ?

Полезные анные 16 байт включая байт адреса, преамбула 6 байт, синхрослово 30/32бита.
Datarate=55.938721kBaud, Deviation=22.216797KHz, Modulation=2-FSK, RX filterbandwith=101.562500KHz, RF frequency=433.919830MHz, Channel=199.951172, используются каналы 0/1.

[rx3apf]

после приема пакета:
status_byte = 0x1f
pktstatus = 0x26
когда есть сигнал приема пакета GDO0, но RXBYTES=0 значения те же.
Ставил. Эффект нулевой. Работает только если делать принудительный перезапуск RX после приема каждого пакета. Любые другие изменения не влияют вообще никак

Странно, вроде все причины уже перебраны. Да, по каким-то причинам я у себя отказался от autoflush при приеме ответов, контролирую валидность по байту состояния и отбрасываю битые. Но это уже тоже проверено...