CAN Bus Augendiagramm

damit hast Du als Anwender ja recht wenig zu tun da das vom Treiber 
erledigt wird...

schau Dir mal das Datenblatt vom PCA82C250 an, Philips hat in seinen 
Datenblätter die timings recht gut erklärt.
Wobei es hier sicherlich um die typ. Timings des Treibers geht und nicht 
um die min- und maxratings der Spezifikation....

Gero schrieb:
> damit hast Du als Anwender ja recht wenig zu tun

Er scheint aber eher Entwickler zu sein. Und da kann in der 
Entwicklungsphase auch mal etwas komisch aussehen. Beispielsweise bei 
Verwendung von fehlerhaften Kabeln, falschen Abschlußwiderständen, 
falsch verlöteten RS-Widerständen usw.

Fachlich kann ich leider keinen Beitrag leisten, bisher habe ich nur das 
Oszi verwendet um den Verlauf ansich darzustellen aber keine 
Augendiagramme. Sind die überhaupt sinnvoll für den CAN machbar? Die 
Flanken können ja nach 1, 2, 3, 4 oder 5 Bit kommen.

Das ist keine so grosse Hexerei. Wenn Du einfach mal drauflos probieren 
magst triggerst Du mit Deinem Oszi einfach mal auf eine der CAN Signal 
Flanken und suchst dann nach der "Persistence" Funktion auf Deinem Oszi.

Anleitungen gibt's oft vom Oszi Hersteller online. Suche nach "eye 
pattern", "eye diagram" oder allenfalls "jitter Analysis" oder halt eben 
"persistence".

Hexer schrieb:
> Das ist keine so grosse Hexerei. Wenn Du einfach mal drauflos
> probieren magst triggerst Du mit Deinem Oszi einfach mal auf eine der
> CAN Signal Flanken und suchst dann nach der "Persistence" Funktion auf
> Deinem Oszi.
>
> Anleitungen gibt's oft vom Oszi Hersteller online. Suche nach "eye
> pattern", "eye diagram" oder allenfalls "jitter Analysis" oder halt eben
> "persistence".

Das Problem bei CAN ist wohl, dass die Flanke nicht immer zum Anfang der 
Bitzeit kommt und erst recht nicht immer zum gleichen Zeitpunkt 
innerhalb der bitzeit. Du wirst das ganze dekodieren muessen und daraus 
ein Triggersignal ableiten...

Guest schrieb:
> Das Problem bei CAN ist wohl, dass die Flanke nicht immer zum Anfang der
> Bitzeit kommt und erst recht nicht immer zum gleichen Zeitpunkt
> innerhalb der bitzeit. Du wirst das ganze dekodieren muessen und daraus
> ein Triggersignal ableiten...

Schwanzbeisser. Genau darum soll er ja auf die Flanke des "Rohsignales" 
triggern, damit sich da das "Auge" öffnen kann und danach die Sample 
Time eintritt, bevor sich das "Auge" wieder schliesst... Mal so 
untechnisch bildlich gesprochen.

Hexer schrieb:
> Guest schrieb:
> Das Problem bei CAN ist wohl, dass die Flanke nicht immer zum Anfang der
> Bitzeit kommt und erst recht nicht immer zum gleichen Zeitpunkt
> innerhalb der bitzeit. Du wirst das ganze dekodieren muessen und daraus
> ein Triggersignal ableiten...
>
> Schwanzbeisser. Genau darum soll er ja auf die Flanke des "Rohsignales"
> triggern, damit sich da das "Auge" öffnen kann und danach die Sample
> Time eintritt, bevor sich das "Auge" wieder schliesst... Mal so
> untechnisch bildlich gesprochen.

Dann schliesst es sich halt zu unterschiedlichen Zeiten. Die 
verschiedenen Oeffnungszeiten gehoeren halt zum CAN Auge dazu deswegen 
sollte man sie auch abbilden.

Ein klassisches Augendiagramm wie es bei eriellen Punkt zu Punkt Links 
genutzt wird macht bei CAN überhaupt keinen Sinn.

Verstehe erst wie CAN funktioniert insb. die bitweise Arbitrierung der 
ACK Mechanismus und das CAN Bittiming / Synchronisation. Dann geht Dir 
ein Licht auf :-)