I2C übersprechen?

Übersprechen: sicher nich!, die flane is grad andersrum...

Max schrieb:
> Übersprechen: sicher nich!, die flane is grad andersrum...

Ok, wenn es kein übersprechen ist, woher könnte dann das Problem des 
sporadischen Ausfalls der kommunikation kommen?

>Die Glitches entstehen bei einer
>Flanke des Taktsignals, allerdings nur sporadisch.

So ein Peak entsteht wenn der I2C Master zum lesen
des Acknowledge Bits die Leitung frei gibt. Das ist normal.
Zähl mal nach ob der Peak immer zwischen dem 8ten und 9ten
Clockpuls kommt.

Die glitches sollten keine Rolle spielen, da sie bei fallender Flanke 
auftreten, ich vemute es ist die Umschaltung des ack-signals des slave.

ok, kann es denn trotzdem aufgrund der länge der leitung zu problemen 
kommen, die ein nichterreichen des busteilnehmers erklären würden

>Die Leitung ist ca. 1,2m lang (kürzer geht leider nicht),
>die Taktfrequenz beträgt 400kHz (SCL).

Dann geh halt mal auf 100kHz.

Geh mal mit einem Oszi (Analogkanal) an deine Signalleitungen drann, 
dein Bild oben wirkt etwas zu digital. Dein Tek kann da zwar schön 0 und 
1 trennen, aber ob die verwendeten Schaltkreise das auch so sehen?  Wo 
hast du den I2C-Pull-UP? Eventuell splitten und an jedes Ende des 
Busses. I2C-Repeater möglich? Andere Leitung getestet (z.B 
Flachbandkabel, jede 2.Ader GND), aber übersprechen ist es eh nicht,

>Die Leitung ist ca. 1,2m lang (kürzer geht leider nicht),
>die Taktfrequenz beträgt 400kHz (SCL).

Ähm - was "I²C" bedeutet ist auch bekannt? Das ist ein Bus, um 
innerhalb einer Platine oder eines Geräts zu kommunizieren. Dass I²C 
immer wieder auch für größere Entfernungen missbraucht wird, ändert 
nichts an der ursprünglichen Intention von Philips.
Für Störungsfreie Übertragung verwendet man differentielle Übertragung, 
RS485 z.B. oder zumindest ordentliche Pegel wie RS232.

holger schrieb:
>>Die Leitung ist ca. 1,2m lang (kürzer geht leider nicht),
>>die Taktfrequenz beträgt 400kHz (SCL).
>
> Dann geh halt mal auf 100kHz.

100kHz hatte ich schon ausprobiert, ergab keine besserung

dummschwaetzer schrieb:
> Geh mal mit einem Oszi (Analogkanal) an deine Signalleitungen drann,
> dein Bild oben wirkt etwas zu digital. Dein Tek kann da zwar schön 0 und
> 1 trennen, aber ob die verwendeten Schaltkreise das auch so sehen?  Wo
> hast du den I2C-Pull-UP? Eventuell splitten und an jedes Ende des
> Busses. I2C-Repeater möglich? Andere Leitung getestet (z.B
> Flachbandkabel, jede 2.Ader GND), aber übersprechen ist es eh nicht,

Ja, im analogen Modus sind Peaks so nicht erkennbar. Der Schwellwert ist 
auf 1,4V eingestellt, ab da an interpretiert das Oscar diese als High.
Die Pull-Ups befinden sich auf der Steuerplatine, die 1,2m vom 
Farbsensor entfernt ist. Da der µC mit 5V arbeitet der Farbsensor aber 
3,3V benötigt, befindet sich dazwischen noch ein Pegelwandlung. Die 
Pegelwandlung ist nach der AppNote von NXP aufgebaut.

Marvin M. schrieb:
> Für Störungsfreie Übertragung verwendet man differentielle Übertragung,
> RS485 z.B. oder zumindest ordentliche Pegel wie RS232.

Haben wir aus dem Oszillogramm nicht gerade gelernt, dass es KEINE 
Übersprechen ist. Die Spikes treten alle 9 Takt. Könnte das etwas mit 
der Richtungsumschaltung zu tun haben?

Hast du mal versucht, die Spikes etwas unkonventionell angemessen mit 
einem kleinen C wegzubügeln? Aber nicht übertreiben ;-)

Wolfgang schrieb:
> Hast du mal versucht, die Spikes etwas unkonventionell angemessen mit
> einem kleinen C wegzubügeln? Aber nicht übertreiben ;-)

Jop, 100pF jeweils von SDA, SCL nach GND, keine besserung.

das hat zwar nicht unbedingt was mit deinem Übertragungsproblem zu tun, 
aber wenn du die Pegelwandlung mit dem MOSFET machen willst, muss die 
Source auf die 3,3V Seite. Du hast sie in der Zeichnung oben auf der 5V 
Seite, und dann leitet die Substratdiode bei High-Pegel.

Ein analoges Oszibild von beiden Enden der Leitung wäre vielleicht doch 
hilfreich, um den Fehler zu finden...

schöne Grüße

Achim S.

Marvin M. schrieb:
> Ähm - was "I²C" bedeutet ist auch bekannt? Das ist ein Bus, um
> innerhalb einer Platine oder eines Geräts zu kommunizieren. Dass I²C
> immer wieder auch für größere Entfernungen missbraucht wird, ändert
> nichts an der ursprünglichen Intention von Philips.

Das ist aber schon ein paar Jahre her. NXP hat inzwischen ein bisschen 
Lesestoff für längere Übertragungswege in der App-Note AN10658 
zusammengestellt.
www.nxp.com/documents/application_note/AN10658.pdf

Achim S. schrieb:
> das hat zwar nicht unbedingt was mit deinem Übertragungsproblem zu tun,
> aber wenn du die Pegelwandlung mit dem MOSFET machen willst, muss die
> Source auf die 3,3V Seite. Du hast sie in der Zeichnung oben auf der 5V
> Seite, und dann leitet die Substratdiode bei High-Pegel.
>
> Ein analoges Oszibild von beiden Enden der Leitung wäre vielleicht doch
> hilfreich, um den Fehler zu finden...
>
> schöne Grüße
>
> Achim S.

Hmm, ja da sind wohl drain und source vertauscht, sollte aber denke ich 
mal bei mosfet nichts machen. Das komische ist ja, es lief eine ganze 
zeit lang ohne probleme, und heute macht es plötzlich probleme.
Analoge Oskarbilder kann ich morgen ggf. nachreichen wenn ich in der FH 
bin.

I2C schrieb:
> sollte aber denke ich mal bei mosfet nichts machen.

... bis auf die auch im Datenblatt eingezeichnete Diode mit Kathode an 
Drain und Anode an Source ...

ne, die Verpolung macht fast nichts, außer dass die angestrebte 
Pegelwandlung nicht funktioniert. Lies die AppNote von NXP noch mal 
durch.

Das es in der Vergangenheit lief und erst seit heute Probleme macht, ist 
eine ziemlich wichtige Info, die ich vorher wohl überlesen habe.

In solchen Fällen sollte man sich fragen: was hat sich verändert, seit 
es das letzte mal stabil lief. Die Antwort lautet spontan meistens 
"nichts", aber nach einigem Nachdenken kommt man dann doch auf den 
eigentlichen Grund des Problems.

schöne Grüße

Achim S.

>Jop, 100pF jeweils von SDA, SCL nach GND, keine besserung.

Scheiss Idee. Damit macht man das virtuelle Kabel noch mal
gefühlte 2m länger.

>Das komische ist ja, es lief eine ganze
>zeit lang ohne probleme, und heute macht es plötzlich probleme.

Dann wird es wohl Zeit auch die Software in Frage zu stellen.
Oder dein Handy hat die Hardware zerstört, oder dein heisser
Finger.

Mach das Kabel doch einfach mal kürzer.
Dann kannst du wenigstens da einen Fehler ausschliessen.

Ja, ich werde es morgen zunächst mit einem kürzeren Kabel ausprobieren.
Vllt. liegt es ja an der trockenen Luft, etc...

Ich habe mal etwas ähnliches, als ein Arduino als Master immer nach Bit 
15 einen kurzen Peak auf die Leitung setzte.
Ich habe das dann über einen Widerstand gelöst, das der Peak unter dem 
Level für High blieb.

400 KHz finde ich bei der Leitungslänge auch ganz schön schnell.

So ich hab noch mal ein paar Bilder gemacht, wir haben jetzt die Leitung 
durch ein Netzwerkkabel getauscht, soweit scheint die Kommunikation 
wieder zu funktionieren. Allerdings kommt bes beim aufnehmen des 
analogen Oszilloskopsignal zu komischen "zwischen" Pegel. Diese stellt 
das Oskar mit einem ausrufezeichen dar.
Anbei die Bilder

Das zweite Bild zeigt jeweils das Datensignal am ende und am anfang der 
Leitung gemessen. Kann der Zwischenpegel möglicherweise an Reflexionen 
liegen?

Diese Zwischenpegel können doch dadurch entstehen, daß beide Devices auf 
beiden Seiten des Pegelwandlers Signale auf der DATA-Leitung senden.

Wie soll sonst das ACK übertragen werden ? Und der Pegelwandler ist ja 
auch ein Haufen FETs=Widerstand mit Dioden. Sieh Dir die Schaltung mal 
genau an.
(Master gibt DATA frei, Pull-Up würde ja gerne hochziehen, aber auf der 
anderen Seite der Diode zieht Slave jetzt gegen Gnd, bis, ja, bis wann 
denn?

Reflexionen kannst Du hier ausschließen.

Hallo,

die "Zwischenpegel" ergeben sich tatsächlich daraus, dass dort nicht 
mehr der Master sondern der Slave die Leitung nach low treibt, um das 
ACK zu geben. Auch der kurze "Glitch", den du zu Beginn verdächtigt 
hast, gehört zum ACK und stört nicht (wie es Holger ja auch schon 
erklärt hat).

Bedenklich finde ich aber die Absolutpegel, die du erreichst.
Das Signal schaltet laut Oszi zwischen 1V und 3V, und das sowohl auf der 
Master-Seite (mit 5V Supply) als auch auf der Slave-Seite (mit 3,3V 
Supply). Das ist untypisch für einen IIC-Bus und passt nicht zu dem 
Schaltbild, das du gestern gepostet hast. Entweder stimmt was mit der 
Messung nicht (GND Clip angeschlossen? Uncal-Setting im Oszi?), oder der 
Bus wird stärker belastet, als er sollte (nicht nur von den oben 
gezeigten 3,6kOhm Pullups).

schöne Grüße

Achim S.

Ja, das kann möglicherweise am nicht angeschlossenen GND liegen, es 
handelt sich um eine Mixed Signal Oscilloscope Tek MSO 2024, wir hatten 
den GND der digitalen Anschlussleitung mit unseren GND verbunden und 
deswegen den von den Tastköpfen weggelassen, da wir davon ausgegangen 
sind das diese intern verbunden sind.

Ahh, jetzt verstehe ich was du meinst, ich habe in beiden Fällen bei 
3,3V gemessen. Nur einmal vor- und einmal hinter der Busleitung.

ok, verstanden

Aber selbst wenn das Oszi einen Offset von 1V haben sollte und beide 
Messungen aus dem 3,3V-Bereich stammen, ist der Swing des Signals mit 2V 
immer noch zu klein. (Und ich würde eigentlich auch davon ausgehen, dass 
der GND des Logikteils und der Analogkanäle intern verbunden sind, und 
dass darüber kein GND-Shift von 1V entstehen kann.) Also richtig 
"gesund" sehen die Pegel immer noch nicht aus...

schöne Grüße

Achim S.

@Tom
>Haben wir aus dem Oszillogramm nicht gerade gelernt, dass es KEINE
>Übersprechen ist. Die Spikes treten alle 9 Takt. Könnte das etwas mit
>der Richtungsumschaltung zu tun haben?

Habe ich mich auf die Spikes bezogen? Nein.
Funktioniert die Datenübertragung störungsfrei? Nein.
Ist I²C die richtig Übertragungsmethode? Offenbar fraglich.

@Wolfgang
>Das ist aber schon ein paar Jahre her. NXP hat inzwischen ein bisschen
>Lesestoff für längere Übertragungswege in der App-Note AN10658
>zusammengestellt.
>www.nxp.com/documents/application_note/AN10658.pdf

Kenne ich. Und dennoch verwende ich I²C nicht. Warum, das erfährt der TO 
momentan am eigenen Leibe.
Ich habe gelernt, nicht lange an Symptomen herumzubasteln, sondern die 
Ursache zu beseitigen - und seit ich I²C nicht mehr für längere 
Übertragungswege nutze, habe ich Ruhe.
Da muss nur der schon angesprochene LKW durch das Hoftor fahren oder ein 
neu angeschaffter PC ist eben doch nicht ganz EMV-konform und schon 
passt es nicht mehr. Bis hin zu statischer Entladung (bei diesem Wetter 
sehr wahrscheinlich) hat irgendetwas geschrottet / angetickt, so dass 
eine vorher "gerade noch" gute Verbindung nun eben nicht mehr 
funktioniert.

Ich würde, wie schon mehrfach vorgeschlagen, die Geschwindigkeit 
massiv herunterfahren. Versuche mal 10kHz und darunter. Geschirmte 
Kabel (aber "richtig" geerdet) sind sowieso ein Muss.
Bei sporadischen Fehlern würde ich mal einen Datenlogger über längere 
Zeit anhängen, die kurzen Oszi-Snapshots sind wenig aussagekräftig.

Ahh, jetzt verstehe ich was du meinst, ich habe in beiden Fällen bei 
3,3V gemessen. Nur einmal vor- und einmal hinter der Busleitung.

Achim S. schrieb:
> ok, verstanden
>
> Aber selbst wenn das Oszi einen Offset von 1V haben sollte und beide
> Messungen aus dem 3,3V-Bereich stammen, ist der Swing des Signals mit 2V
> immer noch zu klein. (Und ich würde eigentlich auch davon ausgehen, dass
> der GND des Logikteils und der Analogkanäle intern verbunden sind, und
> dass darüber kein GND-Shift von 1V entstehen kann.) Also richtig
> "gesund" sehen die Pegel immer noch nicht aus...
>
> schöne Grüße
>
> Achim S.

die übertragung funktioniert nun wieder, allerdings habe ich mir nochmal 
das phänomen angesehen, dass die busleitung nicht richtig auf masse 
gezogen wird. Ich denke das wird wohl tatsächlich mit den vertauschten 
drain und source liegen. Ich werde die Schaltung mal umlöten, und dann 
nochmal berichten

Passt wahrscheinlich nicht ganz zum Thema aber ich habe einen 
merkwürdigen
zusammenhang in einer I2C Kommunikation in einer Bastelei von mir 
entdeckt.

Kann mir irgendjemand vielleicht ansatzweise erklären, warum bei 
niedrigen Freqeunzen (~ <250kHz) die Kommunikation nicht mehr 
funktioniert, aber bei allen Freqeunzen (bis zu 400kHz Normwert) die 
Datenübertragung einwandfrei funktioniert?


*Das Flachbandkabel wirkt bei höheren Freqeunzen induktiver und die 
Induktivitätsbeläge können kapazitives Verhalten kompensieren, was bei 
einen Open-Drain Bus Vorteile hat?

*Fehlanpassung des Pullup Widerstandes bei tiefen Freqeunzen? (Im 
Datenblatt des ATMEGA644 gibt es einen Abschnitt zum Berechnen des 
Pullup Widerstandes in Abhängigkeit der Freqeunz und der Kapazitiven 
Last die die Portpins treiben müssen)

*Etwas völlig anderes?

Den Grund warum unsere Taktleitung (SCL) und Datenleitung (SDA) die 0V 
nicht erreicht haben, haben wir jetzt gefunden. Die beiden MosFETs 
hatten wohl einen weg, ein umtausch durch zwei neue errbrachte den 
gewünschten effekt.
Möglicherweise sind diese durch statische elek. gestorben, konnte aber 
nicht geklärt werden. Danke für die Hilfe.

mfg I2C

Ist doch gut, wenn man nicht alles dem Logikanalysator überläßt, sondern 
mal guckt, was wirklich auf der Leitung los ist. Ein Analogsignal sagt 
mehr als "tausend Fragezeichen".