ATNEL tech-forum

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-08-29T19:22:20+01:00

Xantek napisał(a):

Jednak alarmy są na pinie SQW, a ja takowego pinu nie posiadam na tym układzie.

Skoro chcesz w ten sposób to przecież ten pin występuje na 3 nodze DS'a. Wyprowadź sobie ten pin na kabelku i po problemie...

Statystyki: Napisane przez buz11 — 29 sie 2017, o 19:22

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-08-16T18:47:33+01:00

Cześć, trochę minęło od ostatniego posta, niestety za dużo czasu nie miałem na to, by przysiąść przy kodzie, obecnie mam napisany nadajnik i jestem w trakcie wstępnego pisania kodu na odbiornik. Niestety natrafiłem na mały problem, w trybie power down nie działa timer2. Postanowiłem w tej sytuacji zajrzeć do szuflady i znalazłem w niej układ RTC, dokładnie taki: http://electropark.pl/rtc-zegary-czasu- ... s3231.html
W nocie wyczytałem, że da się w nim ustawić alarmy o konkretnej godzinie, co byłoby super przy włączaniu i wyłączaniu układu. Jednak alarmy są na pinie SQW, a ja takowego pinu nie posiadam na tym układzie. W necie znalazłem inne RTC o tej samej nazwie, które ten pin posiadają. Czy to znaczy, że mój RTC nie nada się od tego? Bo takie mam wrażenie. Jeśli tak, to czy ogólnie układ DS3231 z dostępnym pinem SQW będą odpowiednie do tego zadania? A może jest jakiś układ RTC, który będzie pobierał mniej prądu i również będzie posiadał alarmy (najlepiej 2)?

Statystyki: Napisane przez Xantek — 16 sie 2017, o 18:47

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T22:18:33+01:00

Dzięki, trochę mi to zajmie pewnie, bo nie zawsze mam czas na te zabawy, ale postaram się podzielić moimi wynikami.

Statystyki: Napisane przez Xantek — 22 cze 2017, o 22:18

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T22:16:15+01:00

No to cóż - nie pozostaje nic innego jak działać i podzielić się wynikami

Powodzenia i czekamy na info o postępach!

Statystyki: Napisane przez buz11 — 22 cze 2017, o 22:16

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T22:08:47+01:00

http://www.atmel.com/Images/Atmel-42735 ... asheet.pdf

Wg. powyższej noty katalogowej, mogę wprowadzić Atmegę w tryb Power save, włączając wcześniej timer2 i ustawiając, by wybudzała się przy przepełnieniu timera. Rozwiązanie może nie jest idealne, ale powinno wystarczyć, a przynajmniej ani NRF ani Atmega nie będą działały cały czas w trybie active. Czy może znowu coś pomyliłem?

@edit: Dopiero teraz zauważyłem, że w specce NRF'a jest podany zakres zasilania 1,9 - 3,6 V, a to oznacza, że na ścisłość wsio może jechać na 2 paluszkach, a napięcie na ogniwach może spaść do niecałego 1V, zanim układ zaśnie na wieki. To myślę, że problem rozwiązany.

Statystyki: Napisane przez Xantek — 22 cze 2017, o 22:08

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T21:47:59+01:00

Czekaj, bo chyba czegoś nie zrozumiałeś...
Na początku zakładałeś, ze będziesz usypiał AVR'a a wybudzać go miał NRF w trybie nasłuchu.
Teraz wymyśliłeś, że będziesz "próbkował" odbiornikiem wychodząc ze stany STB do Normal czy nie ma danych do odebrania.
Jeśli dobrze to zrozumiałem do tej pory - to jak chcesz wybudzić AVR'a skoro to procek ma sterować NRF'a?

Quote:

A jeśli o zasilaniu mowa, możesz odnieść się do tego o czym wspomniałem? Mógłbym użyć 2x 1,5V baterii, ale dość szybko układ przestanie działać zapewne z racji spadku napięcia. Opcja na 3 baterie będzie dużo lepsza, kwestia układu, który by sobie stabilizował napięcie do tych 3V jednocześnie nie pożerając 80% baterii.

Jak poprzedni problem jakoś rozwiążesz to proponuję użyć 3xAA, zasilanie NRF'a dać po 2 ogniwach, a AVR'a po 3 - obędziesz się bez stabilizatora

Statystyki: Napisane przez buz11 — 22 cze 2017, o 21:47

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T21:27:17+01:00

Wszystko na razie jest na stykówce, więc nie ma problemu. Największym problemem w sumie jest mierzenie prądu - nie mam żadnego sensownego miernika, któremu bym uwierzył, bo mój potrafi wariować na mierzeniu napięcia, ale czego oczekiwać po mierniku za 30 zł. Zwykłe watomierze też będą miały problem ze zmierzeniem tak małego poboru mocy zapewne... Ale w sumie najważniejsze to chyba, by najpierw zrobić tak by działało, a potem stestować na danym zasilaniu.

A jeśli o zasilaniu mowa, możesz odnieść się do tego o czym wspomniałem? Mógłbym użyć 2x 1,5V baterii, ale dość szybko układ przestanie działać zapewne z racji spadku napięcia. Opcja na 3 baterie będzie dużo lepsza, kwestia układu, który by sobie stabilizował napięcie do tych 3V jednocześnie nie pożerając 80% baterii.

Statystyki: Napisane przez Xantek — 22 cze 2017, o 21:27

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T21:09:38+01:00

W/g mnie takie założenie jest bez sensu, ale to Twój układ. Dlatego proponuję - złóż układ na stole i potestuj przez parę dni.
Najlepiej uczyć się na praktycznych przykładach
Daj znać jakie wnioski wyciągniesz po takim eksperymencie, bo pewnie znajdą się chętni aby je przeczytać!

Statystyki: Napisane przez buz11 — 22 cze 2017, o 21:09

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T21:02:47+01:00

Jeżeli odebrałeś moją wypowiedź jako pretensjonalną, to wybacz, nie o to mi chodziło. Jedyne rozwiązanie, które przychodzi mi do głowy, zakładając zostanie przy bateryjnym zasilaniu i układach NRF, to wyliczenie odpowiedniej liczby prób retransmisji co odpowiedni okres czasu przez nadajnik oraz odpowiednich okresów trybu RX w odbiorniku, by niezależnie od momentu wysłania sygnału, był on odebrany przez odbiornik. Pozwoli to na znaczną redukcję poboru prądu przez odbiornik kosztem nieznacznego wzrostu poboru prądu przez nadajnik (z tego co zdążyłem się naczytać, czas wybudzenia nadajnika będzie znacznie krótszy, niż wcześniej zakładana 1 sekunda).

@edit: Dodatkowo mógłbym spróbować zastosować układ RTC, dzięki któremu mógłbym wprowadzać odbiornik w pełne uśpienie w godzinach, w których nikt z tego nie będzie korzystał, a z racji, że będzie to wykorzystywane tylko w godzinach pracy, to czas pracy zmniejszy się do 7 dni roboczych w miesiącu.

Statystyki: Napisane przez Xantek — 22 cze 2017, o 21:02

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T20:14:58+01:00

Quote:

...bo zostało mi ono polecone do tego projektu

Zastanów się - skoro ktoś Ci polecił NRF'a do tego projektu, to chyba sam go dobrze nie znał, sugerując, że może odbierać dane w trybie Standby...
Poza tym Twoja wypowiedź zaczyna mieć ton pretensjonalny, a chyba nie o to tutaj chodzi...

Quote:

Ciągłe zasilanie modułu w trybie RX bardzo dobitnie eliminuje opcję zasilania bateryjnego, gdyż baterie starczą co najwyżej na kilka dni.

Dlatego napisałem abyś jeszcze raz przeanalizował problem i poszukał innego rozwiązania. Spójrz na ten odbiornik:
http://www.aurelwireless.com/wp-content/uploads/shortform/650200590G_sf.pdf
typowy pobór prądu w czasie działania to tylko 70uA

Statystyki: Napisane przez buz11 — 22 cze 2017, o 20:14

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T18:58:12+01:00

Radio specjalnie wybrałem takie, bo zostało mi ono polecone do tego projektu, a zasilanie też musi być bateryjne i wspominałem o tym przy pytaniu o moduł radiowy, który do tego się nada... Ciągłe zasilanie modułu w trybie RX bardzo dobitnie eliminuje opcję zasilania bateryjnego, gdyż baterie starczą co najwyżej na kilka dni.

Statystyki: Napisane przez Xantek — 22 cze 2017, o 18:58

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T16:11:34+01:00

Wiesz, twoje założenia są złe - przy takim cyklicznym włączaniu RX co jakiś czas uda Ci się odebrać dane ale na zasadzie loterii.
Jak chcesz mieć pewną transmisję, to albo zsynchronizujesz TX-RX - co w Twoim przypadku jest niemożliwe, albo zmień podejście - bo odbiornik musi być cały czas włączony. NRF ma możliwość włączenia retransmisji w przypadku braku potwierdzenia odebrania wysłanych danych - ale do tego to jeszcze u Ciebie daleka droga...
Dlatego zrób jak Ci napisałem - zmień koncepcję albo zmień radio na inne.

Statystyki: Napisane przez buz11 — 22 cze 2017, o 16:11

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-22T12:03:15+01:00

Okej, faktycznie teraz więcej poczytałem o tym NRF'ie i tylko tryb RX pozwala na jakiekolwiek próby odebrania danych. W takiej sytuacji muszę zmienić całkowicie koncepcję.

Na nadajniku niewiele się zmieni, będzie interrupt w postaci micro switcha, procek się wybudzi i załączy NRF'a i wyśle dane, więc możemy zostać przy tym założeniu raczej, oczywiście poprawiając mój błąd w obliczeniach.

Teraz kwestia odbiornika, opcja z ciągłym włączonym odbiornikiem odpada, więc musiałbym ustawić cykliczne wybudzanie się atmegi wraz z NRF by sprawdziło, czy jest coś do odbioru. Nawiązując do tego filmu https://youtu.be/MvjpmsH2wKI?t=4m37s, pojedynczy impuls transmisyjny trwa ok 1 ms, w nocie NRF'a jest napisane, że stan TX nie powinien trwać dłużej, niż 4 ms. Czyli mogę wnioskować, że impulsy RX nie muszą być bardzo długie, tylko mogą trwać też np. 2 ms i odczyt byłby wykonywany kilkadziesiąt razy na sekundę przykładowo, tak? Znasz może mniej więcej ten złoty środek między płynnym odbiorem transmisji, a względnie jak najniższym poborem prądu? Ile mniej więcej i jak długie musiały by być impulsy RX?

Statystyki: Napisane przez Xantek — 22 cze 2017, o 12:03

Re: Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-21T22:34:41+01:00

Xantek napisał(a):

0,3 * (2500 + 12,3) ...

Tutaj masz błąd - domyśl się dlaczego Podpowiem - do uA dodałeś mA...

I chyba mylisz się co do trybu Standby - w/g mnie nic w tym trybie nie odbierzesz, bo jest wyłączony odbiornik. Służy on tylko do szybkiego wybudzenia układu - dzięki temu już po 130us jest w stanie przejść do trybu TX/RX.
Sugeruję liczyć pobór prądu NRF'a na poziomie ~13mA przez cały czas działania układu

Przeanalizuj jeszcze raz, a wyjdzie Ci, że potrzebujesz co najmniej 10Ah na miesiąc - nie licząc samorozładowania aku zasilającego.

Statystyki: Napisane przez buz11 — 21 cze 2017, o 22:34

Optymalizacja prądowa kodu - NRF + Atmega328p

2017-06-21T16:01:03+01:00

Cześć

Z racji, że pojawił się problem z działaniem biblioteki do NRF'a na mojej Attiny44A, zacząłem porównywać zużycie prądowe Atmegi 328p vs wspomniane Attiny i stwierdziłem, że nie jest ono dużo większe, niż bym się spodziewał, dlatego postanowiłem pobawić się z Atmegą i redukcją jej zapotrzebowania na prąd. (Szczegóły problemu z Attiny: http://forum.atnel.pl/post190607.html#p190607 )
Zacznijmy od samego projektu, który tworzę... Buduję, najprościej mówiąc, przełącznik na kluczu tranzystorowym, który będzie załączany bezprzewodowo (nadajnik i odbiornik na module NRF24L01), który w razie mojej potrzeby będzie zwierał 2 przewody. Chodzi o to, bym mógł bezprzewodowo odblokowywać elektrozaczep wykorzystując przewody od przycisku, który do tego służy.

Zakładane wykorzystywanie: 30-50 razy dziennie w dni robocze.
Zakładane zasilanie:
Opcja 1: 2x paluszki AA, a dokładniej te: http://data.energizer.com/pdfs/xr91.pdf
Opcja 2: 3x paluszki AA te same co wyżej + jakiś stabilizator lub step down do 3V - i tu pytanie, co byście polecili?

Jeżeli dobrze rozumiem specyfikację Atmegi, to mogę ją wprowadzać w stan standby i wybudzać ją przerwaniem, które będzie generował układ NRF, tak? Jeżeli tak, to w takiej sytuacji zużycie energii przy wyłączeniu wszystkiego włącznie z watchdogiem to raptem 2 uA. Zakładając czysto teoretycznie teraz, że pojedynczy cykl działania układu trwa 1 sekundę i w tym momencie pobiera maksymalny prąd ze specyfikacji to jest to 2,5 mA dla Atmegi działającej na częstotliwości 4 MHz. Dodajmy do tego zasilanie NRF. Jeśli dobrze rozumiem, to w czasie "idle" układ może pracować w trybie Standby-I w celu oczekiwania na sygnał RX/TX. W takiej sytuacji pobiera 22 uA prądu. W czasie odbioru informacji przy maksymalnej mocy pobiera za to 12,3 mA i ten prąd uznaję na razie za maksymalną wartość. Do tego dla przypadku 2 opcji zasilania dochodzi strata na stabilizatorze/step down.

Podsumowując moje rozumowanie:
Zakładając, że miesiąc to 30 dni i mamy w nim 21 dni roboczych wychodzi:
maksymalnie 1050 użyć układu w miesiącu, co daje 1050 sekund działania całego układu. Jest to w zaokrągleniu 0,3 godziny, reszta to stan idle, czyli 719,7 godziny. Obliczenia wychodzą takie:
0,3 * (2500 + 12,3) + 719,7 * (2 + 22) = 753,7 + 17,273 = 18 030 uA = ok 18 mA miesięcznie. Czy moje rozumowanie jest prawidłowe? Czyli zwykłe baterie paluszki przy tym założeniu powinny starczyć tutaj na przynajmniej kilka miesięcy. Oczywiście może tutaj dojść jeszcze jakaś dioda czy też dodatkowe straty, więc mogę nawet podwoić ten wynik by mieć duży zapas względem tego, co wynika z noty, czyli powiedzmy 36 mA na miesiąc.

Teraz pytanie, czy moje myślenie jest prawidłowe? Czy popełniam gdzieś błąd?

Statystyki: Napisane przez Xantek — 21 cze 2017, o 16:01