freebus.org

Hallo Freebusler,

ich konnte mit mehreren Controlern keinen oder nur instabilen Betrieb realisieren.

Darauf hin habe ich die Schaltung auf dem Steckbrett aufgebaut und analysiert.

Das Ergebnis ist, dass das Sendesignal bei den ersten drei Bits verfälscht ist. Dadurch gehen in der Regel die Schreiboperationen auf den Bus schief. Lesen scheint einwandfrei zu funktionieren, da ich die Parameter in den LPC laden kann.

Die Bilder Zeigen die Signale an Pin 3 vom LPC CHB bzw. Gate und Drain vom 2N7000.

Wer weiss Rat?


Viele Grüße

Erwin

Hallo Erwin,

was bei deiner Messung auffällt sind die kleinen Pegel, die schon am Bus anliegen bevor der LPC senden will. Im oberen Bild auf CHA ist das deutlich zu sehen. Ist ein anderer Sender am Bus? Das Signal deutet klassisch auf eine Buskollision hin. Ich hab zur Sicherheit nochmal bei meiner Schaltung nachgemessen, da sehen alle Bits gleich aus.

Gruß
Andreas

Hallo Andreas,

danke für die Antwort. Gut beobachtet.

Die Messung habe ich zwischen dem 68Ohm Widerstand und dem 2N7000 gemacht.

Die niedrige Spannung interpretiere ich so, dass der 2N7000 dauernd etwas leitet und dadurch der Spannungsabfall entsteht.

Die Busspannung liegt bei 28V, allerdings mit der falschen Signalform.

Da ich dieses Phänomen an verschiedenen Baugruppen gemessen habe, könnte es eventuell an den verwendeten 2N7000 liegen?

Gruß

Erwin

Hi Erwin,

die "kleinen" Pegel haben eine Dauer ähnlich wie das Bit, also ca. 35us. Das kann doch kein Zufall sein. Das muss von irgendwoher gesteuert erfolgt sein. Wenn der 2N7000 dauernd etwas leiten würde, wäre der Pegel dann nicht dauerhaft sichtbar? Merkwürdig ist es allemal.

Gruß
Andreas (kubi)

Hallo

wenn der 2N7000 den Pegel dauernd um 2V runterziehen würde wäre er wohl in Sekunden
Schutt und Asche.
Das runterziehen von 2V über ca 35µs deutet auf einen anderen Sender hin.
Der 68 Ohm ist im Kollisionsfalle nicht so berauschend, besser wäre da eine ZD18V mit 22OHM
in Reihe. Optimal wäre natürlich die neue Grundschaltung

LG

oldi

Hallo!

Habe auch 4 8-fach-Aktoren (noch mit der alten Grundschaltung/Controller LPC3.21a) seit einiger Zeit in Betrieb.
Die Aktoren sind im Versuchsaufbau monatelang ohne Fehler im Labortrisch gelaufen.

Die Aktoren laufen nun im Echtbetrieb im Haus. Netzteil, Taster, Jal-Aktoren, Schnittstelle sind kommerzielle Produkte.
Der Normalbetrieb funktioniert ohne Probleme.
Wenn alle Geäte am Bus hängen, kann ich jedoch mit der ETS nichts programmieren. Die Auflistung der phys. Adressen bzw. Geräteinfo geht auch nicht. Wenn ich Gruppentelegramme per ETS sende, reagieren aber alle Geräte korrekt.
Der Busmonitor zeigt beim Programmieren Telegramme mit nicht vorhandenen Adressen bzw. Datenmüll.

Ich hab leider kein Oszi, um die Signale zu prüfen.
Folgendes hab ich getestet:
- Alle Geräte am Bus: Betrieb OK, Programmieren geht nicht
- Alle Geräte mit Ausnahme Freebus-Aktoren am Bus: Betieb OK, Programmieren OK
- Nur Freebus-Aktoren am Netzteil+Schnittstelle: Programmieren OK, Betrieb nicht testbar

Ich dachte auch schon an doppelt vergebene Adressen oder dgl. aber das dürfte alles passen.

Hat jemand eine Idee, was das sein kann?

LG Charly

hallo. Die 3.21 dürfte noch mit 68 ohm R als begrenzung sein. Das ist unter Ümständen ein Problem
da die 0 bei ACK den Bus zu tief zieht.
Hier hilft dir am besten die neue Grundschaltung ab.
Zur Not kannst auch den 68 OHM gegen eine ZD18(1,3W)+22R in Reihe ersetzen.
Teste mal ob dein original Bus mit nur einem FB Gerät funktioniert.
wenn ja, dann siehe oben

LG
Andreas

Hallo,

nachdem die bisherigen Ergebnisse nicht erklärbar sind, habe ich folgenden Versuchsaufbau gemacht:

Die neue Sendestufe (allerdings nur mit 4,5 mH statt 150 mH) auf dem Steckbrett aufgebaut (unterer TEil des Steckboards).

Mit einem Atmel Evulationsboard (von Pollin) habe ich per Software ein Signal erzeugt. Dies hat allerdings 5V-Pegel.

Die Oszibilder zeigen die Signale CHA gemessen am C und CHB das EIB Signal, wenn

1. das vom Atmel erzeugte Signal direkt auf den C anschliesse. LPC ist nicht angeschlossen.

2. das Vom Atmel erzeugte Signal wird eingespeist; LPC ist auch angeschlossen.

3. nur das vom LPC erzeugte Signal liegt an. Erzeugt durch die Abfrage der Geräteinfo.

Die Bilder zeigen, dass die Signale vom Atmel erzeugt eine sauberes Signal erzeugen, auch wenn der LPC parallel mit angeschlossen ist.

Wenn der LPC die Steuerung übernimmt, kommt es wieder zum schon beobachteten Effekt.


Gruß

Erwin

Hmmm,
was mir auffällt ist, dass der bus vor dem LPC signal schon mal low war.
Wie kann das sein? Der LPC sendet nicht, wenn der bus nicht mindestens
5,2ms high ist. Also dürfte der Ankoppler selber nicht auf "Bus belegt" aufpassen.

LG
Andreas

Eines ist schon wieder auffällig, hatte ich aber schonmal drauf hingewiesen:

Auf dem Bus ist anfangs eine Null, ohne daß der LPC sendet. Jedenfalls interpretiere ich die Signale so, daß die rote Kurve die Ansteuerung des FET ist und die grüne der Bus selbst. Nun schau mal den Anfang deines Oszi-Bildes an, da sieht man das.

Weiterhin sind die "Schultern" in deinen Signalen so nicht von einem einzelnen FET erzeugbar. Schon gar nicht, wenn er mit solch sauberen Rechtecksignalen, wie die gemessenen roten angesteuert wird.

-> Ich vermute stark, daß hier eine Überlagerung zweier Signale vorliegt.

Solange aber nicht klar ist wer da sendet, kann man schwer nach der ursache suchen. Wie ist bei der letzten Messung der Versuchsaufbau gewesen? Ausschließlich LPC und Programmierschnittstelle für ETS am Bus?

Ich würde unheimlich gerne die Ursache für dieses Verhalten rauskriegen, kann es aber absolut nicht reproduzieren. Ich habe die 3.42er Schaltung auf Platine in folgenden Umgebungen getestet:
- Test-Bus, Labor-NT 29V, original Drossel, nur LPC und BCU(für ets)
- Test-Bus, wie oben jedoch mit 21V
- Test-Bus, wie oben, 29V und 21V mit original Tastern und LPC
- Test-Bus, 29V, Drossel, Originale und mehrere LPC Boards
- Echt-Bus, 29V, stark belastet (ca 70 Originale, 350mA DC), diverse freebus-Module
-> Resultat: Programmieren und Auslesen, auch über device-editor, funktioniert immer auf Anhieb. Keinerlei Aussetzer. Signal ist sauber, so wie im Oszi-Bild, das ich weiter oben schon gepostet habe. Der Hub ist bei unterschiedlichen DC-Eigenschaften des Busses immer OK.

Derweil ich auf deine Antwort warte, werde ich mir nochmal die Soft anschauen. Normalerweise wartet der LPC, daß der Bus frei ist bevor er sendet UND prüft während des Sendens entsprechend der spec auf Kollisionen... but who knows.

Gruß
Andreas (kubi)

Hallo Andreas,

die Signale im dritten Bild entstehen durch den LPC am Koppelkondensator gemessen.

Wenn ich über die Geräteinfo den LPC abfrage dann versucht die ETS über vielfache Requsts die Daten vom LPC zu bekommen.

D. h. diese Siganlform ist in dieser Zeit mehr als zehnmal zu sehen in ca. ein bis zwei Minuten bis die ETS aufgibt. Auf den Busmon der ETS sieht man, dass immer wieder Anfragen gestellt werden.

Das komische dabei ist, dass ich diese Verhalten mit 68 Ohm, mit ZD18 und auch mit der neuen Schaltung auf dem Steckbrett und auch auf drei verschiedenen Controller-Platinen reproduzierbar beobachten kann.

Interessant dabei ist, dass mit dem 5V Signal vom Atmel der Signalverlauf wie erwartet ist.
Kann es sein, dass der LPC für die Ansteuerung des Koppelkondesators zu schmalbrüstig ist?

In der Praxis sind die Auswirkungen ähnlich wie sie auch Charly in seinem Beitrag anspricht.
Die Controller lassen sich mal mehr oder weniger in mehreren Durchläufen mit Fehlermeldungen programmieren. Sie reagieren auch auf Objekte vom Bus.
Es ist aber kein stabiler Betrieb möglich.

Zu meiner Anlage:

Ich betreibe zwei Linien mit zwei Netzteilen und Linienkoppler. Über eine FT1.2-Schnittstelle ist ein Gira Homserver in Betrieb.

Als Besonderheit ist auch noch die LWZ303 von Stiebel-Eltron zu sehen, die intern einen EIB zur Steuerung benutzt und nach außen auch einige Objekte zur Verfügung stellt. Diese hat eine feste phy. Adresse 15/15/255 und ist nicht EIB zertifiziert.

Vielleicht hilft das weiter.

Gruß

Erwin

Als Besonderheit ist auch noch die LWZ303 von Stiebel-Eltron zu sehen, die intern einen EIB zur Steuerung benutzt und nach außen auch einige Objekte zur Verfügung stellt. Diese hat eine feste phy. Adresse 15/15/255 und ist nicht EIB zertifiziert.

Vielleicht hilft das weiter.

vielleicht;-)
Also bei mir hat der Busankoppler diese Adresse, da nichts anderes zugeteilt. Solltest mal prüfen ob da nicht
eine doppelvergabe ist.

LG

Andreas

Der LPC kann problemlos den Strom bringen, hat m.E. die gleichen, wenn nicht sogar bessere Werte als der AVR. Der Unterschied zwischen 3,3V und 5V ist die Ansteuerung des FET. Deswegen die Vorspannung des Gates, somit hat er die gleichen Eigenschaften wie "nackt" unter 5V.

Bei zig einwandfrei funktionierenden Geräten bei verschiedenen Leuten in unteschiedlichen Umgebungen, würde ich den Fehler auch nicht ausschließlich in der Controller-Hardware suchen. Das wäre zu einfach und führt in die falsche Richtung. Hier muß ein Zusammenspiel verschiedener Dinge ungünstig zusammentreffen. Das sollten wir versuchen zu identifizieren.

Wäre dem nicht so, müsste man etlichen Leuten erklären warum ihre funktionierenden Geräte eigentlich gar nicht funktionieren dürften. (klingt nach Unsinn ... ist es auch.)

Ich werde mal exakt die von dir beschriebene Umgebung aufbauen und auch die Geräteabfrage über ets laufen lassen... mal schauen ob ich da was erkennen kann. Ich bin jedoch skeptisch, denn alle andern Symptome von dir (Programmieren geht nicht, etc.) kann ich eben nicht feststellen, und das obwohl ich neben dem uralt 4051 auch die lpc versionen 3.1, 3.2, 3.31 und die neue 3.42 am bus habe. Aber irgendwoher muß es ja kommen...

Gruß
Andreas

Ich habe jetzt mehrfach die Geräteinfo über ETS und laufendem Gruppenmonitor laufen lassen. Ich habe keine "kaputten" Telegramme sehen können. Im Anhang ist die Aufzeichnung als PDF, vielleicht hilft ein Vergleich weiter. Auch mit dem Oszi ist nichts ungewöhnliches zu entdecken.

Es wäre schön, wenn man das reproduzieren könnte, da ich sonst nicht weiß wo ich ansetzen könnte.

Gruß
Andreas (kubi)

Hallo Erwin!

Ist das oben im ersten Oszi-Bild dargestellte Byte das erste gesendete Byte des LPC-Controllers, oder irgend eines aus der Mitte eines Telegramms?

Wenns das erste ist, dürfte der LPC hier schon Müll senden oder in eine andere Übertragung reinfunken.
Laut Beschreibung unter "Grundlagen / Infos" sollte das erste Byte (Kontrollbyte) so aussehen:

S | 0 | 0 | p0 | p1 | 1 | R | 0 | 1 | P | St ....

S Startbit = 0
p0, p1 Priority. sollte wahrscheinlich 11 sein
R Repeat-Flag. Sollte beim ersten senden auch 1 sein
P Parity. Abhängig vom Rest
St Stop-Bit

Ergibt für mich: 0001111011....

Genau so sieht das Oszi-Bild von Andreas aus.
Wenn ich die Bits bei dir richtig zähle wäre das : 00011001...

Das wäre gar nicht gültig

Jemand eine Idee dazu?

LG Charly