Hallo, für ein Projekt möchte ich den Durchfluss von Wasser und Temperatur steuern. Da ich günstig an ein digitales Steuerungssystem von Grohe gekommen bin versuche ich nun dieses Protokoll zur Ansteuerung selbst zu implementieren, bzw. falls das nicht möglich ist die entsprechenden Telegramme einfach zu kopieren. Physikalischer Aufbau: Stecker mit 3 Pins. Vcc GND Signal Daten auf dem Oszi. Wie man sieht sind die einzelnen Signale minimal 100µS. Ich dachte erst an 1-Wire aber das ist es wohl eher nicht. Möglicherweise ist es eine propritäre Geschichte. Seltsam ist auch, dass die Anzahl der "Bits" nicht konstant ist (vgl Durchflussbilder). Ich vermute, dass im hinteren Teil eine Art CRC oder XOR Checksumme enthalten ist. Außerdem scheint das letzte Signal ein Ack von der Gegenstelle zu sein. Aber so lange ich nicht weiß wie die Bit von den physikalischen Signalen in logische Bits überführt werden sind das alles nur Vermutungen. Vielleicht kennt jemand diese Art der Kodierung? Vielen Dank schon mal...
Angehängte Dateien:
-
Durchfluss_Stufe_8.png
16 KB -
Durchfluss_Stufe_7.png
16 KB -
Durchfluss_Stufe_6.png
16 KB -
42_.png
16 KB
:
Bearbeitet durch User
Florian We schrieb: > für ein Projekt möchte ich den Durchfluss von Wasser und Temperatur > steuern. Da ich günstig an ein digitales Steuerungssystem von Grohe Ich verstehe das Problem noch nicht ganz. Du hast ein Steuerungssystem günstig von Grohe erworben/bekommen, aber jetzt willst Du per Hand steuern? Was ist denn das für ein System? RainBrain?
Du solltest die Unterschiede aus den Stufen extrahieren und untereinander schreiben. - langer Puls 1 - kurzer Puls 0
Das scheinen CAN-Bus-Nachrichten mit jeweils 6 Datenbytes zu sein. Die leicht unterschiedliche Länge kommt vom Bit-Stuffing.
Hallo, könnte rein von der Bitfolge CAN sein: + erste Bits immer gleich --> gleiche Botschaft-Id + gleich lange High Pulse, gefolgt von kurzen Low-Pulse --> Bit Stuffing + CRC am Ende + Bitanzahl variiert + Acknowledge am Ende Dagegen spricht das normalerweise zwei Leitungen die Daten übertragen. Aber vielleicht wurde der Tranciever gespart und nur das TX-Signal wird über eine kurze Strecke übertragen. Gruß Mentos77
Ergänzung zu meinem Beitrag von oben: Ja, das sind tatsächlich CAN-Nachrichten. Neben der Bitzahl, der DLC und den einzelnen Steuerbits stimmt auch die 15-Bit-CRC bei allen vier Nachrichten, das kann fast kein Zufall sein.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Ja, das sind tatsächlich CAN-Nachrichten. Neben der Bitzahl, der DLC und > den einzelnen Steuerbits stimmt auch die 15-Bit-CRC bei allen vier > Nachrichten, das kann fast kein Zufall sein. Richtiges CAN wird es wohl kaum sein. Bei CAN sind alle Layer streng definiert, vor allem was den Bus betrifft. Eine Leitung für Daten gibt es nicht, CAN-Low und CAN-High sind vorgeschrieben. Bitstuffing und Header mögen da ähnlich aussehen, aber CAN kann es trotzdem nicht sein.
:
Bearbeitet durch User
Ist ganz sicher was Proprietäres. Schaut euch nur das letzte highbit an. Der Pegel dieses Bits ist bei Telegrammen um ca.20% reduziert.
Marc Vesely schrieb: > Eine Leitung für Daten gibt es nicht, CAN-Low und CAN-High > sind vorgeschrieben. Bei Single Wire CAN auch?
Marc Vesely schrieb: > Richtiges CAN wird es wohl kaum sein. Habe ich das irgendwo geschrieben? Ich habe nur geschrieben, dass es sich um CAN- Nachrichten handelt. > Bei CAN sind alle Layer streng definiert, vor allem was den Bus > betrifft. Was die Leitung(en) und die elektrischen Parameter der Signale betrifft, lässt der Standard mehrere Alternativen zu. Die Übertragung muss nicht einmal elektrisch, sondern darf auch optisch (über Lichtwellenleiter) erfolgen. > Eine Leitung für Daten gibt es nicht, CAN-Low und CAN-High > sind vorgeschrieben. Nein. Hier ist ein Bisschen Lesestoff zu dem Thema: http://www.can-cia.org/index.php?id=systemdesign-can-physicallayer#c2068 Wenn du's genauer wissen möchtest, musst du dir die einschlägigen Normen besorgen. Ob der physical Layer einem der in dem Link genannten Standards (z.B. SAE J2411 single wire) entspricht oder nicht, ist hier aber ziemlich belanglos, da sich der TE ausschließlich für das eingesetzte Protokoll interessiert. Und das ist eben das beim CAN verwendete.
Winfried J. schrieb: > Ist ganz sicher was Proprietäres. Schaut euch nur das letzte highbit an. > Der Pegel dieses Bits ist bei Telegrammen um ca.20% reduziert. Das kommt daher, dass dieses Bit (ACK) nicht vom Sender, sondern vom Empfänger der Nachricht auf den Bus geschrieben wird. Da können sich kleinere Unterschiede im Signalpegel ergeben. Das ist ein weiteres Indiz dafür, dass hier das CAN-Protokoll verwendet wird.
:
Bearbeitet durch Moderator
A. K. schrieb: > Bei Single Wire CAN auch? Natürlich nicht, aber Single Wire habe ich nur beim Fensterheber und manch älteren Klimaanlagen in Autos gesehen. Und CAN mit 9600B oder 10KB erschien mir auch nicht besonders logisch. Deswegen habe ich CAN ausgeschlossen. Yalu X. schrieb: > Ob der physical Layer einem der in dem Link genannten Standards (z.B. > SAE J2411 single wire) entspricht oder nicht, ist hier aber ziemlich > belanglos, da sich der TE ausschließlich für das eingesetzte Protokoll > interessiert. Und das ist eben das beim CAN verwendete. Naja, wenn du die einzelnen bits dekodiert hast... Ich habe es nicht getan, glaube dir aber aufs Wort.
Ok das hilft mir schon mal weiter. Dann werde ich mir mal Can ein bischen näher anschauen. Vielen Dank für eure Hilfe. Wünsche euch ein schönes Wochenende...
Yalu X. schrieb: > Hier ist ein Bisschen Lesestoff zu dem Thema: > > http://www.can-cia.org/index.php?id=systemdesign-can-physicallayer#c2068 Wenn ich versuche die Frames anhand des hier angegebenen Schemas zu dekodieren komme ich auf nicht sinnvolle Ergebnisse. Könntest du mir sagen nach welchem Schema du das dekodiert hast? Oder brauche ich da wirklich gleich die ganze Norm? Grüße Florian
:
Bearbeitet durch User
Florian We schrieb: > Wenn ich versuche die Frames anhand des hier angegebenen Schemas zu > dekodieren komme ich auf nicht sinnvolle Ergebnisse. Nimm einfach die Wikipedia-Seite, da steht alles Wichtige drin: http://de.wikipedia.org/wiki/Controller_Area_Network#Frame-Aufbau Beachte, dass im dortigen Diagramm nur 1 Datenbyte übertragen wird (DLC=1), bei dir sind es aber 6 Datenbytes (DLC=6). Deswegen sind bei dir die Nachrichten länger. Im folgenden ist gezeigt, wie die vier Nachrichten aus deinen Oszi- Screenshots dekodiert werden. Zeile 1: Dateiname Zeile 2: Signalform Zeile 3: Zugehörige Bits in negativer Logik (high=0, low=1) Zeile 4: Position der Stopfbits (erscheinen immer nach 5 gleichen Bits) Zeile 5: Entstopfte Nachricht (alle Stopfbits sind entfernt) Danach: Unterteilung in die einzelnen Elemente mit den jeweiligen numerischen Werten (Big-Endian)
1 | Durchfluss_Stufe_8.png: |
2 | —_—_———_——__————__—————_———_—————_——_—_—————_—__—_——_—————_—————_—————_——_——___—_———___—_—__________ |
3 | 0101000100110000110000010001000001001010000010110100100000100000100000100100111010001110101111111111 |
4 | ^ ^ ^ ^ ^ ^ |
5 | 0101000100110000110000000010000000101000000110100100000000000000000100111010001110101111111111 |
6 | |<—————————>|||<——><——————><——————><——————><——————><——————><——————><—————————————>||<—————><—> |
7 | |Identifier |||DLC Data Data Data Data Data Data CRC ||EOF IFS |
8 | |(0x513) |||(6) (0x01) (0x01) (0x40) (0xD2) (0x00) (0x00) (0x4E8E) || |
9 | Start ||Reserved |ACK-Delimiter |
10 | |IDE ACK-Slot |
11 | RTR |
12 | |
13 | |
14 | Durchfluss_Stufe_7.png: |
15 | —_—_———_——__————__—————_———_—————_——_—_—————_—_—__—_—————_—————_—————_————_——_————____——_—__________ |
16 | 0101000100110000110000010001000001001010000010101101000001000001000001000010010000111100101111111111 |
17 | ^ ^ ^ ^ ^ ^ |
18 | 0101000100110000110000000010000000101000000101101000000000000000000010010000111100101111111111 |
19 | |<—————————>|||<——><——————><——————><——————><——————><——————><——————><—————————————>||<—————><—> |
20 | |Identifier |||DLC Data Data Data Data Data Data CRC ||EOF IFS |
21 | |(0x513) |||(6) (0x01) (0x01) (0x40) (0xB4) (0x00) (0x00) (0x243C) || |
22 | Start ||Reserved |ACK delimiter |
23 | |IDE ACK slot |
24 | RTR |
25 | |
26 | |
27 | Durchfluss_Stufe_6.png: |
28 | —_—_———_——__————__—————_———_—————_——__—_——_——____—————_—————_—————_—————_—__—_—_____———___—__________ |
29 | 01010001001100001100000100010000010011010010011110000010000010000010000010110101111100011101111111111 |
30 | ^ ^ ^ ^ ^ ^ ^ |
31 | 0101000100110000110000000010000000110100100111100000000000000000000011010111110011101111111111 |
32 | |<—————————>|||<——><——————><——————><——————><——————><——————><——————><—————————————>||<—————><—> |
33 | |Identifier |||DLC Data Data Data Data Data Data CRC ||EOF IFS |
34 | |(0x513) |||(6) (0x01) (0x01) (0xA4) (0xF0) (0x00) (0x00) (0x35F3) || |
35 | Start ||Reserved |ACK delimiter |
36 | |IDE ACK slot |
37 | RTR |
38 | |
39 | |
40 | 42_.png: |
41 | —_—_———_——__————__—————_———_—————_——_—_———_—_____—————_—————_—————_—————_————__—_____—_———_—__________ |
42 | 010100010011000011000001000100000100101000101111100000100000100000100000100001101111101000101111111111 |
43 | ^ ^ ^ ^ ^ ^ ^ ^ |
44 | 0101000100110000110000000010000000101000101111100000000000000000000000110111111000101111111111 |
45 | |<—————————>|||<——><——————><——————><——————><——————><——————><——————><—————————————>||<—————><—> |
46 | |Identifier |||DLC Data Data Data Data Data Data CRC ||EOF IFS |
47 | |(0x513) |||(6) (0x01) (0x01) (0x45) (0xF0) (0x00) (0x00) (0x0DF8) || |
48 | Start ||Reserved |ACK delimiter |
49 | |IDE ACK slot |
50 | RTR |
Die CRCs kannst du mit den hier geposteten C-Funktionen berechnen lassen und auf Richtigkeit prüfen: http://can-bus.996267.n3.nabble.com/How-CRC-for-CAN-bus-is-calculated-td4034.html
:
Bearbeitet durch Moderator
Marc Vesely schrieb: > Richtiges CAN wird es wohl kaum sein. Highspeed-CAN wird es nicht sein, richtig. Es gibt aber noch eine uralte Norm, die mit umgedrehten TTL-Pegeln arbeitet. High (dominant) wird aktiv getrieben, Low (rezessiv) über einen Widerstand eingestellt. Hier das Datenblatt eines passenden Transceivers: http://www.nxp.com/documents/data_sheet/AU5790.pdf Das System findet man noch in Nutzfahrzeugen und in Heizungssteuerungen.
@ Yalu X. Wow echt vielen Dank für die Mühe (allerdings passt die Zuordung der Bits nicht zu den Bildern ;) ). Ich hatte die Invertierung nicht gemacht und bin dann nicht klar gekommen. Jetzt schaut das ganze schon besser aus. Hast du das von Hand gemacht oder hast du dafür ein Tool (Bereiche und Kennzeichnung) @soul eye Danke für den Tip. Aber kennst du auch einen den man noch irgendwo kaufen kann? Oder kann ich diesen CAN Typ auch mit einem anderen Typ von Transceiver betreiben? Grüße Florian
Ich glaube nicht, das wir von den Dingern irgendwo noch welche haben. Ein CANcab dafür habe ich aber noch... Für den Privatgebrauch könntest Du einen (PNP-)Transistor gegen Plus und einen Widerstand gegen Masse schalten. Mehr macht der Transceiver ja auch nicht. Die ganzen Schutzschaltungen fehlen dann natürlich. Der Transistor wird dann mit TxCAN so angesteuert, dass er bei einem dominanten Pegel (TxCAN low) schaltet. Bei rezessivem Pegel (TxCAN high) zieht der Widerstand den Bus auf Masse. Das empfangene Signal geht dann über einen Inverter auf RxCAN.
Florian We schrieb: > (allerdings passt die Zuordung der > Bits nicht zu den Bildern ;) Oh ja, da ist leider etwas durcheinander geraten. Als ich den letzten Beitrag zusammenschrieb, wusste ich nicht mehr, in welcher Reihenfolge ich die Oszi-Bilder drei Tage zuvor ausgewertet habe. Man kann die Bitmuster aber leicht anhand der letzten paar Bits den einzelnen Bildern zuordnen. > Hast du das von Hand gemacht oder hast du dafür ein Tool (Bereiche und > Kennzeichnung) Von Hand. Man könnte natürlich auch ein kleines Tool schreiben, das eine Datei mit den Oszi-Messwerten einliest und die Dekodierung automatisch durchführt. Das würde vor allem bei der zeitlichen Quantisierung des Signals einiges an Arbeit sparen.
Yalu X. schrieb: > Man kann die > Bitmuster aber leicht anhand der letzten paar Bits den einzelnen Bildern > zuordnen. Hab ich auch so gemacht. War kein Problem. Also nochmal vielen vielen Dank für die Mühe... (An alle die geantwortet haben) Grüße Florian
Zu der Frage mit welchem Transciever man das hinbekommt. Es gibt CAN Low Speed Transciever die auch problemlos mit einer Eleitung arbeiten. Die melden dann meist nur einem Pin das ein Fehler vorliegt. z.B. der TJA1055 kan dies. Den gibt es in der 5V und in der 3,3V Version
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.