постил на телесистемвх, но там народ озабочен другими проблемами, да и докторы туамосят.
повторяю здесь:
====
пытаюсь сделать следующее: посылается запрос, затем 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 - поведение чипа при непрерывной работе на прием не изменяется.
====

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

А после окончания сеанса приема что в регистре состояния ? Трансивер точно оставался в режиме приема, без всяких там FIFO overflow ? Помню, что-то я путался с этим, и вроде пришлось поставить flush FIFO перед приемом. Но тут-то первый пакет приходит... Еще можно посмотреть скопом контроль приема синхронизации, выставив соответствующий режим GDOx. А так - принцип однозначно работоспособный - я так делал. Только не было address check, и пакеты маленькие (4-байтовые пакеты, 256 тайм-слотов, 250 kbps+FEC, 32/32768 sec на слот). Вполне жизнеспособно, заказчик писал кипятком
А, посмотрел, режим 06 - это как раз то, что я предложил, так что мысль в одном направлении движется. А длина пакета какая ?

Сообщение отредактировал rx3apf - Aug 1 2008, 21:23

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


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


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



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



***



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


Ставил. Эффект нулевой. Работает только если делать принудительный перезапуск 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.

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

Корректировать частоту у подчиненных устройств, у мастера не трогать. Разбега не будет.


Статус как получали - чтением или записю? Т.е. для RX или TX. В любом случае модем почему то у вас в IDLE переходит.

При таких скоростях (и, соответственно, полосе) и применении приличных кварцев (а с ширпотребом лучше не связываться, а то при очередной закупке купят левобезродные на третюю гармонику, и выгребай потом...) - коррекция вряд ли нужна. Все ж 433 MHz... Я делал калибровку по опорнику 32768 Hz, а потом посчитал, прикинул разбег для примененных 30 ppm SMDшных кварцев, и выкинул ее...

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

Там же у него в статусе 1x - т.е. остается в приеме. Это-то и странно. Вот если бы ноль был (как можно было бы предположить) - тогда да. Вот только тогда пришлось бы сильно почесать репу для объяснения того факта, что детектор синхрогруппы отрабатывает по каждому пакету
Но вот мой склероз усиленно подсказывает, что именно из-за каких-то проблем с непрерывным приемом мне пришлось отказаться от autoflush и влепить SFRX перед SRX. Давно дело было, но, кажется, именно так и и происходило - прилетал только первый ответ. Правда, синхронизацию я проконтролировать не успел, обошелся плясками с бубном (SFRX и игры с PKTCTRL1). Впрочем, autoflush и непрерывный прием как-то плохо сочетаются по-любому...

Сообщение отредактировал rx3apf - Aug 2 2008, 09:52

Не помешает это точно. Полосу может захотеться уменьшить чтоб увеличить чутье. Я с 1100 тоже давно занимался, сейчас с 2500 - там коррекция очень помогает.


неа. Если первый бит 1 (чтение), то в младшем полубайте статуса лежит количество байт в FIFO приемника. Заметьте - первый бит статуса зависит только от состояния чипа - если он работает, то этот бит всегда 1.


Конечно, это я стормозил. Принял 0x1F за 0x8F


хм... ну не знаю, все нормально работает. Autoflush - замечательная вещь для батарейных приложений - меньше действий - можно просто сразу заснуть, а не сбрасывать FIFO, если контрольная сумма не совпала. А уже тем более в CC1100 - там вообще по CRC_OK работал. В 2500 посложней - там этого нет. Точнее есть, но в режиме совместимости с CC2400, что мне не подходит.

Насколько я помню (а смотреть лениво), 1100 и 2500 отличаются только рабочим диапазоном частот, но никак не логикой обработки пакетов. Что же до autoflush - я имел в виду, что этот режим плохо стыкуется с непрерывным приемом пакетов. Что будет, если пришел битый пакет, а мы еще не закончили вычитывать предыдущий, не битый, из FIFO ?

Да, по младшему нибблу статуса - это уже я положился на свой склероз, пардон...

Сообщение отредактировал rx3apf - Aug 4 2008, 17:38

Как будет не лениво, посмотрите. CC2500 имеет режим совместимости с CC2400 - там контрольная сумма с другим полиномом. Причем вариант пина CRC_OK работает только в этом режиме, пришлось переделывать приложение.


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

Не удивлюсь, если окажется, что и у 1100 этот бит выполняет ту же роль, а вовсе не "reserved".


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

Сообщение отредактировал rx3apf - Aug 4 2008, 22:45