VBus-Decoder: Unterschied zwischen den Versionen

Aus Hobbyelektronik.org
K (oh, es gibt ja schon FAQ)
(19 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
 
[[Bild:Vbus regler.jpg|thumb|Das Corpus Delicti]]
 
[[Bild:Vbus regler.jpg|thumb|Das Corpus Delicti]]
 +
{{Infobox AVR
 +
| Typ  = ATmega32
 +
| Takt  = 12
 +
| FuseH = CF
 +
| FuseL = FF
 +
}}
 
In unserer Solaranlage arbeitet ein Viessmann Vitosolic 200, der die Regelung der Anlage übernimmt.
 
In unserer Solaranlage arbeitet ein Viessmann Vitosolic 200, der die Regelung der Anlage übernimmt.
 
Nach kurzer Recherche stellte sich heraus, dass es sich um eine etwas angepasste Version des [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de RESOL DeltaSol® M] handelt.
 
Nach kurzer Recherche stellte sich heraus, dass es sich um eine etwas angepasste Version des [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de RESOL DeltaSol® M] handelt.
Zeile 11: Zeile 17:
 
=Hardwareschnittstelle=
 
=Hardwareschnittstelle=
 
[[Bild:Resol sch.png|thumb|Wo Rx und Tx ist, muss erraten werden ;)]]
 
[[Bild:Resol sch.png|thumb|Wo Rx und Tx ist, muss erraten werden ;)]]
Bei dem VBus handelt es sich um eine bidirektionale halbduplex Zweidrahtschnittstelle, die zwar Ähnlichkeiten zu RS485 hat, diesem aber nicht entspricht.
+
Bei dem VBus handelt es sich um eine bidirektionale halbduplex Zweidrahtschnittstelle, die - entgegen diverser Meinungen - überhaupt keine Ähnlichkeiten zu RS485 hat, diesem aber nicht entspricht.
  
 
Der Master (Regel-Einheit) versorgt den Bus mit etwa 8,2V und 35mA (S. 4 in der Doku). Die Daten werden durch Spannungsabsenkung auf dem Bus übertragen.
 
Der Master (Regel-Einheit) versorgt den Bus mit etwa 8,2V und 35mA (S. 4 in der Doku). Die Daten werden durch Spannungsabsenkung auf dem Bus übertragen.
Zeile 17: Zeile 23:
  
 
Über die Buchse links kann man sich mit UART (nicht RS232!) mit 9600 Baud, 8 Datenbits, 1 Stoppbit ohne Parität mit dem Master unterhalten.
 
Über die Buchse links kann man sich mit UART (nicht RS232!) mit 9600 Baud, 8 Datenbits, 1 Stoppbit ohne Parität mit dem Master unterhalten.
 +
 +
Der in meiner Schaltung verwendete FET für die bidirektionale Kommunikation ist übrigens ein BS170
  
 
=Protokoll=
 
=Protokoll=
Zeile 66: Zeile 74:
 
Über den Befehl Vbus_ProcessChar() kann ein Zeichen von der seriellen Schnittstelle übergeben werden. Im einfachsten Fall kann die ISR-Routine wie folgt aussehen:
 
Über den Befehl Vbus_ProcessChar() kann ein Zeichen von der seriellen Schnittstelle übergeben werden. Im einfachsten Fall kann die ISR-Routine wie folgt aussehen:
  
<pre>
+
<source lang="c">
 
ISR (USART_RXC_vect) {
 
ISR (USART_RXC_vect) {
 
Vbus_ProcessChar(UDR);
 
Vbus_ProcessChar(UDR);
 
}
 
}
</pre>
+
</source>
  
 
Vorher muss noch der UART initialisiert werden (9600 8N1, sei() nicht vergessen!).
 
Vorher muss noch der UART initialisiert werden (9600 8N1, sei() nicht vergessen!).
Zeile 82: Zeile 90:
 
Ist ein Paket vollständig angekommen, wird die valid-Eigenschaft auf 1 gesetzt. Im Demo-Code wird nach erfolgreichem Empfang das komplette Datenpaket am UART ausgegeben (bitte nicht an den Regler zurückschicken, sondern möglichst an den PC!):
 
Ist ein Paket vollständig angekommen, wird die valid-Eigenschaft auf 1 gesetzt. Im Demo-Code wird nach erfolgreichem Empfang das komplette Datenpaket am UART ausgegeben (bitte nicht an den Regler zurückschicken, sondern möglichst an den PC!):
  
<pre>
+
<source lang="c">
 
int main() {
 
int main() {
  
Zeile 95: Zeile 103:
 
   }
 
   }
 
}
 
}
</pre>
+
</source>
 +
 
 +
 
 +
 
 +
==Debug-Ausgabe==
 +
[[Bild:Vbus debug.jpg|thumb|Anzeige auf dem Display. die ICs unten und rechts gehören nicht zur Schaltung]]
 +
Der Debug in der Software gibt einige Informationen zur Dekodierung auf einem LC-Display aus.
 +
 
 +
Dieser Modus kann in der Datei vbus.h Zeile 35 aktiviert werden (standardmäßig deaktiviert).
 +
 
 +
Über UART würde eine Ausgabe kaum sinn machen, da man durch das langsame Senden den Empfang der Daten verpasst.
  
Der Debug in der Software schreibt einige Informationen zur Dekodierung auf einem LC-Display. Über UART macht das kaum Sinn, da man den Empfang der Daten verpasst.
 
 
Zugegebenermaßen: ich habe einen Exoten mit LC7980-Controller und einer Auflösung von 240x40 Pixel verwendet. Die Routinen lassen sich aber halbwegs einfach auf einen anderen Displaycontroller anpassen.
 
Zugegebenermaßen: ich habe einen Exoten mit LC7980-Controller und einer Auflösung von 240x40 Pixel verwendet. Die Routinen lassen sich aber halbwegs einfach auf einen anderen Displaycontroller anpassen.
 
Die Ausgabe auf dem Display sieht wie folgt aus:
 
Die Ausgabe auf dem Display sieht wie folgt aus:
  
==Debug-Ausgabe==
+
Bei jedem Erhalt eines Sync-Wortes wird "Sync" angezeigt.
[[Bild:Vbus debug.jpg|thumb|Anzeige auf dem Display. die ICs unten und rechts gehören nicht zur Schaltung]]
 
Bei jedem Sync wird "Sync" angezeigt.
 
  
Wurde der Head empfangen, kommt es zu folgender Ausgabe:
+
Wurde der Head empfangen, wird der Displayinhalt gelöscht und folgendes ausgegeben:
  
 
<pre>
 
<pre>
D:<Ziel-Adresse> S:<Quell-Adresse> V:<Protokoll-Version> C:<Befehl> F:<Anzahl Frames> C:<Prüfsumme ok|nok>
+
D:<Ziel-Adresse> S:<Quell-Adresse> V:<Protokoll-Version> C:<Befehl> F:<Anzahl Frames> X:<Prüfsumme ok|nok>
 
</pre>
 
</pre>
  
Zeile 125: Zeile 140:
 
<pre>
 
<pre>
 
Sync [Display wird geleert]
 
Sync [Display wird geleert]
D:0x0010 S:0x7321 V:1 C:0x0100 F:18 S:ok F0ok F1ok F2ok F3ok F4ok F5ok F6ok F7ok F8ok F9nok F10ok F11ok F12ok F13ok F14nok F15ok F16ok F17ok AFR
+
D:0x0010 S:0x7321 V:1 C:0x0100 F:18 X:ok F0ok F1ok F2ok F3ok F4ok F5ok F6ok F7ok F8ok F9nok F10ok F11ok F12ok F13ok F14nok F15ok F16ok F17ok AFR
 
</pre>
 
</pre>
  
Zeile 138: Zeile 153:
  
 
==Bekannte Fehler/Macken==
 
==Bekannte Fehler/Macken==
[[Bild:Vbus_putty_vs_rss.png|thumb|Daten meiner Auswertung und die des Resol ServiceCenters. Rot markiert: fehlerhafte Sätze]]
+
[[Bild:Vbus_putty_vs_rss.png|thumb|Daten meiner Auswertung (links) und die des Resol ServiceCenters]]
Manche Felder sind falsch oder an der falschen Stelle. Im Vergleich zum Resol ServiceCenter (in Klammern) ergibt sich folgendes:
 
*Temperatursensor 12 zeigt 0.0 an (888.8 - unbelegt)
 
*Sensorbruchsmaske ist 0 (4024)
 
*Sensorkurzschlussmaske und Sensorbenutzungsmaske sind vertauscht
 
*Negative Temperaturen werden falsch angezeigt (kann aber auch an itoa liegen)
 
 
 
 
Folgendes wurde noch nicht getestet/ist unbekannt:
 
Folgendes wurde noch nicht getestet/ist unbekannt:
 
*Einstrahlung
 
*Einstrahlung
 
*Werte hinter der Fehler- & Warnungsmaske (muss ich noch in den XML-Dateien nachlesen)
 
*Werte hinter der Fehler- & Warnungsmaske (muss ich noch in den XML-Dateien nachlesen)
 
*Unbekannt-Felder
 
*Unbekannt-Felder
 +
** anscheinend immer 0x00
 
*Woher kommt der Wochentag bei der Systemzeit
 
*Woher kommt der Wochentag bei der Systemzeit
  
 
Verbesserungswürdig an der Software:
 
Verbesserungswürdig an der Software:
 
*RAM-Belegung
 
*RAM-Belegung
*Ziel der Daten (vbus_outdata) durch Pointer definierbar
 
 
*Unterstützung der weiteren Protokolle (Parametrisierung - werde ich aber vermutlich nicht in absehbarer Zeit implementieren)
 
*Unterstützung der weiteren Protokolle (Parametrisierung - werde ich aber vermutlich nicht in absehbarer Zeit implementieren)
 
*Es ist nicht ersichtlich, welche Daten durch Prüfsummenfehler ungültig sind
 
*Es ist nicht ersichtlich, welche Daten durch Prüfsummenfehler ungültig sind
 +
 +
=Hardware für den PC=
 +
Vor geraumer Zeit habe ich ein kleines Design zum Mitlesen auf dem VBus am PC gemacht. In leicht abweichender Form wurde es auch aufgebaut und hat funktioniert.
 +
Das Leiterkärtchen ist etwa 27,5 x 23,2 mm groß und lässt sich direkt an einen D-Sub-Stecker anflanschen. Der MAX3232 erzeugt RS232-kompatible Pegel und die Versorgung wird vom VBus übernommen.
 +
<gallery>
 +
  Bild:Vbus_rxo_brd.png|thumb|Layout der PC-Hardware
 +
</gallery>
 +
 +
Die Daten für EAGLE befinden sich im Download-Bereich.
 +
 +
=VBus-Adapter Nano=
 +
Die Hardware für den Empfang geht auch deutlich einfacher als in der Protokollbeschreibung und weiter oben auf der Seite gezeigt.
 +
 +
Mit einer geschickten Beschaltung eines Komparators braucht man für die Hysterese genau einen Komparator und keinen einzigen Schmitt-Trigger.
 +
 +
Das macht die Schaltung kompakt, billig und einfach aufzubauen. Ich hab einfach mal geschaut, wie klein man es machen kann, das Ergebnis lautet: 13x32,5 mm²:
 +
 +
<gallery>
 +
  resol_nano_0.1_sch.png|Schaltplan
 +
  resol_nano_0.1_assy_top.png|Bestückungsplan Oberseite
 +
  resol_nano_0.1_assy_bot.png|Bestückungsplan Unterseite
 +
  resol_nano_0.1_assy.jpg|Bestückte Leiterkarte
 +
</gallery>
 +
 +
Statt des Optokopplers OK1 und R1 sowie C1 können auch die 0-Ohm-Widerstände R10 und R11 bestückt werden, allerdings fällt dann die galvanische Trennung weg und es kann aufgrund der Vorwärtsspannung der Dioden zu einem GND-Offset kommen. Die Bestückungsoption ist allerdings nur der Vollständigkeit halber vorhanden, generell rate ich dazu, die nicht einmal 60 Cent zu investieren.
 +
 +
Die drei Halblöcher dienen zum Platzsparenden fixieren mit M2,5-Schrauben.
 +
 +
{| class="wikitable"
 +
! Menge  || Referenz    || Wert          || Package    || Reichelt Bestellcode   
 +
|-
 +
| 1      || SV1        ||                || MA04-1    ||               
 +
|-
 +
| 2      || C2, C3      || 100n          || C0603      || X7R-G0603 100N 
 +
|-
 +
| 3      || R5, R7, R8  || 10k            || R0603      || RND 0603 1 10K 
 +
|-
 +
| 1      || C5          || 10u/16V        || C1206      || KEM X7R1206 10U
 +
|-
 +
| 1      || R4          || 15k            || R0603      || RND 0603 1 15K 
 +
|-
 +
| 1      || X1          || 1751248        || 1751248    || AKL 059-02     
 +
|-
 +
| 2      || R3, R6      || 18k            || R0603      || RND 0603 1 18K 
 +
|-
 +
| 1      || R9          || 1k            || R0603      || RND 0603 1 1K 
 +
|-
 +
| 2      || C1, C4      || 1n            || C0603      || X7R-G0603 1,0N 
 +
|-
 +
| 1      || R1          || 3k3            || R0603      || RND 0603 1 3,3K
 +
|-
 +
| 1      || R2          || 68k            || R0603      || RND 0603 1 68K 
 +
|-
 +
| 1      || OK1        || 6N136          || DIL08      || 6N 136         
 +
|-
 +
| 3      || D1, D2, D5  || BAV99          || SOT23      || BAV 99 NXP     
 +
|-
 +
| 1      || IC4        || LM393D        || SO08      || LM 393 D SMD   
 +
|-
 +
| 1      || IC1        || LP2985IM5-5.0  || SOT23-DBV  || LP 2985 IM5-5.0
 +
|-
 +
| 1      || D3          || P6SMB 15A      || SMBJ      || P6SMB 15A SMD 
 +
|}
 +
 +
==Aufbau==
 +
Der Aufbau kann nach dem üblichen Vorgehen erfolgen, hier ein paar Hinweise, die es vereinfachen
 +
* D3 vor D5 bestücken, da die Pads von D3 sehr klein ausfallen
 +
* Die Oberseite kann komplett vor der Unterseite bestückt werden. Die Stiftleiste und Anschlussklemmen sind so gut wie gleich hoch
 +
 +
==Messung==
 +
Kommt auch das raus, was rauskommen soll?
 +
 +
Die Spezifikation gibt ein paar Vorgaben:
 +
 +
* Maximale Strombelastbarkeit: 35 mA
 +
* Schaltschwellen am Slave: 2,25 V Space, 2,00 V Mark
 +
 +
So die Theorie. In der Praxis hat die Schaltung eine Stromaufnahme von etwa 3 mA.
 +
 +
Den Rest musste ich an der echten Anlage messen, da in der Bastelecke weder ein Resol-Regler noch ein Protokollsimulator (der in diesem Fall relativ einfach ausfallen könnte) herumsteht.
 +
Also das Oszi eingepackt und die Schaltung bei meinen Eltern fliegend angeklemmt.
 +
 +
Bei den Schaltschwellen sieht es wie folgt aus:
 +
 +
<gallery>
 +
  resol_nano_0.1_meas_threshold.png|Ch1 hinter R8, Ch2 an ICE4A.1
 +
</gallery>
 +
 +
Die Schaltschwelle für die steigende Flanke liegt bei etwa 1,96 V, die für die fallende bei 2,44 V. In Hinblick auf die Messgenauigkeit des Oszilloskops und Toleranzen der Widerstände ein mehr als zufriedenstellendes Ergebnis.
 +
 +
Der Optokoppler bringt leichte und vor allem asymmetrische Verzögerungen mit sich.
 +
 +
Gemessen wird hier das Signal vor (Ch1 an OK1.3) und nach (Ch2 an OK1.6) dem Optokoppler. Als Stromversorgung auf der "rechten Seite" wurde eine Powerbank mit 5,1 V Ausgangsspannung verwendet. Als Schwellenwerte wurden jeweils 0,25 * Vcc und 0,75 * Vcc verwendet.
 +
 +
<gallery>
 +
  resol_nano_0.1_meas_rising.png|Verzögerung steigende Flanke
 +
  resol_nano_0.1_meas_falling.png|verzögerung fallende Flanke
 +
</gallery>
 +
 +
Bei steigender Flanke hängt der Ausgang 6,12 µs, bei fallender 8,68 µs hinterher.
 +
Die Verzögerung selbst ist hier nicht das Problem, sondern der Verzögerungsunterschied, da dieser die UART-Interfaces der Empfänger durcheinanderbringen kann.
 +
 +
Bei den verwendeten 9600 Baud entspricht eine Bitzeit ca. 104 µs. Die Verzögerungsdifferenz der Flanken beträgt mit 2,56 µs lediglich 2,5 % einer Bitzeit. Vernachlässigbar.
 +
 +
Wichtig ist ebenfalls, dass die Versorgungsspannung stabil bleibt, da sich sonst die Schaltschwellen verschieben und somit Unsinn übertragen wird. Besonders die Tatsache, dass der Optokoppler bei niedriger Busspannung aktiv ist, kann problematisch werden.
 +
 +
Das Oszi-Bild mit Probe am 5V-Ausgang des Reglers und DC-Kopplung war so unspektakulär, dass ich gar keine Bildschirmaufnahme gemacht hab. Interessanter ist da die Betrachtung der Versorgung mit AC-Kopplung:
 +
 +
<gallery>
 +
  resol_nano_0.1_noise.png|Überblick
 +
  resol_nano_0.1_noise_zoom.png|Nahansicht
 +
</gallery>
 +
 +
Bisschen hohe Spikes, wobei diese auch mit dem Probing selbst zusammenhängen können (2x 20 cm Dupont-Drähte und EZ-Hooks), ansonsten nur knapp 10 mV Ripple. Passt soweit.
 +
 +
==Leiterkarten==
 +
Es liegen noch ein paar Leiterkarten herum. Wer eine möchte, kann sich gerne bei mir melden.
 +
 +
=[[VBus-Decoder/FAQ|FAQ]]=
 +
(bitte auf die Überschrift klicken)
  
 
=Download=
 
=Download=
  
 
*[[Datei:VBus-Protokollspezifikation.pdf]] Stand: 20.04.2009
 
*[[Datei:VBus-Protokollspezifikation.pdf]] Stand: 20.04.2009
*[[Datei:VbusDecode.zip]] Version 0.1beta vom 04.03.2010 ATmega32 @ 12MHz
+
*[[Datei:VbusDecode.zip]] Version 0.2beta vom 09.03.2010 ATmega32 @ 12MHz
 +
*[[Datei:Vbus_rxo.zip]] Design-Daten für die PC-Hardware. Erstellt mit EAGLE 7.5.0
 +
*[[Datei:Vbus_nano.zip]] EAGLE-Dateien und LTspice-Simulationsdaten für den VBus-Nano
  
 
'''An dieser Stelle noch einmal vielen Dank an Resol für die Bereitstellung der Informationen und die Erlaubnis, diese hier weiter zu verteilen!'''
 
'''An dieser Stelle noch einmal vielen Dank an Resol für die Bereitstellung der Informationen und die Erlaubnis, diese hier weiter zu verteilen!'''
Zeile 168: Zeile 299:
 
* [http://www.resol.de RESOL - Elektronische Regelungen GmbH]
 
* [http://www.resol.de RESOL - Elektronische Regelungen GmbH]
 
* [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de DeltaSol® M] Regler, der dem Viessmann Vitosolic 200 "alt" in ziemlich genau entspricht
 
* [http://www.resol.de/index/produktdetail/kategorie/1/id/9/sprache/de DeltaSol® M] Regler, der dem Viessmann Vitosolic 200 "alt" in ziemlich genau entspricht
 
  
 
[[Kategorie:AVR]]
 
[[Kategorie:AVR]]
[[Kategorie:Maschinen]]
+
[[Kategorie:Energieerfassung]]
 +
[[Kategorie:Solar-Anlage]]

Version vom 24. Februar 2019, 16:06 Uhr

Das Corpus Delicti
AVR
Typ ATmega32
Takt 12 MHz
Fuses
High 0xCF
Low 0xFF
Engbedded com logo.png Details

In unserer Solaranlage arbeitet ein Viessmann Vitosolic 200, der die Regelung der Anlage übernimmt. Nach kurzer Recherche stellte sich heraus, dass es sich um eine etwas angepasste Version des RESOL DeltaSol® M handelt.

Statt der RS232-Schnittstelle hat das Teil einen Anschluss für den Viessmann-eigenen KM-Bus, zu dem keinerlei Informationen verfügbar sind.

Beim VBus sieht es schon ein wenig anders aus. In der Diskussion auf Mikrocontroller.net bin ich auf den Beitrag von Daniel Wippermann gestoßen, woraufhin ich an die angegebene Adresse eine E-Mail geschickt habe.

Keine zweieinhalb Stunden später habe ich die Dokumentation (inklusive der Erlaubnis zur Veröffentlichung, siehe Download) zum Protokolls erhalten.

Hardwareschnittstelle

Wo Rx und Tx ist, muss erraten werden ;)

Bei dem VBus handelt es sich um eine bidirektionale halbduplex Zweidrahtschnittstelle, die - entgegen diverser Meinungen - überhaupt keine Ähnlichkeiten zu RS485 hat, diesem aber nicht entspricht.

Der Master (Regel-Einheit) versorgt den Bus mit etwa 8,2V und 35mA (S. 4 in der Doku). Die Daten werden durch Spannungsabsenkung auf dem Bus übertragen. Mit der Schaltung auf Seite 5 des PDFs kann auf dem Bus sowohl gelesen, als auch geschrieben werden. Im Bild rechts meine Interpretation der Schaltung (in der noch die Abblockkondensatoren fehlen).

Über die Buchse links kann man sich mit UART (nicht RS232!) mit 9600 Baud, 8 Datenbits, 1 Stoppbit ohne Parität mit dem Master unterhalten.

Der in meiner Schaltung verwendete FET für die bidirektionale Kommunikation ist übrigens ein BS170

Protokoll

Das Protokoll des VBus ist in seiner Version 1.0 ziemlich gut handzuhaben.

Folgendes Daten habe ich zum Testen verwendet:

0xAA, 0x10, 0x00, 0x21, 0x73, 0x10, 0x00, 0x01, 0x12, 0x38, 
0x5E, 0x04, 0x5E, 0x01, 0x05, 0x39 
0x45, 0x01, 0x38, 0x22, 0x04, 0x5B 
0x38, 0x22, 0x38, 0x22, 0x05, 0x46 
0x6C, 0x01, 0x38, 0x22, 0x05, 0x33 
0x38, 0x22, 0x38, 0x22, 0x05, 0x46 
0x38, 0x22, 0x38, 0x22, 0x05, 0x46 
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F 
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F 
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F
0x38, 0x0F, 0x00, 0x00, 0x01, 0x37 
0x47, 0x00, 0x00, 0x00, 0x00, 0x38 
0x64, 0x64, 0x00, 0x00, 0x00, 0x37 
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F 
0x00, 0x00, 0x00, 0x00, 0x00, 0x7F 
0x00, 0x00, 0x43, 0x00, 0x00, 0x3C 
0x00, 0x00, 0x02, 0x00, 0x00, 0x7D 
0x01, 0x03, 0x60, 0x02, 0x04, 0x15 
0x02, 0x00, 0x00, 0x00, 0x00, 0x7D

Zu allererst wird ein 10 Byte langer Kopf gesendet, der mit einem eindeutigen Sync-Wort (0xAA) beginnt. Eindeutig heißt: An keiner anderen Stelle im Protokoll wird das MSB belegt. Man kann sich also zu jedem beliebigen Zeitpunkt in den Bus einklinken!

Gefolgt vom Sync-Wort kommen Ziel- und Quelladresse (0x0010 <= 0x7321), die Protokollversion (0x10), der ausgeführte Befehl (0x0100) und die Anzahl der danach folgenden Nutzpakete (0x12). Abschließend wird eine Prüfsumme (0x38) der zuvor gesendeten Daten übertragen.

Im Anschluss des Headers werden n Datenframes mit je 6 Byte Länge geschickt. Die ersten 4 enthalten Nutzdaten, im 5. wird ein Septett geschickt und abschließend erfolgt wieder eine Checksum.

Das Septett ist eine Ergänzung der zuvor gesendeten Nutzdaten. Da, wie oben erwähnt, das MSB nur im Sync-Wort vorkommen kann, dürfen folgende Daten kein höchstwertiges Bit enthalten. Dieses findet sich jeweils im Septett.

Das ist auch schon das gröbste. Mit Protokollversion 2.0 und 3.0 habe ich mich noch nicht auseinandergesetzt, da diese zum Erfassen der Messwerte nicht benötigt werden.

Hintergrund

Noch eine kleine Hintergrundinformation, worum es sich bei der Ziel- und Quell-Adresse handelt.

Die Quelladresse ist selbstverständlich der Regler (0x7321 = Vitosolic 200 [Regler]), die Zieladresse (0x0010) wird in der kompletten Dokumentation nur als DFA beschrieben. Dabei handelt es sich nicht um eine komische Umschreibung für einen Broadcast, sondern um die Daten für ein zusätzliches Gerät, der Datenfernanzeige.

An diese sendet der Regler alle von ihm gemessenen Werte. Neben der Regler-Identität hat der Vitosolic 200 noch die Identitäten WMZ1 und WM2 (Wärmemengenzähler).

Software

Die Software ist, wie immer, in C geschrieben. Über den Befehl Vbus_ProcessChar() kann ein Zeichen von der seriellen Schnittstelle übergeben werden. Im einfachsten Fall kann die ISR-Routine wie folgt aussehen:

ISR (USART_RXC_vect) {
	Vbus_ProcessChar(UDR);
}

Vorher muss noch der UART initialisiert werden (9600 8N1, sei() nicht vergessen!).

Die empfangenen und dekodierten Daten werden in der Variable vbus_outdata gespeichert. In dieser Variable muss auch angegeben werden, ob ein Paket gelesen werden soll:

vbus_outdata.update = 1;

Ist ein Paket vollständig angekommen, wird die valid-Eigenschaft auf 1 gesetzt. Im Demo-Code wird nach erfolgreichem Empfang das komplette Datenpaket am UART ausgegeben (bitte nicht an den Regler zurückschicken, sondern möglichst an den PC!):

int main() {

  ...

  while(1) {
    if(vbus_outdata.valid == 1) {
      vbus_outdata.valid = 0;
      VBus_Show_Values();
      vbus_outdata.update = 1;
    }
  }
}


Debug-Ausgabe

Anzeige auf dem Display. die ICs unten und rechts gehören nicht zur Schaltung

Der Debug in der Software gibt einige Informationen zur Dekodierung auf einem LC-Display aus.

Dieser Modus kann in der Datei vbus.h Zeile 35 aktiviert werden (standardmäßig deaktiviert).

Über UART würde eine Ausgabe kaum sinn machen, da man durch das langsame Senden den Empfang der Daten verpasst.

Zugegebenermaßen: ich habe einen Exoten mit LC7980-Controller und einer Auflösung von 240x40 Pixel verwendet. Die Routinen lassen sich aber halbwegs einfach auf einen anderen Displaycontroller anpassen. Die Ausgabe auf dem Display sieht wie folgt aus:

Bei jedem Erhalt eines Sync-Wortes wird "Sync" angezeigt.

Wurde der Head empfangen, wird der Displayinhalt gelöscht und folgendes ausgegeben:

D:<Ziel-Adresse> S:<Quell-Adresse> V:<Protokoll-Version> C:<Befehl> F:<Anzahl Frames> X:<Prüfsumme ok|nok>

Danach wird, wenn die Prüfsumme ok ist jedoch das falsche Protokoll angegeben wurde, die Meldung "!V1.0->dropped " ausgegeben. Hat das Paket das "falsche" Adress-Pärchen, wird "Wrong addr->dropped " angezeigt.

Kommen diese beiden Meldungen nicht, werden Informationen über die dekodierten Frames ausgegeben:

 F<Frame-Index><Prüfsumme ok|nok>

Nachdem alle Frames empfangen wurden, wird ein "AFR" (all frames received) ausgegeben

Im Ganzen kann solch eine Ausgabe wie folgt aussehen:

Sync [Display wird geleert]
D:0x0010 S:0x7321 V:1 C:0x0100 F:18 X:ok F0ok F1ok F2ok F3ok F4ok F5ok F6ok F7ok F8ok F9nok F10ok F11ok F12ok F13ok F14nok F15ok F16ok F17ok AFR

Gleiches Beispiel mit meinen Testdaten, nur dass hier (im Gegensatz zu den Daten!!) Frame 9 und 14 ungültig sind.

Zuordnung der Datenfelder

Die Zuordnung der empfangenen Daten kann man relativ einfach zu den entsprechenden Feldern zuordnen.

Im der Datei %ProgramFiles%\RESOL\ServiceCenterFull\eclipse\plugins\de.resol.servicecenter.vbus.<Device>\VBusSpecification<Device>.xml

findet man alle Zuordnungen der Felder. Achtung: es kann Lücken geben - dadurch sind in meinem Code die "unknown"-Felder entstanden.

Bekannte Fehler/Macken

Daten meiner Auswertung (links) und die des Resol ServiceCenters

Folgendes wurde noch nicht getestet/ist unbekannt:

  • Einstrahlung
  • Werte hinter der Fehler- & Warnungsmaske (muss ich noch in den XML-Dateien nachlesen)
  • Unbekannt-Felder
    • anscheinend immer 0x00
  • Woher kommt der Wochentag bei der Systemzeit

Verbesserungswürdig an der Software:

  • RAM-Belegung
  • Unterstützung der weiteren Protokolle (Parametrisierung - werde ich aber vermutlich nicht in absehbarer Zeit implementieren)
  • Es ist nicht ersichtlich, welche Daten durch Prüfsummenfehler ungültig sind

Hardware für den PC

Vor geraumer Zeit habe ich ein kleines Design zum Mitlesen auf dem VBus am PC gemacht. In leicht abweichender Form wurde es auch aufgebaut und hat funktioniert. Das Leiterkärtchen ist etwa 27,5 x 23,2 mm groß und lässt sich direkt an einen D-Sub-Stecker anflanschen. Der MAX3232 erzeugt RS232-kompatible Pegel und die Versorgung wird vom VBus übernommen.

Die Daten für EAGLE befinden sich im Download-Bereich.

VBus-Adapter Nano

Die Hardware für den Empfang geht auch deutlich einfacher als in der Protokollbeschreibung und weiter oben auf der Seite gezeigt.

Mit einer geschickten Beschaltung eines Komparators braucht man für die Hysterese genau einen Komparator und keinen einzigen Schmitt-Trigger.

Das macht die Schaltung kompakt, billig und einfach aufzubauen. Ich hab einfach mal geschaut, wie klein man es machen kann, das Ergebnis lautet: 13x32,5 mm²:

Statt des Optokopplers OK1 und R1 sowie C1 können auch die 0-Ohm-Widerstände R10 und R11 bestückt werden, allerdings fällt dann die galvanische Trennung weg und es kann aufgrund der Vorwärtsspannung der Dioden zu einem GND-Offset kommen. Die Bestückungsoption ist allerdings nur der Vollständigkeit halber vorhanden, generell rate ich dazu, die nicht einmal 60 Cent zu investieren.

Die drei Halblöcher dienen zum Platzsparenden fixieren mit M2,5-Schrauben.

Menge Referenz Wert Package Reichelt Bestellcode
1 SV1 MA04-1
2 C2, C3 100n C0603 X7R-G0603 100N
3 R5, R7, R8 10k R0603 RND 0603 1 10K
1 C5 10u/16V C1206 KEM X7R1206 10U
1 R4 15k R0603 RND 0603 1 15K
1 X1 1751248 1751248 AKL 059-02
2 R3, R6 18k R0603 RND 0603 1 18K
1 R9 1k R0603 RND 0603 1 1K
2 C1, C4 1n C0603 X7R-G0603 1,0N
1 R1 3k3 R0603 RND 0603 1 3,3K
1 R2 68k R0603 RND 0603 1 68K
1 OK1 6N136 DIL08 6N 136
3 D1, D2, D5 BAV99 SOT23 BAV 99 NXP
1 IC4 LM393D SO08 LM 393 D SMD
1 IC1 LP2985IM5-5.0 SOT23-DBV LP 2985 IM5-5.0
1 D3 P6SMB 15A SMBJ P6SMB 15A SMD

Aufbau

Der Aufbau kann nach dem üblichen Vorgehen erfolgen, hier ein paar Hinweise, die es vereinfachen

  • D3 vor D5 bestücken, da die Pads von D3 sehr klein ausfallen
  • Die Oberseite kann komplett vor der Unterseite bestückt werden. Die Stiftleiste und Anschlussklemmen sind so gut wie gleich hoch

Messung

Kommt auch das raus, was rauskommen soll?

Die Spezifikation gibt ein paar Vorgaben:

  • Maximale Strombelastbarkeit: 35 mA
  • Schaltschwellen am Slave: 2,25 V Space, 2,00 V Mark

So die Theorie. In der Praxis hat die Schaltung eine Stromaufnahme von etwa 3 mA.

Den Rest musste ich an der echten Anlage messen, da in der Bastelecke weder ein Resol-Regler noch ein Protokollsimulator (der in diesem Fall relativ einfach ausfallen könnte) herumsteht. Also das Oszi eingepackt und die Schaltung bei meinen Eltern fliegend angeklemmt.

Bei den Schaltschwellen sieht es wie folgt aus:

Die Schaltschwelle für die steigende Flanke liegt bei etwa 1,96 V, die für die fallende bei 2,44 V. In Hinblick auf die Messgenauigkeit des Oszilloskops und Toleranzen der Widerstände ein mehr als zufriedenstellendes Ergebnis.

Der Optokoppler bringt leichte und vor allem asymmetrische Verzögerungen mit sich.

Gemessen wird hier das Signal vor (Ch1 an OK1.3) und nach (Ch2 an OK1.6) dem Optokoppler. Als Stromversorgung auf der "rechten Seite" wurde eine Powerbank mit 5,1 V Ausgangsspannung verwendet. Als Schwellenwerte wurden jeweils 0,25 * Vcc und 0,75 * Vcc verwendet.

Bei steigender Flanke hängt der Ausgang 6,12 µs, bei fallender 8,68 µs hinterher. Die Verzögerung selbst ist hier nicht das Problem, sondern der Verzögerungsunterschied, da dieser die UART-Interfaces der Empfänger durcheinanderbringen kann.

Bei den verwendeten 9600 Baud entspricht eine Bitzeit ca. 104 µs. Die Verzögerungsdifferenz der Flanken beträgt mit 2,56 µs lediglich 2,5 % einer Bitzeit. Vernachlässigbar.

Wichtig ist ebenfalls, dass die Versorgungsspannung stabil bleibt, da sich sonst die Schaltschwellen verschieben und somit Unsinn übertragen wird. Besonders die Tatsache, dass der Optokoppler bei niedriger Busspannung aktiv ist, kann problematisch werden.

Das Oszi-Bild mit Probe am 5V-Ausgang des Reglers und DC-Kopplung war so unspektakulär, dass ich gar keine Bildschirmaufnahme gemacht hab. Interessanter ist da die Betrachtung der Versorgung mit AC-Kopplung:

Bisschen hohe Spikes, wobei diese auch mit dem Probing selbst zusammenhängen können (2x 20 cm Dupont-Drähte und EZ-Hooks), ansonsten nur knapp 10 mV Ripple. Passt soweit.

Leiterkarten

Es liegen noch ein paar Leiterkarten herum. Wer eine möchte, kann sich gerne bei mir melden.

FAQ

(bitte auf die Überschrift klicken)

Download

An dieser Stelle noch einmal vielen Dank an Resol für die Bereitstellung der Informationen und die Erlaubnis, diese hier weiter zu verteilen!

Weblinks