BLE SoC PHY6202

[pvvx]

У nRF5x свои заморочки и в основном программные, если не считать бага в DC-DC.
Наименьший по размеру код стека BLE или Zigbee у Telink и нет ROM. Для простого BLE устройства весь код стека влезает даже в половину имеющейся RAM - не требуется более 32 килобайт на всё.
У PHY - в разы больше и его программная архитектура ужасна, при этом есть и используется ROM, а линкуемый патч стека BLE для ROM более 50 килобайт.
У nRF - громадный линкуемый бинарный файл...

 

[powar]

Скорее всего это просто реклама.

PHY62xx не отличается какими-то успехами от других BLE/Zigbee чипов одного класса.

Всё верно, производитель именно так и говорит - Phyplus живёт от батарейки меньше, чем Nordic. Хотя этот нордик уже пенсионер. Я, видимо, не очень понятно написал.

Обусловлено большей длительностью пробуждения SoC PHY62xx из sleep, до работы с RF частью

Я подозреваю, отчасти в этом "заслуга" SDK.

Например, каждый раз может запускаться автокалибровка rtc или радиотракта. К тому же у меня, например, она работала некорректно. Значения g_rfPhyTpCal0 и g_rfPhyTpCal1, на основе которых формируется значение регистра 0x40030094 (вероятно, ответственного за тонкую настройку ВЧ приемопередатчика), получались такие, что рекламные посылки виделись не всеми устройствами (уходило за допустимые +-150кГц?). Пришлось руками подбирать оптимальные значения. По хорошему бы в dtm режиме посмотреть частоту несущей каким-нибудь оборудованием. У меня есть SDR nuand bladeRF x115, но я не уверен в точности его заводской калибровки, а как проверить на коленке - не знаю.

 

[powar]

У PHY - в разы больше и его программная архитектура ужасна, при этом есть и используется ROM, а линкуемый патч стека BLE для ROM более 50 килобайт.

Но радует, что есть утекшие исходники ble стека. И внести свои патчи гораздо проще.

 

[powar]

Значения g_rfPhyTpCal0 и g_rfPhyTpCal1, на основе которых формируется значение регистра 0x40030094 (вероятно, ответственного за тонкую настройку ВЧ приемопередатчика), получались такие, что рекламные посылки виделись не всеми устройствами (уходило за допустимые +-150кГц?). Пришлось руками подбирать оптимальные значения. По хорошему бы в dtm режиме посмотреть частоту несущей каким-нибудь оборудованием. У меня есть SDR nuand bladeRF x115, но я не уверен в точности его заводской калибровки, а как проверить на коленке - не знаю.

Посмотрел через SDR приемник сигналы, генерируемые в test mode, оказалось, за подстройку несущей отвечает XTAL_CAP (макрос XTAL16M_CAP_SETTING, регистр 0x4000f0bc), а TX_TPCAL (регистр 0x40030094 ) влияет на какие-то параметры модуляции (коэффициенты фильтра Гаусса?), но не частоту несущей.

 

[pvvx]

Например, каждый раз может запускаться автокалибровка rtc или радиотракта.

Калибровку RTC и так пришлось патчить по своему. И проблема длительного запуска не в ней. Есть аппаратный счетчик и пока он работает производится инициализация других частей...
Уход RTC у некоторых экземпляров PHY6222 просто ужасен и калибровать надо каждый раз, т.е. набирать статистику. А для набора статистики нужно много значений.
Имеющийся в SDK код с этим не справляется.
Основные причины: разное напряжение питания RTC при работе и во время sleep. Попробуйте откалибровать Подходит только нечто среднее...

 

[pvvx]

Посмотрел через SDR приемник сигналы, генерируемые в test mode, оказалось, за подстройку несущей отвечает XTAL_CAP

У всех BLE/Zigbee чипов есть XTAL_CAP.
Значения обычно хранятся во Flash где не попадя - зависит от SDK и конкретного производителя.
При очистке Flash они улетают...
По этой причине нигде не используются. Всё зависит от качества кварца, и этого в 99% достаточно.
На работе RF (приема-передачи) никак не сказывается.
Проблемы только от кривого RTC (зависящего от напряжения питания чипа) и это сильно значимо при BLE соединении. А в случае маяков уход RTC безразличен.
Указанный уход RTC в доках дан для питания от стабилизированного источника и без включений sleep и изменений внутренних напряжений.

 

[pvvx]

А при питании от батареи напряжения питания меняется от нагрузки на более 40%. Плюс для достижения меньшего тока утечки RAM и прочего во время sleep внутреннее напряжение для sleep переключается, что меняет частоту RTC до 15%.
Такая халтура у PHY.
И видимо есть ревизии кристалла или откровенные партии брака, т.к. RTC ведет себя по разному и зависит от маркировки на чипе....

 

[pvvx]

Но радует, что есть утекшие исходники ble стека. И внести свои патчи гораздо проще.

"исходники ble стека" нет. Есть только куски патча для стека находящегося в ROM.