Si4463 не взлетает

[Ser60]

Поздравляю. С Si4012 советую использовать 2FSK. Однозначного ответа для максимальной дальности нет. Однако чем меньше скорость передачи, тем выше чувствительность приемника. Девиацию также следует подбирать исходя изнтенсивности помех. В теории чем выше девиация, тем менее сказывается неточность настройки приемника и передатчика на частоту и при высокой скорости передачи её следует расширить. Однако, большая девиация требует более широкой полосы пропускания приемника, значит, более высокий уровень шума и меньшая чувствительность. Короче, лучше подбирать экспериментально.

[MaxNox]

Есть тут кто работал с NiceRF RF4463F30 ?

[Ser60]

Похоже модуль просто на основе Si4463. В чём проблема-то? Статью читали?

[MaxNox]

Похоже модуль просто на основе Si4463. В чём проблема-то? Статью читали?

С запуском просто модулей на основе Si4463 у меня проблем нет. В частности того же 4463PRO от Nicerf. А вот с модулем RF4463F30 следующая проблема-подключаешь его в ту же схему в которой работал 4463PRO вроде бы все должно работать также. Однако модуль RF4463F30 стартует или не стартует случайным образом. Даже если сделать так как в даташите схема- то есть подать 5 вольт на радиомодуль и 3.3 вольта на процессор. Понять от чего зависит старт или не старт модуля ,выявить систему невозможно пока. Проблема повторяется на других экземлярах модуля из разных партий. Разбор с анализом сигналов сигналов приводит к тому что старт не происходит потому что процесс зависает на CTS проверке. Почему то она проходит, то модуль виснет на ней.

[Ser60]

Нет, таких нюансов про этот модуль не знаю - ниогда с ним не работал. Я вскрыл бы один чтобы посмотреть что там под крышкой и какой обвес вокруг основного чипа. Может это натолкнёт на идею.

[MaxNox]

Ser60 писал(а):

Нет, таких нюансов про этот модуль не знаю - ниогда с ним не работал. Я вскрыл бы один чтобы посмотреть что там под крышкой и какой обвес вокруг основного чипа. Может это натолкнёт на идею.

Как вариант вскрыть, это да. Но я примерно знаю что там. Там чип si4463, преобразователь питания в 3.3 вольта, антенный свич, усилитель, ну и обвязка из пассивных элементов.

[Ser60]

Вы SDN вывод задействуете? Для нормальной работы он должен быть притянут к земле. Если это так, то можно грешить на монтаж внутри модуля или сам чип. Кстати, если в процессе отладки засылать в модуль неправильную команду, от которой он "зависнет", то при перезагрузке программы в МК, радио-модуль может не сбрасываться. Следует сделать сброс схемы по питанию перед новым тестом.

[MaxNox]

Ser60 писал(а):

Вы SDN вывод задействуете? Для нормальной работы он должен быть притянут к земле. Если это так, то можно грешить на монтаж внутри модуля или сам чип. Кстати, если в процессе отладки засылать в модуль неправильную команду, от которой он "зависнет", то при перезагрузке программы в МК, радио-модуль может не сбрасываться. Следует сделать сброс схемы по питанию перед новым тестом.

SDN сразу набросил на землю.

[MaxNox]

А пробовал ли ктот-то менять настройки трансивера не выключая его? Так сказать"на лету"?

[Ser60]

Что значит "не выключая"? Если во время передачи или приёма пакета, то передастся или примется незнамо что. А так, каждая настройка - это определённая команда, и её можно подать в любой момент.

[MaxNox]

Что значит "не выключая"?

Предположим мы хотим сменить девиацию или другую настройку. Например мы находимся в режиме приема сигнала и хотим быстро сменить настройки девиации. Обычный подход, который я наблюдал во многих примерах, это перейти из режима приема, подав spi команду CHANGE_STATE sleep. То есть выключив режим приема. Потом подаем необходимые spi комманды для изменения настроек. Затем подаем команду RX_START чтобы перейти в режим приема. Так вот, что будет если не выключать режим приема, а прямо находясь в нем начать менять настройки? Будет ли трансивер отрабатывать каждую смену настройки или не примет настройки вообще,без переключения из режимов TX и RX в "нейтральный " режим типа sleep.

[Ser60]

Менять девиацию на лету не пробовал. Попробуйте сами и нам расскажите - эксперимент на 5 минут. Однако, для смены частоты приёма/передачи можно использовать команды RX_HOP/TX_HOP.

[Feruz]

Если коротко: нет передачи в эфире.

Если подробно, то ситуация следующая. Запускаю si4463 rev B1 на передачу таким способом:
1 Подаю питание на схему
2 Даю длинный SDN=1 (200 мс)
3 Жду CTS=1
4 Шлю power up с указанием частоты кварца 26 МГц
5 Жду CTS=1
6 Отправляю набор конфигурационных property, сгенерированных WDS.
6.1 Перед каждой property ожидаю CTS=1 (как впрочем и перед любой командой, поэтому далее эту запись опускаю)
7 Очищаю FIFO TX/RX
8 Читаю ответ
9 Заполняю TX FIFO
10 Даю команду на передачу
11 Непрерывно запрашиваю REQUEST_DEVICE_STATE пока CURR_STATE=TX, вижу что это состояние сохраняется ровно столько, сколько нужно на передачу заданного числа бит (включая преамбулу и синхрослово) при заданной скорости
12 Повторяю цикл передачи с пункта 7 примерно раз в секунду
13 В эфире тишина...

Замечания:
-настраиваю вывод тактовой частоты на GPIO0 и там тишина, когда же настраиваю на другие функции типа CTS или InvCTS то вижу что они появляются на этом пине корректно
-сишка охотно отвечает на запрос PART_INFO, отвечая что она 4463 с РОМ айди 3
-смотрел осциллографом сигнал на ножках кварца - есть чистенькие 26 МГц

Оборудование:
BluePill STM32F103C8
Китайский SALEAE LOGIC
Китайский RTL-SDR
Китайский модуль SI4463 от CDSENET (красная плата, две гребенки 2.54, без rx/tx свитча, торцевой SMA мама)

В прикреплении:
Исходник прошивки для Keil uVision 5.24.2.0
Дамп логического анализатора для Saleae Logic 1.2.18 (от подачи питания до нескольких пакетов на передачу)
Проект и сгенерированный h файл для WDS 3.2.11.0
Моя грусть от непонимания в чем дело

Вложения

4463_no_tx.rar

(258.88 KiB) Скачиваний: 211

[Feruz]

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

[Feruz]

Взываю Ser60

[Ser60]

Посмотрю код сегодня в течении дня, ответ получите завтра к утру по Москве.
....
Посмотрел код и осциллограммы - всё логично. Единственное, что мне не нравится на осциллограммах - это подъём CS до завершения последнего цикла SCLK. Я-бы добавил строку
while (SPI1->SR & SPI_SR_BSY){}
в конец Вашей spi_trx() функции и добился чтобы подъём CS происходил после возврата SCLK в 0 (idle state). Так будет по правилам, и неизвестно как разные слейвы реагируют если это условие не выполнено.
Загрузил Ваш код в свой модуль. К сожалению у меня нет модулей на 433 мгц, я использую только 900 мгц диапазон, и модули на монтажке есть только SI4461, у которых вывод SDN запаян на землю. Поэтому загрузил в модуль свой конфиг и наблюдаю передачу пакетов. Кроме того, я не использую STM32 и Ваш код проверил под MKL03Z32UFG4 (ARM-CM0+) со своей реализацией SPI интерфейса. На всякий случай привожу ниже свой конфиг на 903 мгц.
Что мне совсем не нравится - это отсутствие тактовой частоты на выводе GPIO0. Должна быть в Вашей конфигурации.

Спойлер

Код:

const uint8_t SI4061_Config[] = {                         // config data size
   0x07, 0x02, 0x01, 0x00, 0x01, 0xC9, 0xC3, 0x80,            // RF_POWER_UP
    0x08, 0x13, 0x01, 0x08, 0x01, 0x01, 0x01, 0x0B, 0x00,      // GPIO_PIN_CFG: int. disabled
    0x06, 0x11, 0x00, 0x02, 0x00, 0x52, 0x00,               // GLOBAL_XO_TUNE
    0x05, 0x11, 0x00, 0x01, 0x03, 0x60,                   // GLOBAL_CONFIG
    0x05, 0x11, 0x01, 0x01, 0x00, 0x00,                     // INT_CTL_ENABLE int disable
    0x08, 0x11, 0x02, 0x04, 0x00, 0x00, 0x00, 0x00, 0x00,      // FRR_CTL_A_MODE
    0x07, 0x11, 0x10, 0x03, 0x00, 0x04, 0x14, 0x00,            // PREAMBLE_TX_LENGTH
    0x09, 0x11, 0x10, 0x05, 0x04, 0x31, 0x00, 0x00, 0x00, 0x00,   // PREAMBLE_CONFIG
    0x09, 0x11, 0x11, 0x05, 0x00, 0x03, 0x8B, 0x89, 0xCB, 0x89, // SYNC_CONFIG (2 bytes 0xD3 0x91)
    0x05, 0x11, 0x12, 0x01, 0x00, 0x84,                     // PKT_CRC_CONFIG
    0x08, 0x11, 0x12, 0x04, 0x03, 0xFF, 0xFF, 0x00, 0x02,      // PKT_CRC_CONFIG
    0x05, 0x11, 0x12, 0x01, 0x0B, 0x30,                     // PKT_TX_THRESHOLD
    0x10, 0x11, 0x12, 0x0C, 0x0D, 0x00, 0x05, 0x04, 0xA2, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
    0x0C, 0x11, 0x12, 0x08, 0x19, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // RF_PKT_FIELD_LENGTH
   0x10, 0x11, 0x20, 0x0C, 0x00, 0x02, 0x00, 0x07, 0x00, 0x2E, 0xE0, 0x01, 0xC9, 0xC3, 0x80, 0x00, 0x00,
    0x05, 0x11, 0x20, 0x01, 0x0C, 0xB4,                     // MODEM_FREQ_DEV (5.15 KHz)
    0x0C, 0x11, 0x20, 0x08, 0x18, 0x01, 0x80, 0x08, 0x03, 0xC0, 0x00, 0x24, 0x20,
    0x0D, 0x11, 0x20, 0x09, 0x22, 0x03, 0x0D, 0x00, 0xA7, 0xC6, 0x00, 0x54, 0x02, 0xC2, // 903 MHz
    0x0B, 0x11, 0x20, 0x07, 0x2C, 0x04, 0x36, 0x80, 0x01, 0x5D, 0x07, 0x80,
    0x05, 0x11, 0x20, 0x01, 0x35, 0xE2,
    0x0D, 0x11, 0x20, 0x09, 0x38, 0x11, 0xAB, 0xAB, 0x00, 0x02, 0xFF, 0xFF, 0x00, 0x2B,
    0x0A, 0x11, 0x20, 0x06, 0x42, 0xA4, 0x02, 0xD6, 0x81, 0x01, 0x29,
    0x05, 0x11, 0x20, 0x01, 0x51, 0x08,                     // RF_MODEM_CLKGEN_BAND
   0x08, 0x11, 0x22, 0x04, 0x00, 0x18, 0x19, 0xC0, 0x3D,      // RF_PA_MODE
   0x0B, 0x11, 0x23, 0x07, 0x00, 0x2C, 0x0E, 0x0B, 0x04, 0x0C, 0x73, 0x03,
    0x0B, 0x11, 0x40, 0x07, 0x00, 0x3B, 0x09, 0x99, 0x99, 0x22, 0x22, 0x20};

[Feruz]

Ser60, большое Вам спасибо! Дело действительно оказалось в том, что чип селект поднимался раньше чем завершался обмен по SPI, как итог сишка некорректно воспринимала все, что ей передают. ( Посыпаю голову пеплом, в даташите si4463 ведь есть рисунок с таймингами SPI где показано, что должно быть минимум 50нс между спадом последнего clock и фронтом чип селект)

Ирония в том, что я ведь тоже это замечал ранее, и пытался исправить (в моем коде есть закомментированная строчка "//while(SPI1->SR & SPI_SR_BSY){}"). Но мои сегодняшние опыты показали что ожидание флага BSY не исправляет ситуацию. Но это уже предмет дальнейших изысканий. Пока что я просто добавил задержку перед подъемом чип селект, и все заработало - и clock out и передача в эфире.

Еще раз спасибо за то, что открыли глаза)

[PANYTA]

У меня вопрос к Ser60.

В вашей статье написано, что "Новые серии микросхем имеют существенно лучшие параметры".
Я про сравнение SI4432 с SI4464.
Самое "радикальное", что я увидел на первых страницах датшитов это чувствительность: -126dBm против -118dBm.
Мощность та же. Токи потребления почти те же.
Собственно вопрос: чем они (4464 против 4432) лучше?
Я с чисто юзерской точки зрения.
Раньше использовал MRF49. Сейчас работают 4432. Однозначно лучше (дальнобойней при прочих равных).
Есть ли смысл переходить с SI4432 на SI4464 ?

А может есть уже более новые ?

[Ser60]

Мне кажется, что Вы сами ответили на свой вопрос по каким параметрам они лучше. Например, токи в активном режиме различаются более чем в 1.5 раза, и только это уже немало. Хотя, если устройство от сети питается, то это улучшение не так важно. Ещё скорость передачи у новых чипов в 4 раза выше. Разница в чувствительности 5 dBm также существенна. В теории при идеальных условиях увеличения link budget на 6 dBm означает прирост дальности связи в 2 раза. На смену серии 4460-64 сейчас пришли SI4467/68 с ещё более лучшими параметрами по чувствительности. Однако, насколько это существенно для приложений - без информации о приложении и в общем ответить трудно. Может оказаться, что в конкретных условиях связи никакого улучшения и не будет заметно. Единственный вариант проверить - это попробовать их на практике в конкретных условиях. В любом случае, хуже не будет.

[Feruz]

Друзья, возникли проблемы с приемом с CRC. Если происходит прием пакета с неверной контрольной суммой, то следующий пришедший пакет, который судя по информации от 4463 имеет верную контрольную сумму, содержит нулевые информационные байты... =( В эррате на чип есть похожий пункт "2.14 If a Received Packet has CRC Error, Subsequent Packets will Report a Command Error" однако он не описывает что в этом случае происходит с информационными байтами. (П.с. - после приема битого пакета, сброс RX FIFO выполняется.)

Добавлено after 1 hour 24 minutes 54 seconds:
Да, действительно проблема была в том, что и указано в эррате. Описанный там же воркэраунд решает проблему. Если коротко, то после битого пакета надо перейти в режим sleep и только потом снова в rx.