BLE SoC PHY6202

[pvvx]

TG7100B и TG7120B - это тоже PHY62xx, но с какими-то модификациями.

Все с кристаллом PHY6222 могут работать в Zigbee, но SDK для Zigbee нет.

 

[pvvx]

И для SDK под Keil с блобами я ничего вам больше подсказывать бесплатно не буду, т.к. он платный и если вы заплатили за него, то извольте платить и за ответы
А для нормальных людей есть SDK под GСС со всеми исходными кодами у cool2000 на github. У меня SDK на github урезан для адаптации к проектам термометров.

 

[_eugene_]

Конфликтов внутренних подтяжек чипа с внешними цепями нет хотя бы потому, что я отключаю перед замером и SWD и UART, а внутри модуля согласно его схеме других подключений нет.

Если ориентироваться на этот ваш график

Keychain with chip ST17H66B (iSearching) · Issue #94 · pvvx/THB2

Key fob on chip ST17H66B with firmware "KEY2" iSearching - BLE, Flash iSearching2 - BLE, Flash iSearching3 - BLE, OTP (!) There are a large number of variations of this device. Switching to “FindMy...

github.com

то при периоде 6 секунд у меня должно быть около 9 мкА потребления, а имеется 14 мкА.

Итого лишних 5 мкА.
Возможно у вас работает RAM_retention только для SRAM0, а у меня +SRAM1.
Ещё надо бы сковырнуть экран модуля и выпаять супрессор.

P.S. Поставил перед запуском ОС:
hal_uart_deinit((UART_INDEX_e)UART0);
hal_uart_deinit((UART_INDEX_e)UART1);
потребление не изменилось. С процессе работы UART включаться не должен, LOG отключен, мой код включает его только при коннекте или при GPIO_WAKEUP.

 

[_eugene_]

...извольте платить и за ответы

Не... платить я не люблю
Уж лучше сам как-нибудь разберусь.

 

[pvvx]

Итого лишних 5 мкА.

Значит такой SDK для Keil. А для поиска что там не так у вас мне нужно купить Keil.

 

[pvvx]

График наверно даже завышен в потреблении, т.к. реальные брелоки с этими чипами ещё работают с батарейками из них, которые там были несколько лет (валялись пока руки не дошли до этих брелоков) и были практически севшими (в данных брелоках батарейки включены и чип в режиме deep-sleep при продаже с ожиданием нажатия кнопки).
И так работают c моим SDK:

 

[pvvx]

Разница в среднем потреблении возможна от выставленного уровня TX RF. На графике он дан для 0 дБм.

 

[_eugene_]

PHY6222... есть и кривые партии с совсем нестабильным RC генератором)

Генератор совсем останавливается что ли?

 

[_eugene_]

Разница в среднем потреблении возможна от выставленного уровня TX RF. На графике он дан для 0 дБм.

Ну да у меня +5dBm, а ещё у меня же CONNEСТABLE а у вас вроде нет.

 

[pvvx]

Генератор совсем останавливается что ли?

При соединении возникает уход RC генератора из-за нестабильности внутреннего питания. При sleep напряжение питания уменьшается, а при активности SoC увеличивается. И расчет таймингов BLE нарушается, т.к. коррекция рассчитывается и применяется при активном SoC от кварца.
А уход RC более нормативов BLE спецификации, даже у нормальной партии чипов. При этом в доках PHY нагло врут.

 

[pvvx]

Ну да у меня +5dBm, а ещё у меня же CONNEСТABLE а у вас вроде нет.

Мои брелоки работают с "CONNEСТABLE" и с достаточно длинным фреймом передачи в формате BTHome. И работают как выключатели прожекторов на улице...
Как FindMy не используются - ну нет у нас в округе Aplle и вообще никого нет - лес и там быстрее собаками найти

 

[pvvx]

А так-же их достаточно часто периодически опрашивает в режиме активного сканирования шлюзы Xiaomi...
Лезут ко всем BLE... Хорошо ещё, что это дело у них периодическое, а постоянное, как в всяких интеграциях по умолчанию...

 

[pvvx]

Взял один из брелоков. Попробовал измерить тестером UT89XE - пищит на диапазоне 200 uA - оно и понятно... Но все таки успел измерить ток sleep: показал 3.43/3.44 мкА.
Всунул в дурной PPK2 от nRF, который рисует липовые выбросы при автопереключении диапазонов (и с этим ничего не сделать - такие разработчики в nRF):




Т.е. имеем формулу расчета что-то типа:
При периоде 10 сек: (5.81мс*6.41мА+0.00344мА*9994мс)/10000мс = 0.007162146 мА
При периоде 6 сек: (5.81*6.41+0.00344*5994)/6000 = 0.009643576666...

 

[pvvx]

Итого лишних 5 мкА.
Возможно у вас работает RAM_retention только для SRAM0, а у меня +SRAM1.

+-SRAM1 дает в максималке полтора мкА.
А что там у брелока - он сам знает, т.к. выбор идет автоматически. Наверняка SRAM0+SRAM1

 

[pvvx]

 

[pvvx]

Наверно в вашем SDK для Keil забыли переключить питание в режиме sleep для RAM и/или Flash (там тоже должно переключаться и в других частях так-же)... Копайте бинарные блобы либ для Keil
Или в PHY докопались до бага RC и не стали опускать питание в sleep... Я пошел другим путем - полностью переписал расчет коррекции RC гена.

 

[_eugene_]

В моём случае есть возможность сделать отключение BLE с 20:00 до 08:00 тогда 14 мкА превратятся в 7, мне этого за глаза хватит.

 

[pvvx]

UT71B показывает на этот брелок так:

В моём случае есть возможность сделать отключение BLE с 20:00 до 08:00 тогда 14 мкА превратятся в 7, мне этого за глаза хватит.

Купили Keil - значит за батарейки платить можете

 

[pvvx]

7 мкА имеет среднее потребление TLSR825x в термометре без экрана и периоде маяка в 2.5 секунды.
Думаю вам надо купить PowerProfiler, а то неизвестно что вы там измеряете...

 

[_eugene_]

Купили Keil - значит за батарейки платить можете

Я купил Keil за ту долю, ежемесячной оплаты Интернет трафика, в течение которой он скачивался. Считаю, что этого вполне достаточно.