← Blog Hardware

Projektowanie zasilanych bateryjnie urządzeń IoT z 5-letnim czasem pracy

MCU

Analiza budżetu energetycznego baterii — każdy mikroamper się liczy, gdy celujesz w ponad 2 lata pracy na baterii pastylkowej

Uzyskanie 5 lat pracy z baterii pastylkowej wymaga systematycznej optymalizacji na każdym poziomie: doboru MCU, architektury trybów uśpienia, odcinania zasilania peryferiów, cyklowania pracy radia oraz projektu firmware'u.

Zacznij od budżetu energetycznego

// Budżet energetyczny — GEST v2 (CR2032, 225 mAh)

Stan             | Prąd     | Cykl  | Śred. μA
Głęboki sen      | 3 μA     | 98.8% | 3.0
Rozgłaszanie BLE | 4 mA     | 0.8%  | 32.0
Połączenie BLE   | 6 mA     | 0.15% | 9.0
Wybudzenie przyc.| 5 mA     | 0.25% | 12.5
-----------------------------------------
Razem: ~57 μA → 2+ lata na CR2032 ✓

Architektura głębokiego uśpienia

Projektuj firmware jako sterowaną zdarzeniami maszynę stanów, spędzającą ponad 99% czasu w najgłębszym uśpieniu. Wybudzaj się wyłącznie na przerwanie sprzętowe i wracaj do uśpienia najszybciej, jak to możliwe.

// ESP32 — wybudzenie z głębokiego snu na GPIO + timer

esp_sleep_enable_timer_wakeup(30 * 1000000ULL);
esp_sleep_enable_ext0_wakeup(BUTTON_PIN, 0);
esp_deep_sleep_start();  // ~8μA
🔋 Nauczka z praktyki
W GEST v1 błąd uniemożliwiał zakończenie połączenia BLE, jeśli brama nie rozłączyła się jawnie. Urządzenia pozostawały połączone przez BLE przez minuty zamiast sekund. Żywotność baterii spadła z 18 miesięcy do 3 miesięcy. Zawsze testuj najgorsze scenariusze połączeń, a nie tylko ścieżkę optymistyczną.

Odcinanie zasilania peryferiów

Jedną z najbardziej efektywnych technik wydłużania żywotności baterii jest odcięcie zasilania nieużywanym peryferiom. Czujnik temperatury i wilgotności pobierający 1 mA podczas pomiaru można zasilać przez tranzystor P-MOSFET przełączany pinem GPIO. Podczas głębokiego uśpienia czujnik nie otrzymuje zasilania w ogóle. Przy interwale pomiaru co 5 sekund i okresie aktywności 50 ms zmniejsza to udział czujnika w średnim prądzie o 99%.

Podobnie układy pamięci NOR flash pobierają 30–100 μA w trybie czuwania. Wywołanie spi_flash_deep_sleep() przed wejściem MCU w tryb uśpienia całkowicie to eliminuje. Pamięć SPI flash w głębokim uśpieniu pobiera poniżej 1 μA w większości elementów. W urządzeniu z docelową żywotnością baterii 2 lat te oszczędności rzędu mikroamperów sumują się w miesiące dodatkowego czasu pracy.

LDO vs stabilizator impulsowy

Wybór między LDO (stabilizatorem liniowym) a stabilizatorem impulsowym (SMPS) jest niuansowy dla projektów o ultraniskim poborze mocy. Przy prądach obciążenia powyżej 20 mA stabilizator impulsowy jest niemal zawsze bardziej wydajny — 85–95% wobec 60–80% dla LDO. Jednak przy obciążeniach rzędu mikroamperów obserwowanych podczas głębokiego uśpienia dominuje prąd spoczynkowy stabilizatora (Iq). Niektóre LDO mają Iq poniżej 1 μA; stabilizatory impulsowe rzadko osiągają Iq poniżej 5 μA.

Praktyczne rozwiązanie: użyj stabilizatora impulsowego dla głównej szyny zasilania podczas pracy aktywnej i wybierz stabilizator z trybem niskiego poboru mocy lub zastosuj osobny LDO dla domeny stale zasilanej. W GEST v2 stosujemy przetwornicę buck-boost TPS63036 dla głównej szyny oraz LDO TLV733P (Iq 1 μA) dla stale zasilanego RTC i logiki wybudzania.

Dyscyplina firmware'u dla żywotności baterii

Optymalizacja sprzętu ma swoje granice. Równie ważna jest dyscyplina firmware'u. Każda milisekunda z procesorem pracującym na pełnej prędkości kosztuje baterię. Po wybudzeniu z uśpienia przetwarzaj dane najszybciej, jak to możliwe, i wracaj do uśpienia. Unikaj pętli aktywnego oczekiwania — stosuj komunikację z peryferiami sterowaną przerwaniami lub opartą na DMA. Loguj intensywnie w trakcie developmentu, aby poznać rzeczywisty czas wybudzenia w porównaniu z oczekiwanym; znaleźliśmy błędy powodujące 10-krotnie dłuższe czasy wybudzenia niż zamierzone, co o połowę skracało prognozowaną żywotność baterii.

Projektowanie zasilanego bateryjnie IoT to dyscyplina dotykająca każdej warstwy produktu — od doboru komponentów i układu PCB po architekturę firmware'u i procedury testów fabrycznych. W FSS projektujemy sprzęt i firmware w tym samym zespole, co jest jedynym sposobem na osiągnięcie ścisłej współoptymalizacji, jakiej wymaga wieloletnia żywotność baterii.

Budujesz produkt IoT?

FSS to pełnostackowy zespół inżynieryjny IoT — sprzęt, firmware, chmura i aplikacje mobilne w jednym miejscu.

Nasze możliwości IoT →