31-10-2022, 23:01 (Ten post był ostatnio modyfikowany: 31-10-2022, 23:23 przez brendy.)
Co do pracy timera nie mam zastrzeżeń, ale po podłączeniu do układu pobór prądu w zakresie napięcia roboczego tego timera jest za duży na Aku 18650 wyssał mi w ciągu 12H 0.01V. Narazie nie ma czasu zbadać dokładnie prądy, ale prąd podtrzymania timera, a prąd roboczy przez vdd nie daje mi jakiś dobrych wyników. Wartości napięcia baterii wysyłam co 20 min sobie na serwer i obserwuje na wykresie i widzę jak Aku liniowo szybko leci w dół.
Po odłączeniu timera od układu na wykresie widzę jak bateria zaczyna wolno spadać 0.003V w ciągu ponad 2 dni, a z timerem 0.01V w ciągu 12H straszna lipa z tym timerem żre jak python ofiarę.
Najlepsze timery na baterie jakie udało mi się trafić to te z programatorów czasowych mają one 10 alarmów i czasami przerabiam je po procki żeby wybudzaly o określonej godzinie tam pobór razem z wyświetlaczem 2.2uA.
Znalazłem coś takiego MAX31331
Ale masz oba układy zasilane z tego samego napięcia Vcc, najlepiej nie więcej niż 3.3V?
Dziwi mnie duża różnica poboru w moich pomiarach przy zasilaniu 5 i 3 V, wg karty katalogowej to powinno być w obu przypadkach coś w okolicach 1uA. Ale nie chciało mi się budować układu na 3.3V, podłączyłem to do UNO zasilanego 5V, tylko sam zegar zasiliłem z 3.3V.
Przy uśpieniu czasami warto dodać stabilizator liniowy, używałem kiedyś HT7333 LDO, typowy wyciek 4uA. Urządzenia mają dużo niższy pobór gdy są zasilane z niższego napięcia, choć oczywiście nie wyższego niż potrzebne. Tak na czuja wydawało mi się odwrotnie, paliwa o wyższej kaloryczności powinno zużywać mniej.
Kiedyś bawiłem się z ESP8266 podłączonym bezpośrednio do aku 18650, nawet kilka i wszystkie wytrzymały te testy (przez jakiś czas), ale pobór w uśpieniu był 400uA zamiast 10uA , spadał wraz z napięciem aku, ale najwięcej energii jest w nim powyżej 3.3V, po dodaniu regulatora LDO spadł do 15uA w uśpieniu. Tu oczywiście napięcie dodatkowo było w ogóle poza dopuszczalnym zakresem dla ESP max 3.6V.
Stabilizator liniowy generuje dużo straty przy większym poborze prądu, ale jak układ jest głównie uśpiony to może się opłacać.
01-11-2022, 10:41 (Ten post był ostatnio modyfikowany: 01-11-2022, 12:31 przez brendy.)
Poprzedni układ o którym wcześniej pisałem gdzie używam inny timer co pobiera mi 2.2uA jak wcześniej pisałem, właśnie tam używam LDO MCP1700T-1202E/MB pobór samego ldo to tylko 1.6uA.
Myślę, że tutaj trzeba zrobić podobnie, bo może być tak jak piszesz, że timer PCF8563 kiedy ma ponad 3.3V może brać więcej.
Teraz mam wyjezdne ale jak za 2 dni wrócę to plan jest taki
Skoro dokumentacja mówi że zakres od 1.0-5.5V to chce zastosować MCP1700T-1202E/MB i zasilić go na 1.2V i zobaczyć jak to się zachowa bo obecnie zasilam timer 3.93V jak resztę układu i może faktycznie stąd te duże prądy.
tak bym to widział, schemat o nazwie pcf zawiera blad nie mogę go usunąć...
Nie możesz go zasilać dużo niżej niż będziesz miał napięcia na pinach. Do komunikacji I2c i tak musi być minimum 1.8V, 1V to jest tylko by mógł przechować dane w pamięci.
AVR też mogą działać na 5V, ale jak są zasilane z 2V to nie można im sypać sygnałami 5V, bo wtedy muszą łykać większy prąd, np. w dataSh. Atmega328P:
Voltage on any Pin except RESET with respect to Ground: -0.5V to VCC+0.5V
A jak podasz na INT napięcie podciągania dużo niższe niż Vcc Atmegi, to Atmega może nie zauważyć, że stan się zmienił, bo to będzie zmiana z 0 na 0.
04-11-2022, 17:46 (Ten post był ostatnio modyfikowany: 04-11-2022, 17:59 przez brendy.)
Po wykonoaniu testów timer PCF8563 nie nadaję się do zasilania bateryjnego. Szukając dalej i drążąc temat na necie nie ma nic oszczędnego. Postanowiłem sam spróbować i udało się wykonałem układ, który może nie jest jak klasyczny timer, ale wykonuje 2 alarmy lub więcej o określonych godz zgodnie założeniem i uwaga! Pobór prądu 200nA i to podczas pracy przy 4V! nie czuwania. Zrobiłem symulacje i jestem zadowolony. Jeszcze będą testy, ale do tego celu ktrórego chce użyć w zupełnosći wystarczy czas nawet jest dokładny. Temat do zamknięcia.
05-11-2022, 00:02 (Ten post był ostatnio modyfikowany: 05-11-2022, 00:16 przez brendy.)
Jeszcze zapomniałem dopisać ten chip 5110 może być użyty jako zewnętrzny watch dog myślę że jeszcze lepsza opcja bo wew watch dog w procku zrobi reset a ten timer odetnie zasilanie na chwilę i wtedy na pewno zainicjują się wszystkie urządzenia peryferyjne.
Jeśli TPL nie odbierze sygnału przed upływem ustawionego czasu to zresetuje proc jak typowy watchdog spr u działa rewelacyjnie
Już mi śnią się te timery po nocach czas pograbic liście
Ja jeszcze się pobawiłem dzisiaj tym RTC PCF8563.
Moduł zachowuje się trochę dziwnie, ale może tylko dla mnie, bo się nie znam.
Mam wrażenie, że pasożytuje każdym połączeniem z uC, tak że najlepiej jakby były zasilane tym samym napięciem, niskim, w granicach 3V.
Pobór A bez żadnego połączenia z uC jest większy niż wtedy gdy jest połączony z uC i układy się komunikują wysyłając okresowo godzinę. Z ogniwa 4V ciągnie 12uA przez rezystor pomiarowy i diodę obniżającą napięcie do o 0.5V.
Zmontowałem układ z Atmegą 328P zasilaną z 2.5V pobór jest 0.6uA, ale obawiam się, że sam rezystor pomiarowy obniżający napięcie o 0.6mV wystarcza by ciągnął prąd gdzieś bokiem, bo moduł podłączony bezpośrednio i tylko do zasilania 2.5V pobiera 1.2uA. Do tego na płytce są już diody, więc moduł jest zasilany 0.3V mniej niezależnie czy to leci z baterii czy VCC układu uC-RTC (tester w trybie diody pokazuje 0.6V).
Nie można jakoś bardzo zejść poniżej 3V, bo wtedy będzie sobie szabrował z baterii 3.3V. Pomiary wykonałem z wyjętą baterią. Moduł był w stanie jeszcze działać gdy był połączony przez diodę do pinu VCC i przez 1000R do pomiaru, pobierał wtedy 0.5uA, z VCC, pewnie reszta przez pozostałe połączenia.
Wbudowane kondensatory wystarczają na kilkanaście sekund, można podmienić baterię i nie stracić czasu.
Generalnie nie jest więc taki zły, byle go używać na poziomie <=3.3V. Nawet jakby bateria CR1220 36mA była drenowana 12uA, to i tak wystarczy na kwartał, a że z każdym spadkiem będzie pobierał mniej, to na rok powinna wystarczyć.
