Liebe Experten,
ich brauche Euren Rat!
Es geht um einen Whirlpool, der in einem Ferienhaus betrieben wird.
Dieser benötigt einige Zeit um warm zu werden. Daher wäre es toll diesen
von Zuhause aus einschalten zu können. Eine einfache Strom an / Strom
aus Variante geht nicht, da Umwälzpumpe, Frostschutz, Ozonator etc.
weiter laufen müssen, auch wenn die Temperatur runter gedreht ist.
Die Temperatur wird mittels eines Bedienteils über zwei Knöpfe +/-
eingegeben. An einem LCD Display kann man aktuelle und Solltemperatur
ablesen.
Vom Bedienteil gehen 8 Kabel in die Steuerplatine des Whirlpools. Sie
sind folgendermaßen bezeichnet: Key1, Key2, CS, DATA, CLK, A, DNS, +5.
Um welche Art von Serieller-Kommunikation (Protokoll?) könnte es sich
hierbei handeln?
Ich möchte gerne mit Arduino das Drücken des + bzw. - Knopfes simulieren
und so die Temperatur regeln. Schön wäre es auch die derzeitige und
Solltemperatur auszulesen. Seht ihr da eine Chance?
Vielen Dank für Euren Rat und Tipps!
Henry
Als ersten Schnellschuss würde ich SPI tippen. Falls es das ist, kannst
du ohne Probleme mit einem SPI2USB Konverter am Rechner mitlesen und das
entsprechende Protokoll verifizieren.
Wenn du gar nicht über das Protokoll an deine Temperaturen kommst, dann
kannst du immer noch den Tastendruck simulieren. Problem dabei ist nur,
dass du die aktuell eingestellte Temperatur nicht weißt.
Als recht günstiges und vielseitiges Tool kann ich dir das AVRLab
empfehlen.
http://wiki.ullihome.de/index.php/Hauptseite
Da ist z.B. auch ein Firmware dabei, mit welcher es möglich ist, die SPI
Kommunikation mitzulesen.
http://wiki.ullihome.de/index.php/USBAVR-ISP-Firmwares/SPI-USB-UARTBridge/de
Vielen Dank für den Tipp. Ich habe überlegt mir den Logic-Analyzer von
Saleae zu kaufen und damit alle 8 Leitungen zu loggen, während ich die
gewollten Aktionen durchführen. SPI sollte ich damit ja dann erkennen
können. Bleibt nur die Frage der Belegung der Kabel, ist ja aus der
Bezeichnung nicht alles ersichtlich.
Den Tastendruck direkt zu simulieren wird ohne Protokoll vlt. schwierig,
da das Bedienfeld wasserdicht versiegelt ist und ich das nur ungern
öffnen möchte... Vielleicht habe ich aber Glück und Key1 und Key2 sind
genau die beiden Temp +/- Knöpfe.
Wenn Key1 und Key2 schon die Knöpfe sind, besteht immer noch das
Problem, dass du nur die aktuelle Temperatur erhöhen oder absenken
kannst. Du weißt aber nicht wo du angefangen hast.
Sich für solch eine Aufgabe extra einen Logik Analysator zu kaufen finde
ich übertrieben. Die Bezeichnung ist ziemlich eindeutig. Mach dich mal
ein wenig über SPI schlau, da werden dir ganz schnell die Parallelen an
der Belegung auffallen (CS, Data, CLK). Ich würde schon zu nahezu 95%
darauf tippen, das es SPI ist. Da reicht dann eine einfache SPI2USB
Bridge vollkommen aus. Das AVR Lab kann zudem auch gleich als Programmer
für einen später angedachten µC eingesetzt werden. Für 15€ ein
wirkliches Schnäppchen.
Hier noch ein Link zum Verständnis von SPI
http://www.rn-wissen.de/index.php/SPI
PS: ob da nun Data, SDI oder SDO steht soll dich erst mal nicht weiter
stören
Sollte es kein SPI sein, wäre auch noch I2C möglich. Wie der Zufall so
will, kannst du mit dem AVR Lab auch das Protokoll einfach mitloggen.
Hört sich sehr gut an, vielen Dank. Ich werd mich da jetzt erst mal
weiter einlesen. Aber du hast recht, es sieht von der Belegung sehr nach
SPI aus...
Hi!
Auf dem Bild sieht die Beschriftung etwas anders aus:
Key1, Key2, CS, DATA, CLK, A, GND, +5.
Nach SPI riecht da garnix, eher nach I2C. Denn Für SPI müsste MOSI und
MISO oder wenigstens Data1 und Data2 oder ähnliches zu finden sein.
Ohne gleich mit schwerem Gerät alles mit zu lesen, würde ich zuerst mal
das Bedienteil öffnen und nachsehen, ob dort nicht der ein oder andere
Chip mit lesbarer Beschriftung zu finden ist. Dann man suchen, was diese
Chips so können und welche Interfaces sie unterstützen.
Es hilft auch immer mal auf beiden Seite nachzusehen, wo die Signale
dort auf einen Chip geführt werden und welche Fähigkeiten dieser Chip an
den entsprechenden Pinnen hat.
Da das Display ja die aktuelle Solltemperatur anzeigt, spricht nix
dagegen, diese Anzeige über simulierte Tastendrücke zu provozieren und
dann den Datenstrom zum Display auszulesen und diese Information dann
auszuwerten oder ebenfalls per Internet zu versenden. Wäre eine nette
Applikation für eine Ethernut 1.3.
Gruß, Ulrich
Ulrich P. schrieb:> Nach SPI riecht da garnix, eher nach I2C.Remote One schrieb:> Sollte es kein SPI sein, wäre auch noch I2C möglich. Wie der Zufall so> will, kannst du mit dem AVR Lab auch das Protokoll einfach mitloggen.
Das wurde ja auch schon angesprochen. Bei I2C stört mich persönlich
lediglich die Chip Select (CS) Leitung. Da bei I2C eigentlich mit der
Adresse selektiert wird.
Nichtsdestotrotz gibt es natürlich auch Bausteine welche mehrfach am Bus
hängen können und produktionsseitig die gleich Adresse haben, so dass
man um ein Chip Select nicht herum kommt.
Zu den Datenleitungen bei SPI, also SDI und SDA, ist es genauso gut
mgl., dass der Baustein nur sendet und deswegen nur eine Datenleitung
vorhanden ist. Evtl. werden die aktuelle Einstellungen ja lediglich an
die Steuerung übergeben. Das ist ja schließlich nur die
"Eingabeeinheit". Zudem kann es auch sein, dass nicht alle Leitungen an
diese Stiftleiste herausgeführt sind.
Also einfach mal verfolgen, wo die Data und CLK Leitung hinführt und den
entsprechenden Chip näher identifizieren.
Henry,
die idee mit dem logic von salae ist nicht verkehrt, da du damit
sämtliche signale parallel und zeitlich zugeordnet loggen kannst. Ob das
nun SPI-like oder eher I2C ist, wirst du sehr schnell erkennen können
und dann einfach den richtigen interpreter benutzen.
das avrlab ist zwar auch eine option aber da wird es mit den
key-leitungen und der a-leitung schon schmal.
hmmm, eine manipulation der busleitungen von aussen kann klappen, aber
du solltest bedenken, das da auch jemand gegen deine eingespeisten pegel
treiben könnte, also erstmal loggen, anschauen und dann einen plan
machen - alles andere ist zuviel glaskugel.
gruss aus berlin, tom.
Muss mich korrigieren:
Die allermeisten LCD-Controller Chips, die auch SPI unterstützen, können
nur Daten empfangen und brauchen das /CS um sich auf den SPI Datenstrom
zu synchronisieren. CS, DATA, CLK können also sehr wohl einen 'halben'
SPI darstellen, der nur Daten zum Display senden kann.
Es würde mich nicht wundern, wenn die Tasten einfach an einem R2R
Netzwerk hängen und von ein oder zwei ADC Kanälen des Controllers
ausgelesen werden.
Ich habe meine Glaskugel nicht dabei, aber es gibt eine nicht zu
verachtende Wahrscheinlichkeit, dass die beiden Tasten Up/Down auf Key1
und Key2 digital liegen und der Steuerkreis über eine Widerstandskaskade
am Pin A zu finden ist. Das sollte sich sehr einfach herausfinden
lassen, ganz ohne igendeinen Analyzer zu kaufen:
Display Einheit abstöpseln, dann
Multimeter in Ohm-Stellung an +5 und A, dann Tasten betätigen und sehen,
ob sich dort je nach Tastendruck die Werte ändern. Das ganze mit +5V und
Key1/2 wiederholen. Dann die ganze Reihe noch mal mit GND und A / GND
und Key1/2.
Wenn ich damit recht habe, gibt es vielleicht immer noch einen einfachen
und einen schweren Weg das Ding fern zu steuern:
Einfach:
Der Hersteller hat RXD/TXD als serielle Schnittstelle beibehalten und
man kann heraus finden, wie man Parameter darüber direkt setzt.
(Bitte über Pegelwandler an den PC, nicht direkt!)
Schwer:
Man kauft sich ein Digital-Poti mit I2C oder SPI Schnittstelle und
bringt dem Web-Server das simulieren eines Tastendruckes bei. Sorry fpr
die Wiederholung, aber man kann auch das SPI mitlesen, dass das Display
steuert und daraus herleiten, welche aktuellen Werte angezeigt werden.
Gruß, Ulrich
@ulrich:
1. denke, deine vermutung mit den analog codierten tastern ist
wahrscheinlich zutreffend. aber da es ja paar mehr als nur key-up/down
sind glaskugele ich eher in die richtung zwei kanäle (KEY1, KEY2) an
adc-eingänge des uC, das lässt sich mit ohmmeter ja herausfinden.
2. der SPI oder I2C data-bus steuert wahrscheinlich das display an.
3. Leitung A könnte auch die ansteuerung für die hintergrundbeleuchtung
oder kontrasteinstellung des displays sein. falls es ein menü zum
einstellen gibt, könnte man das damit z.B. herausfinden oder
ausschliessen.
4. um soll/ist temperatur oder komplette displayausgaben nach "remote"
zu übertragen wird trotzdem nichts anderes übrigbleiben als den
digitalen bus zu ananlysieren und die ausgaben daraus zu extrahieren. da
sind vernünftige tools, die man auch weiterbenutzen kann nie schlecht...
5. digitales poti als taster-emulation ist eine gute idee, muss man aber
mal schauen wegen dem widerstandsbereich der gebraucht wird. ggf. eher
ein 8-bit port mit R2R Netzwerk spendieren.
anyway, gutt lack and häv fann, Hännrie.
Moin Moin,
lange ist es her.... und nun, nach über 10 Jahren (!) habe ich mir die
Zeit genommen mich diesem Projekt wieder zu widmen. Grund ist auch, dass
die LCD Anzeige altersbedingt so langsam kaum noch lesbar ist.
Ich habe die Leitungen mal mit einen Logic-Analyzer (Saleae) geprüft,
anbei ein paar Screenshots.
Das Display scheint seine Daten via SPI zu erhalten:
CS active low
DATA -> MISO
CLK -> clock
Soweit nicht überraschend.
Alle 25ms werden 138bit übertragen.
Zudem wird alle 1.28s (also alle 51 mal) zusätzlich vor dem 138bit-Paket
ein 40bit-Paket gesendet.
Ich konnte leider noch nicht entschlüsseln, wie die Daten zu
interpretieren sind.
Eingangs dachte ich, jedes Bit entspräche einem LCD-Segment, wie ja
bereits angeregt wurde. Aber so einfach scheint es nicht zu sein. Ich
habe jedes bit mal durch toggeln "blinken" lassen, um die entsprechenden
Segmente zuzuordnen. Aber mal hat ein Bit gar keine Auswirkungen
(jedenfalls nicht ersichtlich) und mal blinken ganze Segment-Gruppen.
Ich habe das gleiche mit dem 40bit-Paket versucht. Auch hier haben
manche Bits keine Auswirkungen, mal blinken auf einmal ganze Bereiche
des Displays. Ein Bit scheint hierbei alle Segmente leuchten zu lassen,
unbeachtet der Inhalte des 138bit-Pakets.
Vielleicht ist das 40Bit Paket so eine Art Data-Latching oder
Refresh-Anweisung?
Bsp 138bit:
(immer dann mit "0101" am Anfang, sonst immer die "1101")
Es wäre natürlich hilfreich zu wissen welche Art von IC im Bedienteil
verbaut ist, nur leider ist das Bedienteil verklebt bzw. vergossen.
Hat jmd. hier eine Idee wie man vorgehen könnte? Die 138Bits entspricht
Augenscheinlich der Anzahl der Segmente, also das scheint schon der
richtige Ansatz zu sein, denke ich.
Die Buttons, ein Buzzer und das Display Backlight werden ebenfalls via
SPI übertragen. Dabei übernimmt eine Leitung jedoch eine andere Rolle:
Display-CLK wird zur Data-Line und A ist nun die CLK, kein CS. Es hier
alle 25ms (zwischen den Display Paketen) mal 6, mal 7 Bytes übertragen.
Hier ein Bsp:
1
0111 1100
2
0111 1010
3
0111 0110
4
0110 1110
5
0101 1110
6
0011 1110
7
0111 1110
Das schalten des Buzzers und des Backlights scheinen Bits 7 und 6 zu
sein. 0-5 werden genutzt um wohl die Button-Presses zu übermitteln. Also
keine Resistor-Networks wie einst vermutet. Diesem Part werde ich mich
widmen sobald ich das Display verstanden habe.
Also Was mir derzeit Kopfzerbrechen bereitet ist das dekodieren der
Display Daten...
Hat jemand eine Idee?
VG, Henry
Hallo Henry,
Bist du bei deinem Projekt weiter gekommen?
Mich würde auch die Ansteuerung des Panels über einen Arduino
interessieren, da meine Hauptplatine durchgebrannt ist und ich hier
keinen Fehler finde.
Schöne Grüße
Michael
Uebersicht.jpg
(620 KB)
Platine.jpg
(220 KB)
Bedienfeld.jpg
(51 KB)
