TPInk - stacja pogodowa z e-papierem

[TPReal]

Dawno już miałem ochotę skombinować sobie stację pogodową i powiesić na ścianie jakiś estetyczny ekran pokazujący jak to tam jest za oknem. Myślałem żeby coś takiego kupić, ale w końcu zbudowałem sam - a w każdym razie ekran, bo prezentowane dane pochodzą z serwisu pogodowego, a nie z mierników. Jest to mój pierwszy projekt elektroniczny.

Od razu wyjaśnię, że ikony pogody oraz biedronka i grzybek to rysunki mojej pięcioletniej córki 🙂

Hardware

Wszystko oparte jest na Raspberry Pi Zero W, ekran wybrałem Waveshare trójkolorowy 7.5", z modułem HAT dla Raspberry Pi. Natomiast żona dała mi wyraźnie do zrozumienia, że jeśli to ma wisieć na ścianie w salonie czy w korytarzu, to ma być ładne, więc zbudowałem z listewek drewnianych ramkę (wiem że jest trochę krzywo na łączeniach, ja naprawdę się starałem), a następnie stwierdziłem, że jeśli nałożę tego HATa na Pi, to całość jest o ładnych kilka milimetrów za gruba żeby się zmieścić pod ekranem...  więc pozostało mi łączenie przewodami pojedynczych nóżek. Moduł HAT ma też połączenie uniwersalne, i dołączony był przewód ośmiożyłowy.

Ekran ma dość krótką taśmę, w zestawie była też przedłużka ale postanowiłem podłączyć moduł do tej taśmy bezpośrednio z myślą że przecież tam w środku jest nadal masa miejsca na moje Pi. No cóż, okazało się to nie takie proste, i ostatecznie Pi jest tak trochę po skosie, utrzymywany na miejscu przez swój kabel zasilający oraz drut łączący go z wiązką przewodów. Tego się nie da opisać, to trzeba zobaczyć, więc załączam zdjęcia. Na szczęście wszystko to jest całkowicie schowane, bo ramka tyłem przylega do ściany. Grubość ramki to 2cm, przestrzeń na elektronikę ma około 1.5cm.

(Jeżeli ktoś się zastanawia czemu wszystkie piny Pi są ubabrane cyną, no cóż, to smutna historia. Najpierw własnoręcznie wlutowałem tam złącze czterdziestopinowe (i byłem z siebie bardzo zadowolony, bo nigdy wcześniej czegoś takiego nie lutowałem, a do tego użyłem lutownicy transformatorowej i nic się od tego nie uszkodziło), a dopiero później zbudowałem ramkę, która okazała się za mała, więc je całe wylutowałem wyrywając po jednej nóżce. Nadal transformatorem, i nadal nic się nie uszkodziło, więc właściwie to nadal jestem z siebie zadowolony.)

W ostatecznej wersji szczelina na dole, którą wsuwany był ekran, zaklejona jest plasteliną. Plastelina jest też użyta do uszczelnienia ekranu, tak żeby nie miał luzu.

Software

Oprogramowanie napisane jest całkowicie w języku Ruby, i składa się z następujących części:

• Dane pobierane są co około 10 minut:
  • Dane o pogodzie pobierane są z openweathermap.com. Darmowy dostęp do API pozwala pobrać prognozę godzinną na 48h oraz dzienną na parę dni, no i sporo parametrów aktualnej pogody, które prawie wszystkie wyświetlam.
  • Dane do kalendarza pobierane są przez protokół ICAL z Kalendarza Google, opis wydarzeń wskazuje na typ, różne typy są różnie oznaczone w kalendarzu (kreskowane linie nad datami albo kropki, czarne lub czerwone).
  • Dodatkowo pobieram informacje o świętach z calendarific. Te dane są cache'owane bo świąt narodowych raczej nie dodają co 10 minut i nie ma sensu tak męczyć tego API.
• Pobrane dane są porównane z poprzednimi danymi. Jeżeli nie zmienił się żaden istotny parametr to nie ma sensu nic przerysowywać, zwłaszcza że ekran nie ma częściowego przerysowania, tylko cały migocze jak szalony przez kilkanaście sekund. Natomiast jeśli różni się na przykład aktualna ikona pogody czy temperatura, albo to, czy ma za dwie godziny padać, to przerysowuję od razu. Przerysowuję też co najmniej raz na godzinę, żeby zaktualizować wykres.
• Następnie z danych składam (z użyciem własnej bardzo prostej biblioteki) definicję SVG przedstawiającego cały ekran. Potem używam imagemagick żeby odczytać piksele z tego obrazu.
• Piksele mapuję na dostępne w ekranie kolory (biały, czarny, szary (tylko jeden) i czerwony), i wysyłam do własnej biblioteki, która montuje bufor w formacie akceptowanym przez ekran.
• Wysyłam zawartość do ekranu przez SPI. Korzystam przy tym z biblioteki Mike'a McCauley'a, której używam z Rubiego przez FFI.

Oprogramowanie ma sporą ilość konfigurowalnych parametrów, takich jak liczba godzin do pokazania na wykresie, gęstość siatki, liczba tygodni w kalendarzu, dane do "galerii" po prawej na dole. Wszystko to, razem z takimi danymi jak na przykład klucze API albo lokalizacja dla której ma być sprawdzana pogoda, siedzi w pliku konfiguracyjnym lokalnie na Pi, albo przez HTTP (co pozwala łatwo zmieniać konfigurację bez logowania się do Pi).

Używam gita, edytuję kod na innej maszynie niż ten Pi w ekranie, testuję kod uruchamiając go z parametrami, które powodują wygenerowanie PNG zamiast wysyłania obrazu na fizyczny ekran. Gdy zrobię zmianę, pushuję ją, a potem jedną komendą ustawiam flagę update-code w serwisie na zewnętrznym serwerze (nie będę tu opisywał ze szczegółami). Gdy serwis działający na ekranie następnym razem będzie odświeżać dane i zobaczy flagę update-code, to najpierw zrobi git pull i się zrestartuje. Dzięki temu nie potrzebuję łączyć się bezpośrednio z Pi w ekranie żeby wgrać mu aktualizację kodu.

Potencjalny dalszy rozwój

Projekt jest zakończony, wisi na ścianie już 4 miesiące i jestem z niego bardzo zadowolony. W międzyczasie dodawałem tylko różne drobne usprawnienia (na przykład dodawałem godziny wschodu i zachodu słońca, a ledwie wczoraj naprawiałem małego buga, który się ujawnił przy zmianie czasu). Natomiast jest możliwe parę większych usprawnień, które może kiedyś zrobię, a może nie.

• Pobieranie prognozy pogody z innego serwisu, na przykład yr.no. Czasami wydawało mi się, że jest bardziej trafna, chociaż bywało też odwrotnie. Natomiast zawiera mniej parametrów, więc raczej łączyłbym prognozę z dwóch źródeł. No i podaje temperaturę bez części ułamkowych, i musiałbym zaimplementować wygładzanie wykresu.
• Pobieranie informacji o aktualnej pogodzie z jakichś fizycznych czujników.
• Dołączenie informacji o aktualnych parametrach wewnątrz pomieszczenia, na przykład temperaturze i wilgotności. Do tego prawdopodobnie zbudowałbym osobne urządzenie oparte na Pi, które takie dane mierzy i wystawia w jakiś sposób, a ramka by je tylko pobierała.

[Treker (Damian Szymański)]

@TPReal dzięki za opis kolejnego ciekawego projektu - bardzo ładnie wygląda gotowa ramka na ścianie 🙂 Właśnie zatwierdziłem Twój projekt, więc jest już widoczny publicznie.

[ethanak]

Bardzo ładne (sam robię pogodynkę, więc wszystko w tym temacie mi się podoba). Pytanie tylko: po co pobierasz dane o świętach z jakiegoś obcego serwera? Moim zdaniem dużo prościej jest to wbudować w program (tablica świąt stałych z rozróżnieniem czy to dzień wolny od pracy oraz tablica dat Wielkanocy na najbliższe ileś tam lat).

[TPReal]

@ethanak Najpierw myślałem stablicować święta, ale ja po prostu lubię jak rzeczy działają automatycznie 🙂 I tak już miałem kod do pobierania JSONa (do pogody), calendarific jest darmowe, więc to nie był żaden problem pobierać stamtąd. Poza tym w ten sposób w konfiguracji podaję kraj dla którego chcę święta, i gotowe. Gdybym się kiedyś przeprowadził do innego kraju to wystarczy zmienić w konfiguracji lokalizację do pogody i właśnie kraj do świąt 🙂 bez zmian w repo.

No albo gdyby ktoś gdzieś chciał zbudować sobie taką samą ramkę z mojego kodu... ale to się nie wydarzy, bo kod nawet nie jest obecnie publiczny.

Edytowano Październik 27, 2020 przez TPReal

[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

[KHX]

Projekt bardzo fajny. Pierwszy raz w praktyce widzę papierowy wyświetlacz. Dużo za niego dałeś? 

[TPReal]

@KHX To był ten, już niedostępny, ale cena 319zł, i tak jakoś podobnie dałem. Te najmniejsze (z modułem) są poniżej stówy: sklep.

[Gieneq]

@TPReal Wow genialny projekt 😮 mnie to zawsze jarają takie ramki, sam się wiele razy przymierzałem do zrobienia jakiegoś zegara zintegrowanego z jakimś API, Slackiem, whatsupem czy czymś ale wyszło jak wyszło...

Orientujesz się czy da się zastosować wyświetlacz z demontażu np. ze starego kindla?

[TPReal]

@Gieneq Dzięki.

Nie mam pojęcia, ale podejrzewam że trudno będzie znaleźć dokumentację do takiego wymontowanego ekranu niewiadomej marki. Ale pewnie można popróbować.

[ewraw]

Super projekt!

Mógłbyś opisać w jaki sposób uzyskujesz szary kolor na wyświetlaczu? W dokumentacji trójkolorowego ekranu znalazłem tylko funkcję do wysyłania czarnego i czerwonego obrazu:

void EPD_xxx_Display(const UBYTE *blackimage, const UBYTE *ryimage);

[TPReal]

@ewraw Dzięki 🙂

Ten konkretnie ekran to przestarzały model, już nie sprzedawany, a niestety w każdym modelu mnóstwo rzeczy jest inaczej. Postudiowałem trochę datasheety kilku modeli Waveshare i wyglądają jakby je w dużej mierze robiły zupełnie osobne zespoły. Niektóre mają osobny bufor na obraz czarny a osobny na czerwony, a inne mają jeden bufor, 3 bity na piksel, i w tym każdy kolor ma inny kod, ale żaden z tych bitów nie steruje bezpośrednio czerwonym. Poza tym jest coś co się nazywa LUT, to jest dokładna instrukcja dla ekranu jak ma migać napięciami w ekranie żeby ustawić piksel na określony kolor. Niektóre ekrany mają osobną sekwencję LUT na kolor czarny, biały, szary i czerwony, a inne pamiętają co wyświetlały poprzednio i mają osobną sekwencję LUT na przejście czarny->biały, czarny->szary itd. Niektóre ekrany mają w sterowniku zapisane sekwencje LUT, a innym trzeba po załączeniu je przesłać, wtedy cała sekwencja (kilkadziesiąt bajtów) jest po prostu zapisana w datasheecie i trzeba ją wysłać po SPI. Widziałem że niektórzy też dali radę pohackować trochę, i podmieniali LUT na własny, dzięki czemu ekran smużył, ale na przykład odświeżał się w pół sekundy zamiast 15 sekund. A na koniec warto też pamiętać, że w tych datasheetach jest masa błędów.

Przechodząc do rzeczy, w załączniku wrzucam datasheet tego konkretnego ekranu, który miałem, i na stronie 14 jest opisany format bufora. Są trzy bity na piksel i opisane są tam 2 kolory szare i 4 czerwone. To nie jest prawda, nie wiem dlaczego ale trzy z tych czerwonych są identyczne jak szary, czarny i biały, natomiast te dwa szare są identyczne ze sobą. Prawdopodobnie jest tak po prostu dlatego, że wgrany w sterownik LUT dla tych sekwencji tak wygląda, jest na przykład identyczny dla tych dwóch szarych. A jako że nie znalazłem nigdzie pasującego opisu samego formatu LUT, nie umiem tego zmienić, chociaż na pewno się da (bo ten ekran ma w sterowniku zapisany LUT, ale można też wgrać własny).

W każdym razie nie korzystałem z żadnej gotowej biblioteki do tego ekranu tylko napisałem swoją na podstawie datasheeta oraz czytania masy różnego kodu, i wtedy szary uzyskuje się dość łatwo. To jest ten szary którym wyświetlam pasy pokazujące gdzie jest noc na wykresie. Ale zrobiłem też sobie inny szary, użyty na przykład do narysowania przeszłej części wykresu, który jest po prostu szachownicą pikseli czarnych i szarych.

Repozytorium demo, z którego najbardziej korzystałem, jest tutaj, nie jestem teraz pewien który to był z tych "7in5", ale to da się wywnioskować po rozdzielczości. Jest tam też kod w Pythonie, ale... różni się pewnymi szczegółami.

Natomiast ta funkcja EPD_xxx_Display być może akceptuje jakieś odcienie szarości, bo w tym buforze może być więcej niż jeden bit na piksel. Wszystko zależy od ekranu 🙂

7.5inch_e-paper-b-Specification.pdf

[ewraw]

@TPReal dzięki za odpowiedź, sporo wyjaśnia, a jeszcze więcej komplikuje 😉

Ekran zamówiony, jak tylko dotrze to biorę się za testy

[piotr-jarosz]

Wow, to jest wspaniałe. 
Zamawiam ekran i RPI Zero. A zanim przyjdzie.. Widział ktoś, jakiś emulator e-INK po SPI? zwirtualizowałbym to z chęcią i zaczął pisać widok :)
A może @TPReal, udostępniasz kod źródłowy na GitHubie? :) z chęcią bym podejrzał.
 

[Treker (Damian Szymański)]

@piotr-jarosz witam na forum 🙂 

Dnia 3.11.2020 o 10:25, piotr-jarosz napisał:

Widział ktoś, jakiś emulator e-INK po SPI? zwirtualizowałbym to z chęcią i zaczął pisać widok 🙂

Raczej nie znajdziesz tego typu rozwiązania - zdecydowanie szybciej przyjdzie paczka z zamówionymi częściami 😉

[TPReal]

@piotr-jarosz 

Hej, dzięki!

Tak jak napisałem, ja składam obrazek tekstowo w SVG, potem wyciągam piksele przez imagemagick. Zamiast tego można skonwertować ten SVG na PNG i podejrzeć, ja to sobie tak emulowałem. Nie radzę podgladać SVG bezpośrednio bo imagemagick ma trochę biedny ten renderer i można się potem zdziwić że inaczej wychodzi.

Co do kodu... chyba nie jestem jeszcze gotowy na to, żeby ktoś go oglądał 🙂

[piotr-jarosz]

7 godzin temu, Treker napisał:

@piotr-jarosz witam na forum 🙂 

Raczej nie znajdziesz tego typu rozwiązania - zdecydowanie szybciej przyjdzie paczka z zamówionymi częściami 😉

@treker

A tak, witam 🙂

Ale z tego co patrzę na samą specyfikę SPI i e-INK, to nie będzie trudne do zasymulowania, postaram się w tygodniu znaleźć czas i zobaczymy co uda się wyrzeźbić 🙂
Już nawet nie chodzi o ten jeden projekt - przyszłościowo, w przypadku innych narzędzi, moim zdaniem wygodniej prototypować na zwirtualizowanym e-papierze niż na fizycznym nośniku 🙂

@TPReal Rozumiem Twoje obawy przed publikacją kodu 🙂 miałem takie same przed pierwszym lockdownem, kiedy zacząłem pisać swoje side projekty - po publikacji pierwszego i wyszerowaniu do kilku kolegów, żeby mogli ocenić, pomóc znaleźć błędy, publikowanie stało się łatwiejsze 🙂 polecam, bardzo dużo kontruktywnej krytyki można zgarnąć 🙂