Läuft: Heizung mit eBus-Schnittstelle

Reinhart · 09 November 2015, 16:58:22

Ok, wenn du das schon gemessen hast, dann sehe ich jetzt in deiner aufgebauten Schaltung keine Fehler.
Mit Pin3 und Pin4 meine ich die Bezeichnung am Gleichrichter. Pah hat die Anschlüsse des Gleichrichters in der Schaltung mit mit 1,2,3,4 bezeichnet. 4 liegt auf Masse und 3 ist der positive Anschluss des eBus.

Was mir allerdings komisch vorkommt, ist das nur ein kurzes High-Signal sichtbar ist, dies ist ja schon am ersten Messpunkt so gewesen. Logischerweise könnte dann nur noch der Seriellwandler beim Sendeweg defekt sein und eben nur eine positive Flanke ausgeben und den Rest "verschlucken".

LG
Reinhart

yellowpinky · 09 November 2015, 17:33:43

Der kurze Impuls stört mich auch, vielleicht ist das eine Art Sync Bit das gespiegelt werden muss um dann mit der "echten" Sendung zu beginnen.
Die Bitlänge würde zu 2400 bit/s passen, da das Bit 4,4ms lang ist..
Wie gesagt die Schleifenmessung (siehe Bild Schleifenmessung) funktioniert ja, allerdings statt dem Rasp mit einem Windows PC mit Terminalprogramm .
Darum verstehe ich das Ganze nicht. Bin überzeut dass es ein ganz einfacher Fehler ist.... wenn ich ihn nur finden würde.
Könnte den Rasp noch tauschen und Linux und ebusd neu aufspielen !?

Danke für deine Mühe
LGD

Prof. Dr. Peter Henning · 09 November 2015, 18:27:47

Hm. Sind die vier Dioden der Gleichrichterschaltung richtig eingebaut ? Das kommt mir an der Stelle sehr seltsam vor.

LG

pah

yellowpinky · 09 November 2015, 18:37:56

Hab in schon überprüft.
Und die Dioden mit dem Bauteiltester gecheckt

LGD

phantom · 09 November 2015, 20:05:19

Zitat von: john30 am 07 November 2015, 15:26:16
So, ich denke das Problem ist mit commit https://github.com/john30/ebusd/commit/d402325 gelöst.
Es wär cool, wenn Du das nochmal gegen Deinen ersten Versuch testen könntest (RealCOM-Mode mit tty-driver-Kernel-Modul von Moxa), da sich das nicht so trivial nachstellen lässt.

Hallo John,
ich habe den ebusd per git pull komplett aktualisiert (nun ebusd 2.0.0-preview) und alle drei Test nochmal durchgeführt:
1. RealCom / 2. RealCom mit aquiretimeout / 3. an TCP-Server (s. Logfiles)

Im RealCom-Mode (1.+2.) gibt es nun Timeouts anstelle der Endlosschleife -> gut so. Doch diese Betriebsart des NPort-5110 scheint einfach nicht schnell genug zu sein.
Im TCP-Server-Mode klappt es wie gehabt.

Ich denke es macht wenig Sinn, den Weg vom ebusd über die im RealCom-Mode emulierte virtuelle tty-Schnittstelle weiter zu verfolgen.
Der Weg über TCP klappt ja und ist bei den meisten Serial-Ethernet-Wandlern vorhanden (manchmal auch per UDP)

Gruß Dirk

john30 · 11 November 2015, 07:53:11

Zitat von: phantom am 09 November 2015, 20:05:19
ich habe den ebusd per git pull komplett aktualisiert (nun ebusd 2.0.0-preview) und alle drei Test nochmal durchgeführt:
1. RealCom / 2. RealCom mit aquiretimeout / 3. an TCP-Server (s. Logfiles)

Im RealCom-Mode (1.+2.) gibt es nun Timeouts anstelle der Endlosschleife -> gut so. Doch diese Betriebsart des NPort-5110 scheint einfach nicht schnell genug zu sein.
Im TCP-Server-Mode klappt es wie gehabt.

Hallo Dirk,
Danke fürs Testen, dann kann ich das abhaken.
John

yellowpinky · 22 November 2015, 20:52:20

ZitatSchaltungstechnisch sieht es ja bis jetzt nicht so schlecht aus, leider hast du die wichtigste Messung am Collector des BD645 vergessen.

Die Messung nach R6 scheint auch in Ordnung zu sein, denn R6 begrenzt ja den Basis-Emitter Strom, sonst wäre es ja ein Kurzschluß am Transistor. Wenn nun ein Signal am R6 kommt, müsste der Darlingtontransistor durchschalten (und ordentlich Strom verstärken) und die Zenerdiode begrenzt hier den Strom/Spannung auf der Collector-Emitterstrecke. Was dieser BD645 nun letztlich macht ist das was "am eBus ankommt". Nimm bei dieser Messung bitte Pin4 des Gleichrichters als Masse. Du kannst dann auch noch am Pin3 des Gleichrichters messen, auch da muss das Signal dann sichtbar sein, weil auch hier die Spannung einbrechen muss damit am Master des eBus dies dann als Signal erkannt wird.

Hallo;
Ich war leider die letzen 2 Wochen unterwegs und konnte daher nicht testen.
Nun aber die Messungen zu meinem Schaltungsproblem.
Habe mit dem Oszi direkt an der Z-Diode gemessen (GL-Pin3 zu Collector T1)... siehe Bild.
Dies scheint auch in Ordnung zu sein.
Messe ich aber Gleichrichter Pin 3 zu Pin4 kommt sehe ich mein Signal nicht mehr.
Das würde ja heißen das der Transistor T1 (BD 645) nicht durchschaltet !?
Den hab ich aber auch schon getauscht... oder hab ich da noch ein Potential Problem ?
Hab auch noch ein Foto von meinem bestückten Print beigelegt, sieht aber nach all den Experimenten nicht mehr so Top aus

Bild "Messung Z_Diode":
Blau=Z-Diode, Rot=TTY

Danke Euch
Daniel

Reinhart · 27 November 2015, 18:44:31

Ich kann dir nur sagen, du bist nicht alleine mit dem Fehler. Seit gestern in der Früh bekomme ich ebenfalls nur mehr die Broadcasts durch, der Rest sind in etwa die Fehlermeldungen die du hast. Es hat jetzt alles ein Jahr ohne Probleme funktioniert. Nach einigen Messungen musste ich feststellen, das meine Schaltung (ebenso wie deine) im Prinzip funktioniert aber ich nichts senden kann.

Bei den Messungen habe ich aber gleich noch einen Pulldown Widerstand (TxD mit 10 K gegen Masse) eingelötet weil der Pegel an den Eingängen des Cmos (Pin 8+9) bei Low 1,6 V betrug was nicht sauber ist (oder es zeigt sich hier schon der Fehler). Soweit ich aber bis jetzt beurteilen kann, deutet alles auf einen Defekt des USB Seriell Konverters, da ich keine Impulse an TxD bekomme. Es ist nur ein Impuls kurz beim einstecken, das wars.

Leider habe ich einen Konverter mit Prolific Chip 2303 und für den habe ich noch keinen Windows10 Treiber (der auch funktioniert) gefunden, somit kann ich keinen Loopback Test am PC durchführen. Der neue Seriell Konverter ist schon bestellt, kommt aber erst am Mo oder Di.

Wenn ich mir deine Fehlermeldungen so anschaue, dann haben die große Ähnlichkeiten wie mit meinen jetzt.

LG

stinch · 29 November 2015, 05:21:13

Hallo John,

ich habe gestern die aktuelle 2.0 preview installiert und die Option scanconfig gestartet. Dabei werden die meisten csv files geladen. Nur die pmw und pms files werden scheinbar nicht geladen, obwohl diese auch vorhanden sind. Hast du eine Idee hierfür?

Code Auswählen

pi@raspberrypi /etc/ebusd $ ls
broadcast.csv  _templates.csv  vaillant
pi@raspberrypi /etc/ebusd $ cd vaillant
pi@raspberrypi /etc/ebusd/vaillant $ ls
05.vd2.csv  05.vl8.csv         08.ehp.csv      15.f47.csv    23.ehp.cc.csv     26.solsy.hc.csv  50.v61.csv    broadcast.csv    scan.csv
05.vd3.csv  05.vl9.csv         0a.pmw.hwc.csv  15.ui.csv     23.solsy.cc.csv   3c.rcc.5.csv     52.mc2.4.csv  e0.omu.csv       _templates.csv
05.vd4.csv  06.pms.csv         15.430.csv      15.uih.csv    25.ehp.hwc.csv    50.ehp.mc.csv    53.mc2.5.csv  ec.solsy.sc.csv
05.vd6.csv  08.bai.HW7401.csv  15.470.csv      1c.rcc.4.csv  25.solsy.hwc.csv  50.solsy.mc.csv  75.rcc.csv    ed.pms.sc.csv

Code Auswählen

localhost: info
version: ebusd 2.0.0-preview.ce4bc56
signal: acquired
symbol rate: 48
masters: 5
messages: 656
address 01: master #2, seen
address 03: master #3, seen
address 06: slave of 01, seen, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402"
address 08: slave of 03, seen, scanned "MF=Vaillant;ID=BAI00;SW=0703;HW=7401", loaded "vaillant/08.bai.HW7401.csv"
address 0a: slave, seen, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 10: master #6, seen
address 12: slave, seen, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"
address 15: slave of 10, seen, scanned "MF=Vaillant;ID=UI   ;SW=0507;HW=6201", loaded "vaillant/15.ui.csv"
address 23: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/23.solsy.cc.csv"
address 25: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/25.solsy.hwc.csv"
address 26: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/26.solsy.hc.csv"
address 50: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/50.solsy.mc.csv"
address ec: slave, seen, scanned "MF=Vaillant;ID=SOLSY;SW=0500;HW=6301", loaded "vaillant/ec.solsy.sc.csv"
address ed: slave, seen, scanned "MF=Vaillant;ID=PMS02;SW=0209;HW=8402"
address f7: master #24, seen
address fc: slave of f7, seen, scanned "MF=Vaillant;ID=PMW01;SW=0205;HW=8302"

yellowpinky · 29 November 2015, 11:44:47

Ich habe meinen Fehler am ebusd Adapter gefunden
Anscheinend hat T1 wirklich nicht durchgesteuert.
Habe nun den R6 von 22k auf 10k geändert und es funktioniert

@Reinhart:
Habe den 10k PullDown bei mir auch eingebaut - kann ja nicht schaden ein definiertes Potential zu haben

DANKE an alle die mich bei der Suche unterstützt haben

LG

Prof. Dr. Peter Henning · 29 November 2015, 12:36:10

Hm. War denn da auch wirklich ein Darlingtontransistor drin ? Der sollte mit 22k problemlos anzusteuern sein - mit dem BD645 geht es jedenfalls problemlos.

LG

pah

yellowpinky · 29 November 2015, 13:09:14

@ pah
.. war und ist ein BD645... kann ich mir auch nicht erklären $:-\$
Sieht man auch auf meinem Bestückungsfoto das ich gepostet habe.

LG

Reinhart · 29 November 2015, 13:26:42

@yellowpinky

Freut mich wenn du denn Fehler endlich gefunden hast!
Wundert mich auch, das der Darlington Transistor bei 22 K Ohm nicht korrekt durchschaltet, aber wie du siehst sind es meist nur Kleinigkeiten. Es gibt hier mehre Typen vom BD648 wie A,B oder C sollte aber hauptsächlich die Spannung betreffen und nicht die Verstärkung.
Auch meine Schaltung funktioniert wieder. Bei mir war die Zenerdiode defekt, aber ich habe gleich ein paar Messpunkte aufgenommen wenn wieder jemand einen Fehler beim Sendebetrieb sucht.

Vorgangsweise bei der Sendemessung:
Ich habe dazu statisch gemessen (nicht am eBus) und mit einem 24 Volt Netzgerät über einen 5 Watt Vorwiderstand von 330 Ohm eingespeist. Den Seriel Wandler habe ich einfach zur Speisung in einen Laptop gesteckt. Sollte der Tx Ausgang nicht auf 0 V liegen, dann Kabel vom Wandler (nur Tx) abziehen und einen Pulldown Widerstand am Eingang (Pin8,9) legen damit hier definiert 0 V zur Messung anliegt. Wir müssen für die Sende Messung nämlich den 4011 zwingen, dass er am Pin10 "High" wird.

Die von mir ermittelten Spannungen können natürlich bei anderen je nach Streuung der Bauteile etwas abweichen. Ich habe zB. eine Zenerdiode mit 8,2 Volt eingebaut.

Code Auswählen

2015-11-29 06:26:55.271 [update notice] update myCustom1 Status11: nosignal;40;0;15;-;-;-;-;-0.188
2015-11-29 06:26:55.541 [update notice] update myCustom Status02: auto;60;70.0;70;54.0
2015-11-29 06:26:59.293 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:03.323 [update notice] update myCustom Status01: 53.0;45.0;-0.438;47.0;46.0;error
2015-11-29 06:27:05.268 [update notice] update broadcast outsidetemp QQ=10: -3.188
2015-11-29 06:27:09.344 [update notice] update bc Mode QQ=10: standby
2015-11-29 06:27:11.934 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:11.981 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.025 [bus error] send to 08: ERR: read timeout, retry
2015-11-29 06:27:12.069 [bus error] send to 08: ERR: read timeout

so haben die Fehlermeldungen im Log bei einem Sendeversuch ausgesehen (ebusd Version 2.0 Preview vom 28.11.2015). Alle Broadcast Meldungen waren natürlich ok.

LG

yellowpinky · 29 November 2015, 14:10:50

@ Reinhart
Die Simulation mit einem Netzgerät hatte ich ja auch gemacht !
Das Schlimme war nur, das hat alles korrekt funktioniert.
Das hat mich etwas auf die falsche "Fährte" gelockt.

.. aber jetzt haben wir es ja geschafft.. DANKE nochmal !!

LG

john30 · 01 Dezember 2015, 07:29:39

Zitat von: stinch am 29 November 2015, 05:21:13
ich habe gestern die aktuelle 2.0 preview installiert und die Option scanconfig gestartet. Dabei werden die meisten csv files geladen. Nur die pmw und pms files werden scheinbar nicht geladen, obwohl diese auch vorhanden sind. Hast du eine Idee hierfür?

Sollte mit dem commit https://github.com/john30/ebusd/commit/5f50c99 von gerade eben behoben sein.
Merci fürs Bescheid geben!
John