E-papierowa prognoza pogody

[spook 92]

Zainspirowany projektem TPInk, postanowiłem zbudować własną prognozę pogody bazowaną na Raspberry Pi oraz wyświetlaczu e-papierowym.

 

Przyjąłem kilka założeń. Pierwszym z nich było zachowanie przynajmniej podstawowych zasad estetyki - zależało mi bowiem na tym, by zbudowane przeze mnie urządzenie było aktywnie użytkowane. Zdecydowałem się na wyświetlacz e-papierowy z uwagi na jego trwałość (zwykły wyświetlacz musiałby prezentować 24h na dobę bardzo podobne obrazy, co z pewnością skończyłoby się jego szybkim zużyciem), niskie zużycie prądu oraz - właściwe dla tego rodzaju wyświetlaczy - świetne dostosowanie do warunków oświetleniowych (im jaśniej tym lepiej). Sercem układu stał się tani i rewelacyjny Raspberry Pi Zero.

Sterownik wybranego przeze mnie wyświetlacza ma wyprowadzone 40-pinowe złącze kompatybilne z Raspberry, ale niestety nie można z niego skorzystać w przypadku Raspberry Pi Zero, ponieważ podczas próby podłączenia komputerek resetuje się. Problem ten jest znany i opisany na forum Waveshare, a bezpośrednią przyczyną jest fakt, że hat podłącza ekran do pinu 5V, z czym Raspberry sobie nie radzi. Wystarczy jednak zasilić ekran z dowolnego pinu 3,3V i wszystko śmiga aż miło.

Na szczęście istnieje druga opcja - sterownik wyprowadza również złącze, które kończy się goldpinami - można wtedy podłączyć wszystko ręcznie. Ponieważ jednak nie lubię za bardzo sterczących kabli w moich projektach, zdecydowałem się skorzystać z płytki uniwersalnej, na której wszystkie połączenia polutowałem przewodzikami kynarowymi. 

Na koniec pozostało zamontowanie wszystkiego w obudowie - siadłem więc do Fusion360 i przygotowałem do wydruku obudowę pod wymiar - tak, by wszystkie elementy były pewnie trzymane w swoich miejscach. Zadbałem też o dodatkowe otwory, by łatwo można było urządzenie powiesić na ścianę, zarówno w orientacji pionowej jak i poziomej.

Jeżeli ktoś będzie zainteresowany, mogę dorzucić projekt w Fusion, tylko jest on skrojony na miarę - jeżeli chcielibyście odtworzyć moją stację, musielibyście również polutować płytkę uniwersalną w taki sam sposób (lub zmodyfikować jej mocowania).

Teraz mogłem zabrać się za oprogramowanie stacji. Zdecydowałem się na Pythona, ponieważ nie zależało mi kompletnie na szybkości działania (ekran odświeża się co 15 minut, które w całości mogę wykorzystać na pobieranie i przetwarzanie potrzebnych danych), a jednocześnie jest to język, w którym wiele rzeczy robi się bardzo prosto.

Kompletny kod całego projektu (z wyłączeniem tylko kluczy API i współrzędnych geograficznych) załączam do posta, możecie go swobodnie ściągnąć, zmodyfikować i wykorzystać we własnych projektach. Dodam tu tylko, że zastosowałem w nim napisany samodzielnie mechanizm rysowawnia wykresów oraz czcionek - dzięki temu nie mam problemu z tym, że są one poszarpane (standardowe mechanizmy PIL próbują narysować je z antyaliasingiem, którego na monochromatycznym wyświetlaczu oczywiście osiągnąć się nie da).

RaspberryPicture.zip

Całość na ścianie prezentuje się następująco:

Po zakończeniu projektu wyciągnąłem następujące wnioski:

• Do tego typu projektów znacznie lepiej nadają się ekrany czarno-białe niż kolorowe. Mam jeden kolorowy, na którym zbudowałem sobie małą stację informacyjną na biurko i cały cykl odświeżania trwa ok. 15 sekund, co niweluje jego użyteczność w momencie, gdy chciałbym przeczytać więcej informacji. Miganie jest też nieprzyjemne dla oka i ściąga uwagę, co w dużym ekranie nie stanowi takiego problemu, bo podczas odświeżania miga zaledwie dwa razy, a cały proces trwa jakieś 3-4 sekundy.
• Raspberry Pi Zero jest rewelacyjne dla takich projektów! Okazuje się też, że można skonfigurować je bez podłączania wyświetlacza i klawiatury, co jest o tyle wygodne, że Zero posiada mało popularny i wymagający zwykle przejściówki port Micro HDMI.
• Warto skonfigurować system plików na Raspberry w trybie tylko do odczytu - dzięki temu oszczędzamy żywotność karty SD i możemy wyłączać całe urządzenie po prostu przez odłączenie zasilania, nie ryzykując uszkodzenia systemu operacyjnego (bo i tak nie może nic zapisywać na karcie).
• Tym razem już nie popełniłem tego błędu, ale warto pamiętać, żeby projektowaną obudowę zawsze środkować do rozmiaru aktywnego obszaru ekranu, a nie rozmiaru całego ekranu. Większość z nich jest niesymetryczna, to znaczy płytka z ekranem (albo sam ekran) jest z jednej lub kilku stron szerszy niż w pozostałych. W przypadku tego konkretnego ekranu prawa krawędź (ta, z której wyprowadzona jest taśma) jest kilkukrotnie szersza niż pozostałe.

Edytowano Grudzień 20, 2020 przez spook

[Leander 54]

Ładnie to wygląda! Bardzo estetyczna obudowa i naprawdę fajne meteorogramy. A dlaczego rysowane "własnoręcznie", jakieś gotowe rozwiązania (zakładam, że są) się nie sprawdzają? Kończę remont ganku i ogólnie to marzy mi się, żeby wyrzeźbić coś takiego, łącząc prognozy z sieci z bieżącym odczytem (i ich historią) charakterystyk przez czujnik. Wracam do programowania (po latach), chcę poznać Pythona, bo jest dla mnie przydatny, a na czym się lepiej uczyć, jak nie na hobbystycznej dłubaninie (tak się kiedyś właśnie za naukę programowania zabierałem).

[spook 92]

Większość czcionek typu TrueType jest przygotowanych pod ekrany obsługujące antyaliasing. Zrób zrzut ekranu dowolnego tekstu i powiększ go mocno w dowolnym edytorze grafiki, to będziesz wiedział, o co chodzi.

Monochromatyczne ekrany typu e-paper nie obsługują antyaliasingu, ponieważ nie są w stanie (z definicji) wyświetlić pikseli w odcieniach szarości. Dlatego czcionki wyświetlane standardowymi mechanizmami wyglądają często bardzo nienaturalnie.

Przygotowałem własny mechanizm renderowania czcionek - najpierw trzeba przygotować czcionkę w moim programiku (wygenerować na podstawie czcionki, a potem ręcznie poprawić), wyeksportować ją jako dane binarne do skryptu pythonowego, a potem użyć przygotowanych przeze mnie skryptów do renderowania.

Dla przykładu: u góry czcionka wyrenderowana moim mechanizmem, na dole - mechanizmem standardowym (PIL / ImageFont, ImageDraw):

Ciągle zbieram się do wrzucanie programiku na moją stronę, ale nie mogę znaleźć czasu  Może po Świętach, jak już wrócę do domu, to ogarnę temat.

Zastanawiałem się też nad dodaniem zwykłego czujnika, tylko muszę znaleźć jakiś dobry. Najbardziej lubiłem BME280 Boscha (temperatura/ciśnienie/wilgotność), ale niestety ma ten problem, że się grzeje i zafałszowuje z czasem odczyty. Zaletą mojego rozwiązania jest prostota dodania czujnika, bo na pokładzie mam płytkę uniwersalną - wystarczy więc tylko dolutować kilka przewodzików, wyprowadzić piny i przygotować miejsce w obudowie na czujnik. Tylko będę wtedy musiał drukować całą spodnią część od nowa, a to jest 17 godzin wydruku

Python wprawdzie jest językiem stosunkowo wolnym, ale jego ogromnymi zaletami jest mnogość bibliotek i ogromna łatwość realizowania wielu czynności. Na przykład w mojej stacji informacyjnej wyświetlam RSSy z wielu stron - pobranie RSSa do obiektu Pythonowego przy pomocy odpowiedniej biblioteki to kwestia jednej (słownie) linijki kodu. Do projektów, które nie wymagają wysokiej wydajności w tej chwili to jest mój wybór numer jeden

Zachęcam do zapoznania się z kodem mojego projektu - wstaje normalnie na komputerze. W środku zawarłem prosty mechanizm detekcji, jeżeli systemem jest Windows (w sensie: nie POSIX), to obraz renderowany jest do pliku. Jeżeli Raspberry, to wtedy obraz wyświetlany jest na e-papierze. Będziesz tylko musiał uzupełnić klucz API do OpenWeatherMap i wprowadzić odpowiednie współrzędne geograficzne. Teoretycznie mogłem się pobawić w rozpoznawanie ich, ale skoro prognoza wisi w domu na ścianie, to trochę nie miało to sensu.

Pozdrawiam -- Spook.

[Marooned 204]

Rozumiem, że gotowe fonty przygotowane pod e-ink też się nie sprawdziły?
https://the-digital-reader.com/2016/04/30/how-to-find-free-and-open-source-fonts-for-e-ink-screens/

Projekt ładnie wygląda, choć nie wiem, czy boskie otoczenie nie wpłynie na odczyt pogody

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[ethanak 2 937]

29 minut temu, spook napisał:

Większość czcionek typu TrueType jest przygotowanych pod ekrany obsługujące antyaliasing.

Dlatego zastanawiam się, dlaczego użyłeś czcionek TT a nie bitmapowych.

[spook 92]

22 minuty temu, ethanak napisał:

Dlatego zastanawiam się, dlaczego użyłeś czcionek TT a nie bitmapowych.

Tak naprawdę użyłem bitmapowych, tyle że własnej produkcji

Pozdrawiam -- Spook.

[ethanak 2 937]

8 minut temu, spook napisał:

Tak naprawdę użyłem bitmapowych, tyle że własnej produkcji

No właśnie - kolejny raz wynalazłeś koło... a całkiem sensowne czcionki bitmapowe siedzą sobie choćby w pakiecie xfonts-misc i to w formacie strawnym dla pilfont.py.

[spook 92]

Przed chwilą, ethanak napisał:

No właśnie - kolejny raz wynalazłeś koło... a całkiem sensowne czcionki bitmapowe siedzą sobie choćby w pakiecie xfonts-misc i to w formacie strawnym dla pilfont.py.

Trochę tak, a trochę nie. Mój edytor czcionek powstał w pierwotnej wersji do generowania czcionek w formacie ILI9341-t3 dla Teensy. Napisałem go jednak dosyć modularnie, więc wystarczyło dodać tylko eksport do odpowiedniego formatu. W ten sposób niewielkim kosztem mogłem skorzystać z dowolnych czcionek TTF, robiąc tylko trochę niewielkich, ręcznych korekt.

Ostatnio na przykład jestem sporym fanem czcionki Saira Condensed i mogłem tym sposobem użyć jej w moim projekcie, bez konieczności poświęcenia jakości wynikowego obrazu.

[Leander 54]

2 godziny temu, spook napisał:

Zrób zrzut ekranu dowolnego tekstu i powiększ go mocno w dowolnym edytorze grafiki, to będziesz wiedział, o co chodzi.

Ja o wykresy pytałem, bo o nich też napisałeś, że są rysowane własnoręcznie. O czcionkach mam całkiem spore pojęcie w różnych ich aspektach ;).

A jeśli o czujnik chodzi, to właśnie te trzy parametry (temperatura, ciśnienie, wilgotność) chciałbym zapisywać.

Edytowano Grudzień 22, 2020 przez Leander

[spook 92]

Tu miałem mniejszą ochotę wynajdywać koło na nowo, ale nie mogłem jak na złość znaleźć biblioteki, która jest w stanie wyrenderować wykres na zadanym obszarze już istniejącego obrazka (w sensie, w pamięci). Jedyną opcją było renderowanie do pliku, ale tego chciałem uniknąć, bo docelowo będę przerabiał obie Raspberki na system plików R/O, a poza tym sytuacja, w której dwie części programu komunikują się ze sobą przez pliki jes taka bardzo '70. Więc już wolałem napisać własny mechanizm, bo pisałem już takich setki i nie było to jakieś wielkie wyzwanie (a poza tym mogłem wprowadzić np. ditherowane wypełnienie histogramu - nie wiem, czy bardziej standardowe biblioteki na to pozwalają). Co więcej ta moja mini-biblioteka jest też przygotowana np. na renderowanie do osobnych obrazków w przypadku ekranu czerwono-czarnego. To potem mocno ułatwia wypluwanie tego na e-papier.

Ale jeżeli znasz jakąś bibliotekę, która spełnia powyższe warunki, to chętnie zobaczyłbym jakiś przykład, bo w przeciwieństwie do czcionek, wykresy wymagały już nietrywialnego wkładu z mojej strony

[ethanak 2 937]

13 godzin temu, spook napisał:

Mój edytor czcionek powstał w pierwotnej wersji do generowania czcionek w formacie ILI9341-t3 dla Teensy.

A, to zwracam honor.

2 godziny temu, spook napisał:

Jedyną opcją było renderowanie do pliku, ale tego chciałem uniknąć, bo docelowo będę przerabiał obie Raspberki na system plików R/O

/dev/shm też będzie ro?

Poza tym nie wiem jakie wykresy masz tam jeszcze oprócz tych na zdjęciach, ale sprowadzają się w praktyce do funkcji typu writePixel oraz siedzącej nad nią drawLine i drawVLine z parametrem pattern (zakładam że nie robisz Floyda-Steinberga tylko po prostu rysujesz co drugi piksel). Nie wiem jak to jest przyjęte u współczesnej "młodzieży", ale ja tam bym napisaniem writePixel i drawLine się nie chwalił

3 godziny temu, spook napisał:

sytuacja, w której dwie części programu komunikują się ze sobą przez pliki jes taka bardzo '70

E tam - jak coś jest zrobione i działa to czemu tego nie użyć? Syntezator formantowy też pochodzi z lat 70-tych a we współczesnych programach znajdziesz fragmenty oryginalnego kodu Klatta z 1980 (tzn. jego najnowszej wersji).

[enikan 44]

Mam pytanie, ale jak coś, to prosił bym bardzo prostym językiem,
bo niewiele ogarniam, nawet nie posiadam jeszcze żadnego Raspberry...
Ile dni (mniej więcej) mogłoby takie coś działać na akumulatorze?
Gdzieś kiedyś widziałem rozszerzenia nazwane "RPi PowerPack 5000mAh".
Jest sens nad tym rozmyślać, czy raczej bez kabla nie ma szans?

A tak z innej beczki, to gratuluję pomysłu i sukcesu w wykonaniu...
Widziałem też posty TPInka. Kreatywności Wam Panowie nie brakuje...
Rzadko widzę, aby ktoś używał drukarki 3D do czegoś użytecznego,
wszyscy moi znajomi drukują tylko jakiś szajs z internetowych gotowców...

[spook 92]

Tak naprawdę trudno ocenić, bo to zależy np. od rodzaju akumulatora. E-papier jest bardzo oszczędny jeśli chodzi o energię elektryczną, ale Raspberry to mały komputerek i trochę prądu będzie siorbał nawet wtedy, gdy nie będzie nic robił - w końcu na pokładzie jest pełnoprawny Linux.

Ogólnie nie rozważałem nawet użycia akumulatora, bo wbrew pozorom powodowałoby to chyba więcej problemów niż pożytku. Akumulator tak czy kwak trzeba ładować co jakiś czas, więc trzeba byłoby co jakiś czas podłączać kabel. Ja mam wpięte urządzenie w gniazdko i nie muszę się za bardzo niczym przejmować.

Ogólnie akumulator stosowałbym tylko wówczas, gdy miałoby to być rozwiązanie mobilne lub stosowane w miejscu, gdzie trudno o zasilanie sieciowe. W domu korzystam po prostu z możliwości podłączenia się do sieci (korzystam z nieużywanej ładowarki do telefonu - mam ich już chyba z sześć).

 

[enikan 44]

Dzięki za wyjaśnienie.

Tak sobie tylko rozmyślam o zapotrzebowaniu Raspberry na prąd.
(...nawet nie wiedziałem, że normalnego Linuxa się tam wgrywa, myślałem że jakąś okrojoną wersję...)
Wyobraziłem sobie korytarz w moim obecnym mieszkaniu, gdzie pasowałoby takie coś postawić/powiesić,
tylko ze w korytarzu jest wyłącznie jedno gniazdo i to z dala od szafek.
Do tego gniazdko jest w takim miejscu, że przechodząc ciągle bym wadził o ładowarkę.
No i po takich wyobrażeniach zacząłem właśnie rozmyślać o akumulatorach...

Może jeszcze gdzieś trafię na jakieś wyliczenia, co do akumulatorów w Raspberry..

[Treker 3 076]

@enikan pytanie też czy na pewno potrzebujesz tam RPi. Może wystarczy ESP, które będzie zaciągało dane z sieci? Wtedy Zapotrzebowanie na prąd będzie znacznie, znacznie niższe