PullUp NRF52842

Pondělí Leden 20 17:28:43 CET 2025

Měření na našem projeku s nRF82532

Celý vysílací děj adverttisingu trvá 4ms (standardní 3 kanály).
Při nastavení výkonu na 0 dBm (stačí min. na 10m) vyšel průměrný odběr při vysílání 3,9 mA.
Bylo to zhruba koleno závislosti Pwr - Idd, při menším výkonu je už dominantní vlastní spotřeba MCU. 

Spotřeba byla počítaná jako integrál křivky, roztažené na celou obrazovku osciloskopu, měřeno na odporu.
Máme tu sice 6.5 místný Keithley, ale pro ten pulzní odběr to měřilo hausnumera.

V mezeře byla spotřeba cca 10uA, ale to zahrnuje celou desku včetně ostatního HW na desce.

V příloze je zhruba průběh, ten malý hrbolek na začátku k tomu patří také.

Tomáš

Děkuji za odpověď. O BLE se příležitostně zajímám něco přes rok a vlastně si vzpomínám, že s tím skenováním máte pravdu a že reklama na nějaké delsi přenosy moc není (spis sem tam neco). Mohl bych příležitostně požádat o změření té spotřeby? Děkuji.

MG

Dne ne 19. 1. 2025 16:28 uživatel Tomas Hamouz <konfery.tomas.hamouz na seznam.cz> napsal:
Jako zdroj 32kHz se může použít:
- Xtal 32k - nejmenší spotřeba v klidu, součástky navíc
- RC interní - nejjednodušší, přijatelná spotřeba v klidu, stačí na BLE, málo přesný na NFC
- dělička z hlavního Xtalu - velká spotřeba v klidu

LF hodiny slouží jen k časování ve spánku, ale ten procesor víceméně spí furt. Mají v SDK velmi hezký systém timerů, odvozený od LFC, který slouží pro spouštění funkcí dle potřeby, aniž by to zvyšovalo klidovou spotřebu. 
K vyslání advertisingu se samozřejmě CPU budí, ale pokud se stáhne vysílaný výkon a bude rozumná perioda, tak je střední hodnota odběru velmi malá. Teď z hlavy nevím, ale v pondělí můžu z práce poslat konkrétní čísla.

Lepší je posílat data při připojení, pak je totiž otevřený komunikační kanál a data chodí spolehlivě. Pokud se posílají v advertisingu, musí taky protistrana mít spuštěný scanning a zatím všechna zařízení která jsem zkoušel do cca 1 min scanning skončí.

Navíc, při standardním advertisingu se posílají 3 pakety (na 3 kanálech), kdežto při spojení jen jeden.

Tomáš

Díky za info. Ještě by mě zajímalo jak je to u NRF s 32khz krystalem. Dočetl jsem se, že z těch asi 3 možnosti jak dostat hodiny na nízké frekvence je externí 32khz krystal jediná možnost jak se dostat se stálou spotřebou na jednotky uA (mozna cca 10uA uz si to nepamatuji). Ostatní možnosti (delicka atd) už jsou se spotřebou na stovky uA. Nějak nemohu zatím najít info zda kdyz se přejde s hodinami na 32khz jestli ten procesor umí i něco jiného než jenom spat. Zda k vyslani reklamy není nutné procesor probudit nebo jak to je. Mám takovou ideu a spotřeba je rozhodující (NRF+akcelerometr nic vic). A zatím ještě nevím zda data z akcelerometru vysílat v rámci reklamy nebo jako service po připojení. Přičemž bych potřeboval při používání vyšší refresh dat z alcelerometru. Při nečinnosti klidně sem tam reklama, že to žije (akcelerometr může spat). Něco jako je iTag, ale chci data z akcelerometru a ne jenom pohyb/nepohyb, ale i XYZ. Tak přemýšlím jak na to a hlavně to umět pak prověřit co se týče spotřeby zda to sedí s tím co jsem zamyslel.

MG

Dne čt 16. 1. 2025 12:31 uživatel Jindrich Fucik <fulda na seznam.cz> napsal:
Tohle je něco, na co u microchipu také upozorňují v datasheetech.
Pokud na lince nejsou puluppy a je jako vstup (chápej - je ve vzduchu), 
tak probíhá část vyhodnocování - například jestli daný vstup nemá vliv 
na wake up a tak. Takže pokud je dostatek šumu, tak spotřeba může vzrůst 
poměrně signifikantně. Pochopitelně pak na tom vstupu jsou ještě další 
periferie, které při změnách také něco vyhodnocují a probouzejí se k životu.

Dne 15.01.2025 v 19:38 Michal Grunt napsal(a):
> Tady jsem se dočetl, že pokud budou PU aktivní i během spánku tak budou 
> odebírat 0.x uA. Četl jsem to snad i jinde. Někdo měl problém v tom, že 
> ty PU pred spánkem vypnul, měl to pak ve spanku ve vzduchu a mělo to 
> spotřebu stovky uA.
> 
> https://electronics.stackexchange.com/questions/600927/best-practices-for-low-power-consumption-battery-operated-i2c-pullups <https://electronics.stackexchange.com/questions/600927/best-practices-for-low-power-consumption-battery-operated-i2c-pullups>
> 
> Děkuji za graf že ktereho je jasné jaké hodnoty pro jaké rychlosti.
> 
> Dne st 15. 1. 2025 10:04 uživatel Pavel Hudeček <edizon na seznam.cz 
> <mailto:edizon na seznam.cz>> napsal:
> 
>     __
>     Ještě jsem se podíval do DS:
> 
> 
>     Na průměr v µA bude rozhodně potřeba ten Pu vypínat spolu s čidlem,
>     případně kombinovat s externím ňáký 100k-několik M, aby to čidlo
>     mezitím nějak nezblblo, pokud se mu teda nevypíná napájení.
> 
>     PH
> 
>     Dne 14.01.2025 v 17:26 Michal Grunt napsal(a):
>>     Zdravím, plánuji mít NRF52832 a k tomu LIS2DW12. Je nutné mít na
>>     I2C externí pullup nebo stačí interní v NRF? Zrovna dneska jsem
>>     narazil na článek nebo spíš problém ve fóru kde tazatel řešil
>>     větší spotřebu řádově stovky uA místo jednotky uA a řešilo se tam,
>>     že by to mohly delat pullupy a to ještě nejspíš zapomenuté zapnuté
>>     u nějaké sběrnice NRF, která se nepouzivala...
>>
>>     Ještě doplňující dotaz jak se měří spotřeba v řádech uA?
>     _______________________________________________
>     HW-list mailing list  -  sponsored by www.HW.cz <http://www.HW.cz>
>     Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>     http://list.hw.cz/mailman/listinfo/hw-list
>     <http://list.hw.cz/mailman/listinfo/hw-list>
> 
> 
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
Hw-list na list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list

-- 
Best regards,
Tomas                            mailto:konfery.tomas.hamouz na seznam.cz
_______________________________________________
HW-list mailing list  -  sponsored by www.HW.cz
Hw-list na list.hw.cz
http://list.hw.cz/mailman/listinfo/hw-list
------------- další část ---------------
A non-text attachment was scrubbed...
Name: scope_185.png
Type: image/png
Size: 29373 bytes
Desc: [žádný popis není k dispozici]
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20250120/673e44b5/attachment.png>