Такой вопрос к гуру. Имеется трансивер на Si4432. Точнее Si1000. Еще один такой же посылает пакеты с другого конца лаборатории. Читаю все прекрасно, RSSI говорит от 80 до 90, т.е. порядка -70 dBm. Замечтельно. Теперь я посылаю ответ на каждый пакет. Все по прежнему работает, но RSSI падает до 55-60, т.е. на 12 дБ.

Это что, передача так действует на АРУ? В антенне стоит переключатель согласно рекомендациям. Я боюсь что дальность связи сильно упадет, если это не глюк самого RSSI регистра.

Обратите внимание в вашей програме на: как долго измеряете и в какие моменты. Воможно вам нужно поиграться там с временами. В Si4432 глюков не наблюдал.

Пардон, не понял "как долго измеряете". Один раз читаю RSSI регистр как только приходит пакет. Я знаю что рекомендуют 3 раза прочесть и выкинуть один если он сильно другой, но мне случайная ошибка не страшна. Главный вопрос такой: действительно ли упадет чувствительность после передачи? Новый пакет приходит через сотни милисекунд.

После распознавания заголовка, читаем. 3-5 раз читаем, обрабатываем. Чувствительность после передачи не падает. Какая скорость у вас? Какая полоса?

Я не реагирую на заголовок - только на правильный пакет. 10 K bps, deviation 40K полоса 80К.
Надо будет ослабить сигнал и посмотреть когда пропадет связь с ответом и без.

А надо реагировать и привязывать по времени чтение регистра, тогда без проблем. Скорость низкая у вас тоже без проблем, у меня на высоких скоростях измерения не соответствовали из-за малого времени пакета.

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

Кварц 10 ппм и частота соответствует. Попробовал ослабить сигнал. Вроде пакеты принимаются хорошо. Отключил AGC (reg 0x69=0), RSSI поднялся до небес.
В общем будем считать что проблемы нет. Мне важно не RSSI измерить правильно, а не терять данные.

Чтобы не плодить тем, спрошу тут раз уже проблема затронута.

Есть пример от SiLabs: ExHop. Передается очень длинная ( 225 байт на 50К bps ) преамбула. Приемник быстро быстро сканирует частоты пока не получит прерывание о распознавании преамбылы. Ждет прерывания о паспознавании синхро слова. Только потом ждет самого пакета.

Все логично и прекрасно работает. Только пакет в 4 раза дольше чем надо. 300% overhead некузяво. В смысле не comme il faut. Для моей задачи надо долго ждать (секунды) первого пакета. Тут этот механизм очень хорошо работает. А потом надо быстро передать десятки или даже сотню пакетов на том же канале. Ясно что тут можно передавать пакеты с короткой преамбулой и сидеть на последней частоте.

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

Перед тем как переделать код дальше хочу спросить. А в чем смысл ждать синхры а не сразу valid packet received? Если я использую штатную обработку пакетов.

Такая струкрура пакетов EzHOPE ( далеко не лучшая) для 50 каналов, либо пользовать как есть, либо своё писать. Да и скорость у вас для 50 каналов низковата, отсюда и время большое. И что, реально нужно столько каналов?

Я решил проблему с RSSI так:
1. Разрешил прерывание по SyncWord.
2. В обработчике прерывания считываю Значение RSSI из SI4432_RECEIVED_SIGNAL_STRENGTH_INDICATOR

Обоснование такое. По преамбуле настраивается автомат приема по ПЧ и уровню. SyncWord замораживает настройки в том числе RSSI. После приема пакета можно считывать, но получал какие-то глюки. Скорее всего, глюки вызываются переключениями режимов работы трансивера. Я особо не разбирал проблему.

Тоже столкнулся с проблемой глюков при чтении RSSI. В одном проекте можно было при старте игнорировать несколько пакетов без ущерба. На приеме ввёл выборку и усреднение по 5...7 коротким пакетам, для RSSI. Получилось приемлемо. На RSSI влияет еще несколько внешних фактором. По одному значению судить не реально. На скоростях выше 200...240K c RSSI еще проблема возникает, недостаточно времени для измерения реального занчения RSSI.

Словарь Ожегова говорит:
ПОЛЬЗОВАТЬ, -зую, -зуешь; несов., кого-что (устар.). То же, что лечить. П. от простуды.

Вы имеете в виду "ИСпользовать".

Мне нужны все 50. Так говорит FCC.

> скорость у вас для 50 каналов низковата

EzHop предлагают 4 скорости: от 2.4 до 128 kbps. Я остановился на 50 как компромис между чувствительностью и скоростью.

Понял что RSSI лучше читать после синхры. А в остальном можно сразу ждать правильного пакета?

> далеко не лучшая

А как лучше? И чем именно плох мой метод сканировать каналы в ожидании первого пакета с длинной преамбулой а потом принимать "нормальные" пакеты на фиксированной частоте?

Aner: я ценю Ваши замечания, но к сожалению просто сказать "формат не лучший" или "4463 быстрее" не очень помогает. Хочется понять что именно следует менять и что имено это даст.

alexf пока не очень поинмаю вашу задачу в целом, поскольку не описываете. Посему и ответы где-то общие из моего опыта. Что менять?
Видимо должны оценивать сами.

Если у вас жёстко, требование по FCC то уйти от этого не просто. Если есть свобода действий, то можете подумать над своим протоколом обмена, под задачу.
Это несколько труднее, но может быть эффективно.

FCC жестко. Отсюда 915 и 50 каналов. А задача такая. Имеется сервер с радио и много клиентов в том же помещении, но может быть и за стенкой-двумя.
(Игра с многими участниками).

Сначала клиент посылает запрос и сервер посылает в ответ несколько килобайт. Тут нужна скорость и 225 байт преамбулы не годится. Я решаю так:
сервер посылает редкие пакеты с длинной преамбулой (beacon) прыгая по каналам. Клиент, который готов, отвечает на том же канале где был последний сигнал. Дальше сервер посылает все несколько кило подряд с короткими преамбулами. Если все влезло в 0.4 сек, можно канала не менять. Не влезет - перейдем на след. по таблице.

А дальше сервер посылает редкие (раз в секунду) пакеты всем клиентам. Тут должен хорошо работать формат EzHop - скорость совсем не нужна, а клиентам не надо по времени синхронизироваться с сменой каналов.

Скорость важна только при начальной загрузке, но требования не жесткие, а "чем быстрее тем лучше". Поэтому чтобы не жертвовать дальностью выбрал 50К, а больше и не надо. Как то так.