Hallo liebe Experten, ich habe eine Problemstellung und weiß mir leider keinen Rat mehr. Seit Tagen bin ich am recherchieren und bin auf keine passende Lösung gestoßen. Ihr seit also meine letzte Hoffnung! Folgende Ausgangssituation: Ich habe einen Raspberry Pi. An diesem hängen 6 DS18S20 Temperatursensoren in verschiedenen Räumen. Die Temperaturen werden alls 5 Minuten gemessen und in einer MySQL-DB gespeichert. Außerdem läuft auf dem Raspberry ein Webserver, der die gemessenen Daten visualisiert. Soweit, so gut. Nun möchte ich gerne in den einzelnen Räumen batteriebetriebene LCDs aufstellen und diese gerne vom Raspberry per Funk ansteuern (433Mhz Modul am Raspberry wäre schon vorhanden). Ich habe etwas recherchiert und bin darauf gestoßen, dass es irgendwie möglich sein soll am Display einen RFM01 Empfänger anzuschließen und vom Raspberry aus mit einem RFM12 Modul Daten an die Displays zu senden. Wie würdet ihr dieses Problem angehen? Habt ihr irgendwelche Info darüber wie man grundsätzlich von einer Linux-Maschine (RPi) per Funk batteriebetriebene Displays ansteuern kann. Vorerst würden mit normale LCDs (20x2 oder so) reichen. Wenn das ganze mit grafischen LCDs zu lösen wäre, wäre ich natürlich begeistert! Vielen Dank schon mal und Grüße, Mick
LCD = Liquid Crystel Display, wiso muss man dann noch Display dranhängen? Ist ja wie bei SAT1 der Film Film
Hallo OMG, ich glaube du hast mich da missverstanden. Der Raspberry soll per Funk LCDs ansteuern, die in verschiedenen Räumen aufgestellt sind (Temperaturanzeige), also auf dem Wohnzimmertisch, auf dem Nachttisch in Schlafzimmer, in der Küche usw. Ich kann auch nicht erkennen, wo ich geschrieben habe, dass ich an ein Display ein Display hängen möchte? Gruß, Mick
zum Beispiel im Titel: Batteriebetriebenes LCD Display !!! Hast du es jetzt verstanden?
Hallo Mick,
das was OMG meinte ist, dass die Abkürzung "LCD" bereits ein "Display"
im Wort enthält ("Liquid Crystel Display"). Daher bedeutet der
Threadtitel "Liquid Crystel Display Display". Also ein Display zu
viel...
Zum Thema:
es spricht eigentlich nichts dagegen ein normales 20x2 (oder auch eins
mit anderer Größe) an einen kleinen µC zu hängen, der mittels RFM12 mit
dem Raspberry Pi kommuniziert. Allerdings habe ich keine Erfahrung,
wieviel Strom so ein Display verbraucht (bezüglich Batteriebetrieb).
Vielleicht wäre da ein kleines eInk Display nicht schlecht. Wenn das
Display erst mal beschrieben ist haben die anscheinend einen sehr
kleinen Strombedarf. Deine Temperaturen ändern sich ja maximal alle 5
Minuten.
Ich würde den Controller in der Zeit dazwischen schlafen legen und mit
dem Empfang einer Nachricht vom RFM12 wieder aufwecken.
Hallo OMG, ich entschuldige mich vielmals für diese - fachlich gesehen - amateurhafte Ausdrucksweise, hilft mir bei meinem Problem leider nicht weiter. Ich habe etwas weiter gesucht und bin, wenn die LCDs - aufgrund des Stromverbrauchs - nicht möglich wären, auf E-Paper Displays gestoßen. Gruß, Mick
@Mick Halt Dich nich länger mit so einem Klugsch...er wie OMG auf! Nichts zum Thema beizutragen aber der M..l aufreissen. Hast Du schon mal unter openenergymonitor.org nachgesehen. Ich dächte da was mit (ferngesteuerten) LCD gelesen zu haben.
Hallo Lupfer, danke für deine Antwort. Das sieht schon mal sehr gut aus! Allerdings kostet das Display 63 € (Was für 6 Räume schon fast etwas teuer wird) und zum zweiten kann das "emonGLCD" (wie es heißt) zu viel "Schnick-Schnack", den ich eigentlich nicht brauche. Zum Beispiel brauche ich keinen DS18B20 in Display, es muss auch nicht beleuchtet sein. Desweiteren ist dieses Display (noch) nicht batteriebetrieben und müsste so erst umgebaut werden. Gruß, Mick
@Mick Freut mich, dass Dir der Link (erst einmal) hilft. Immerhin handelt es sich um ein 'open source project', da liegen die Quellen für Hard- und Software i.d.R. komplett offen. Sieh es als Inspirationsquelle für eigene Modifikationen. Das hilft Dir bestimmt allemal weiter, denke ich.
Das Problem ist, dass diese Displays recht viel verbrauchen, es also auf die Akkulebensdauer geht. Aus diesem Grund habe ich bei einem Projekt einen Atmega mit integriertem LCD-Controller verwendet, welcher deutlich sparsamer arbeitet.
Hallo Moritz, kannst du deine Vorgehensweise bei deinem Projekt etwas genauer beschreiben? Welche Hardware hast du verwendet (Display, uC)? Arbeitest du auch mit Funk (auch per RFM01/RFM12)? Danke für eure Antworten, Mick
Hi >Das Problem ist, dass diese Displays recht viel verbrauchen, es also auf >die Akkulebensdauer geht. Das Display selbst verbraucht 1-2mA. Die Beleuchtung schnell das 100-200 fache. Sparsamer sind z.B. DOG-Displays. DOG-M (1x8, 2x8 oder 3x8) brauchen ca. 250µA. Ein 132x32 GrafikDOG-Diplay ca.140µ. MfG Spess
Hallo, ich danke euch für eure Antworten. Die Wahl fällt also entweder auf ein "DOG"-Display (kannte ich bisher gar nicht) oder ein E-Paper Display. Was mir aber noch nicht ganz klar ist: Wie wird die Kommunikation ablaufen: RPi -> RFM12 -> RFM01 -> uC -> Display? Welche Hardware empfehlt ihr genau? Gibts schon Protokolle/SW für den uC auf der Empfänger-Seite? Hat jemand eine Beispielschaltung? Ich muss dazu sagen, ich bin Fachinformatiker/Anwendungsentwicklung, beschäftige mich also eher selten mit der Hardwareseite. Gruß, Mick
spess53 schrieb: > Das Display selbst verbraucht 1-2mA. Die Beleuchtung schnell das 100-200 > fache. Aber selbst das reicht bei angenommenen 2,5Ah nur für 52 Tage Betrieb. > Sparsamer sind z.B. DOG-Displays. DOG-M (1x8, 2x8 oder 3x8) brauchen ca. > 250µA. Ein 132x32 GrafikDOG-Diplay ca.140µ. Und ist damit um Welten empfehlenswerter, bei 150µA (der mikrocontroller will ja auch was abhaben, wobei er wohl die meiste Zeit schlafen sollte) fast 2 Jahre. Ich kenne die RFM*-Dinger nicht, aber wenn die wirklich nur Empfang bieten solltest du dir da was ausdenken, dass sie in annehmbarer Zeit an ihre Daten kommen. Den RasPi alle 10s Daten senden lassen o.ä, damit das Funkmodul nicht allzu lange lauschen muss. Ich verwende den NRF24L01 Tutorial, da er Daten aktiv anfordern kann, dank 2-Wege-Kommunikation. und dazu einen xmegab3 mit http://www.schukat.com/schukat/schukat_cms_de.nsf/index/PDFView?OpenDocument&art=DE325RS-20/8.4(5)&wg=W4235 Das Projekt ist noch nicht fertig und daher kann ich auch noch auf keine konkrete Doku verweisen, wobei sich der Energieverbrauch für das LCD mit irgendwas um 5µA angenehm in Grenzen hält. Ob das Datenblatt hier auch die Realität abbildet wird sich zeigen, sobald ich es aufgebaut habe.
Auf der Seite http://jeelabs.com/ findest du Hard- und Software. Einfach einmal durchstöbern. Z. B. der JEENode (http://jeelabs.com/products/jeenode) dürfte für deine Anwendung interessant sein.
Ich würde die Kommunikation eher mit zwei RFM12 aufbauen. Also:
uC -> RFM12 <-> RFM12 <- uC -> LCD
Damit könntest du eine Kommunikation in beide Richtungen realisieren.
Das würde dann deutlich stromsparender funktionieren, weil die
Anzeigemodule nur kurz aus dem Schlafmodus aufwachen müssen um Daten
anzufordern und dann wieder schlafen gehen.
So in dieser Art:
1. Anzeige uC wacht auf und sendet Anfrage an Basis uC.
2. Basis uC sendet Werte an Anzeige uC.
3. Anzeige uC zeigt Werte an und legt sich wieder schlafen.
Dabei musst du natürlich ein einfaches Protokoll entwickeln, welches bei
mehr als einem LCD Modul sicherstellt, dass nicht gerade gleichzeitig
gesendet (oder dies erkannt) wird.
Ciao,
Rainer
Nokia LCD 5110 oder 1202, ca. 250uA ohne backlight? LG, Sebastian
Hallo, mein erster Schritt wird, denke ich, sein, ein LCD Display mit einem ATMega8 anzusteuern (kann ja ruhig mal ein fester Text sein). Danach würde ich mich mal etwas in die Thematik mit den RFM12 einlesen, um überhaupt mal zu wissen, wie man den mit einem uC ansteuert. Dann werde ich versuchen beides zu kombinieren, sprich einen zweiten RFM12 an den RPi anschließen und mal Daten zu Display übertragen. Zum Schluss das ganze noch mit in mein Temperatur-Python-Script am Pi integrieren. Macht das Sinn so vorzugehen? Mick
Hi, eigentlich schon ja. Aber bitte, bitte, bitte verwende keines dieser dämlichen RFM-Module. Nimm ein NRF24L01+ Modul, die gibt es sehr günstig bei ebay, sind gut dokumentiert und einfach anzusteuern. Im standby brauchen sie nur 26 uA. Der grössten Vorteile dürften aber sein, dass die Module die Antenne schon enthalten, dass sie mit 2.4 GHz arbeiten und natürlich dass sie ein ausgeklügeltes Protokoll verwenden, dass auch retransmitts und CRC unterstützt.
Und auf dem uC: Schlafen, schlafen, schlafen, und wenn aufwachen dann bei niedriger VCC und langsamem Takt ... LG, Sebastian
Sebastian W. schrieb: > und wenn aufwachen dann bei niedriger VCC und langsamem Takt ... Der Takt hängt von der Aufgabe ab, wenn er nur wartet (wobei dann geht auch Sleep) mag das sinnvoll sein, wenn er wirklich rechnet aber nicht. Beispiel tiny2313a @3,3V: - 4MHz 1,5mA - 12MHz 3,1mA Somit "rechnet" er beim doppelten Verbrauch dreimal so schnell, es ist also sinnvoll ihn höher getaktet zu betreiben, damit er schneller wieder in seine Schlafmodi zurückkehren kann. Netterweise kann man den Clock-Divider ja zur Laufzeit umkonfigurieren, man sollte nur den Überblick behalten falls man doch man sleeps verwendet, auf welche Taktrate bezogen da nun die Zeitangaben sind.
wireguy schrieb: > Was hast du gegen die RFM-Module? Sie sind zu teuer, schlecht dokumentiert, unpraktisch und wenn es nicht gerade das rfm70 ist, brauchen sie noch eine externe antenne. Also ich habe mir zwei rfm70 gekauft und es bereut, dann habe ich zehn nrf24l01 gekauft und mich gefreut. ;) Enhanced ShockBurst(TM) ist der Hammer! Edit: Zugegeben, das rfm70 ist schon verdammt klein für seine Leistung, deshalb wollte ich zuerst auch dieses Modul nehmen
Mick schrieb: > Nun möchte ich gerne in den einzelnen Räumen batteriebetriebene LCDs > aufstellen und diese gerne vom Raspberry per Funk ansteuern (433Mhz > Modul am Raspberry wäre schon vorhanden). Warum will man so etwas, wenn man mit seinem Handy einfach per Wlan auf den Webserver im Rpi zugreifen kann?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.