Elektronisches Preisschild Sammelbestellung - Ansteuerung

[Bastelbruder]

Diagonal verzerrt

Sieht das so aus wie auf der Deppenlampe ohne Zeilensynchronisation?
Dann tippe ich auf falsche Anzahl Pixel in X-Richtung. Das kann durchaus zu leeren Bildern führen, es ist aber nicht auszuschließen daß die Y-Größe dann auch nicht stimmt.

[T5000]

Ich hab mal eines meiner Testbilder angehängt.
Die Pixelmaße sind 296x146

000002838f9c3b12.png (2.23 KiB) 1145 mal betrachtet

Mit dem alten Script gehts, mit dem neuen nicht.
Auch eine abschneiden von jeweils 10 Pixel in Länge und Breite bringt leider keine Besserung.

Nachtrag:

wenn ich in den /tmp Ordner schaue, stelle ich fest, das die Bilder nicht korrekt konvertiert werden. TempConvert.bmp lässt sich meist noch mit einem Bildbetrachter anzeigen. Die anderen erzeugten Bilder die "000002838CCA3B12_7176246181206894028.bmp" oder ähnlich heißen lassen sich nicht öffnen. Die mit der alten Station.py erzeugten Bilder "7176216331184172200.bmp" hingegen schon.

[berferd]

Mal eine grundlegende Frage... ich überlege grade wie ich das Ding möglichst einfach & energiesparend dauerhaft betreibe.
Ich habe hier keinen extra Router, Pi o.ä. der "ohnehin immer läuft" und den ich als Server nutzen könnte. Alle meine Geräte (Desktop, Laptop) schalte ich bei Nichtgebrauch aus oder in den Ruhemodus.
Ich würde gerne vermeiden, extra einen Pi o.ä. hinzustellen, der dann 24/7 die nächsten Jahre nur dafür durchläuft und rund um die Uhr 3-5 Watt schlürft.
Also, was nimmt man als minimalistische Plattform? "alles selber entwerfen und bauen" scheidet aus.
Idealerweise sollte das Ding Zigbee (natürlich) können, und Ethernet und/oder Wifi (vermutlich ersteres stromsparender), und man sollte selber einfache eigene Programme drauf starten können (Programmiersprache egal. Meinetwegen auch nur Shell und compiliertes C.).

[Lokaro]

Die bilder werden in 296x128 erwartet und müssen auch so vorliegen

Die Pixelmaße sind 296x146

Und zum nachtrag, durch das ROT in den Bildern werden sie in ein altes BMP format konvertiert was so gut wie keine software mehr unterstützt, die firmware im display aber schon.

[Lokaro]

@berferd

Du könntest eine Station auch nur für ca. 20 Minuten starten um die Displays upzudaten und den rest des Tages aus. Die Displays suchen alle 15 Minuten nach der Station.

Es gibt auch eine ESP32 Station, dadurch läuft alles auf diesem.

Als Zigbee transceiver wird eine Display Platine genommen und mit einer eigenen firmware als Access Point genutzt, diese flasht der ESP32 selber

Die software funktioniert ist aber noch im beta status.

Das Repo ist hier:
https://github.com/jjwbruijn/ESP32-epaper-station

[Später Gast]

An dem Energieverbrauch denk ich auch grad rum. Muss grad primär eine Wohnung neu beleuchten und da wird wohl zigbee zum Einsatz kommen. Esp32 kann das auch, wenn man sich also als gateway nen esp hernimmt, passt das da vllt grad auch noch drauf.

Wenn man die Informationsbeschaffung der Displays irgendwie extern takten könnte, kann der Esp in der Zwischenzeit auch aus sein. Alle gleichzeitig anschalten führt nach längerer Betriebszeit bestimmt zu Phasenverschiebungen und damit Ausfällen.

Fritzboxen können ja nebenher teils auch schon smart Kram, leider nur sehr eingeschränkt und selber sachen dazupatchen ist eher nicht, oder gibts Freetz noch? Router mit OpenWRT?

[Hightech]

Mein Plan ist, ein 2x3 Displaymatrix auf dem ich meine Daten darstelle.
Die Display kann man parallel an einen Akku klemmen und über eine ttl- Daisychain hintereinander schalten und mit einem nem ESP32 mit Daten füttern.
Die Funkdaten laufen dann nur über den ESP.
Wlan halt dann.

[T5000]

Danke für den Tipp mit der richtigen Auflösung, ich weis auch nicht mehr wo ich meine falschen Werte her hatte.

Display1 : altes station.py Script - Bild in Graustufen ohne rot im PNG
Display2 : neues station.py Script - gleiches Bild wie Display1 -> die Graustufen fehlen, Mario hat keine Hände usw
Display3 : neues station.py Script - Bild mit rot im PNG

Die Graustufen fehlen halt im neuen Script. Wird sicherlich an dem ungewöhnlichen BMP Format liegen.
Ideal wäre natürlich, wenn das Script erkennt, das es ein Graustufen PNG ist und es dann in das modernere BMP wandelt.

Ich bin erstmal froh, das ich überhaupt soweit gekommen bin, inkl. C2531 Flashen usw.

[Teslafreak]

Diese Ständer kann man für die Displays wunderbar zweckentfremden: https://www.thingiverse.com/thing:5422488

[nero]

kwh.png (4.88 KiB) 889 mal betrachtet

Mhhhhahprprhrhprrr

[xanakind]

Was genau möchtest du uns denn mit diesem Post sagen?
Bitte schreibe doch einen vollständigen Satz in einer Sprache, welche wir lesen können.

[ferdimh]

Es wird eindeutig die Änderungsrate der eingespeisten Leistung in Kilowatt pro Stunde angezeigt...

[Fritzler]

Kontext Mädels!
Es geht um die ausgefransten Buchstaben durch Subpixelrendering umgemappt auf 1bit Graustufen Epaper und die immernoch fehlende Lösung dazu.

[MSG]

Aber gab es nicht früher (tm) Schriften extra für den Bildschirm? Da war doch das gleiche Problem, bis die grafischen OS die Druckerschriften entsprechend rendern konnten.

Evtl wäre das ein Ansatzpunkt?

Die Adafruit Grafikbibliotheken haben soweit mir dünkt auch spezielle Schriften für die kleinen Grafik Panels.

[Hightech]

Ich hab was in Python gebastelt mit Skalierung und min/Max.
Klappt leider noch nicht 100 bei negativen Zahlen kackts ab

[Flip]

Ich bin ja in meinem Gesamten System auf der Variante ESP32-gateway-Station. Die Sendezeit ist ja durchaus begrenzt, wenn man den Äther nicht verstopft haben will.
Mich stört es etwas, immer die pixelgrafik zu übertragen, auch wenn komprimiert, hat man da doch erheblich mehr daten, als wenn man Schrift und grafik auf dem Display rechnet. Selbst mit 1MHz kerntakt dürfte das fixer gehen als das rüberschieben der grafik.


Ich denke erstmal effizienzverliebt an Protobuf-codierte Zeichenbefehle. 1 byte Typ und Farbe, 2 Byte Position und Größe, dann ggf für Text oder Kurven noch ein Datenstring Fällt da jemandem noch etwas ein, was besser für differentielle screen-updates geht?

[Hightech]

So, nun
Hier 6 Display uarts in Reihe an einem ESP32

Der holt sich die Daten direkt aus der InfluxDB und geht dann schlafen, nachdem er den Strom für die Displays aus gemacht hat.

[berferd]

Hat jemand zufällig einige Adapterplatinen (so wie hier beschrieben https://www.pcbway.com/project/sharepro ... a845c.html) über?
Dann muss ich nicht extra nur für meine 5 Stück welche fertigen lassen....

[ProgBernie]

Ich bin ja in meinem Gesamten System auf der Variante ESP32-gateway-Station. Die Sendezeit ist ja durchaus begrenzt, wenn man den Äther nicht verstopft haben will.
Mich stört es etwas, immer die pixelgrafik zu übertragen, auch wenn komprimiert, hat man da doch erheblich mehr daten, als wenn man Schrift und grafik auf dem Display rechnet. Selbst mit 1MHz kerntakt dürfte das fixer gehen als das rüberschieben der grafik.


Ich denke erstmal effizienzverliebt an Protobuf-codierte Zeichenbefehle. 1 byte Typ und Farbe, 2 Byte Position und Größe, dann ggf für Text oder Kurven noch ein Datenstring Fällt da jemandem noch etwas ein, was besser für differentielle screen-updates geht?

Es wäre ja schon viel gewonnen, wenn nicht dieses dusselige unkomprimierte BMP-Format benutzt würde. Das sind auch für ein komplett einfarbiges Schild aktuell 9542 Byte. Als GIF sind das meist deutlich weniger Byte, bei meinen Wetterbildern etwa 2200, als PNG noch darunter 1800 Byte. Ein einfarbiges Bild sind als PNG nur noch 159 Byte.

[Lokaro]

Eine komprimierung ist in arbeit

Bei den großen ist nun Gzip implementiert und funktioniert sehr gut. Leider haben die ZBS243 aber zu wenig RAM um das dort zu implementieren.
https://youtu.be/kPy8rIQ75NU

[Bastelbruder]

Ich bin jetzt nicht der Spezialist in Bilddatenformaten, aber ich war bei der Prüfung der Kinderschuhe der elektronischen Bildverarbeitung mit dabei. Viele der heute völlig unnötig mitgeschleppten Begleitdaten fressen bei so kleinen Bildern den Gewinn auf.

Da sollte man wirklch mal die Statis-Tiger dranlassen, sehr wahrscheinlich bringt eine primitivste Lauflängencodierung die höchste Ersparnis, natürlich abhängig vom Bildinhalt - ein unregelmäßiges Raster ist die Höchststrafe.
Ich hab eben geschwind mit IrfanView eine aus dem Leben gegriffene SW-Grafik (296 x 128 Pixel, bmp: 5182 Bytes) durchprobiert, da hat (tif) CCITT Fax 4 mit 1416 Bytes gegenüber allen anderen Algorithmen die Nase weit vorn. png belegt mit 2120 Bytes den zweiten Platz und huffmann kommt noch vor gif.

Schalter aus dem Watkins-Johnson

bitmaps.png (6.05 KiB) 322 mal betrachtet

Alle weiter oben gesehenen Musterdisplays lassen sich natürlich viel effektiver komprimieren, für Wetterbilder dürfte Fax 4 der Spitzenreiter sein.

Ein einzelner Pixel in der Bildmitte wird in (tif) CCITT Fax 4 mit ganzen 254 Bytes dargestellt, Fax3: 666, huffmann 510, gif 295, png kommt auf Platz 1 mit 144 Bytes.

Bei der Gelegenheit (habt Ihr im IrfanView schonmal die Taste [F3] benutzt?) fällt auf daß die populären Formate natürlich auch Format, teilweise Größe (dpi) und nicht zuletzt den Namen des Kompressionsbeauftragten beinhalten, das brauchen wir hier alles nicht.

[Lokaro]

Wenn RLE auch am einfachsten zu implementieren wäre macht es leider zu schnell keinen sinn mehr da die Daten zu groß werden.

CCITT T.4 ist derzeit der Favorit noch etwas vor .png um es als System umgreifende Komprimierung zu nutzen.

[Kerko]

Hat noch Jemand das Problem, dass einzelne Displays Ihre Batterien innerhalb von 14 Tagen leersaugen? Hängen alle an der gleichen Basis mit dem gleichen Updateintervall. Manche ziehen neue Batterien innerhalb von 14 Tagen leer, manche nicht.

[Hightech]

Ich glaube da gibt es einen Bug, das Display hängt sich auf und macht die Batterie platt.

Hab ich auch schon beobachtet.

[ProgBernie]

Ich glaube da gibt es einen Bug, das Display hängt sich auf und macht die Batterie platt.

Hab ich auch schon beobachtet.

Ein Bug in der Firmware der Schilder würde das erklären. Dann wird vermutlich der RF-Kram nicht abgeschaltet. Der RF-Kram braucht Unmengen an Strom (>30mA), der Rest nicht.

Ich habe auch beobachtet daß ein Schild oft stundenlang keine neue Anzeige schaltet, obwohl diese bereit steht. Im Log habe ich gefunden, daß diese Schilder oft bei jedem Update die Datei bekommen, inzwischen läuft das im Debug hier und ich warte aufs Auftreten. Dann kann ich sehen ob der letzte Teil des Bildes auch ausgeliefert wird.