CAN Status LED einfach machbar?

[Rudolph R. (rudolph)]

Ich plane gerade eine sogenannte Koppelkiste, das ist eine Box die 
zwischen ein Steuergerät und das Bordnetz geklemmt wird damit man die 
verschiedenen Signale abgreifen oder auch unterbrechen kann.
Oder man kann das Ding auch einfach nur dazu benutzen um mit dem 
Steuergerät was auszuprobieren.

Jetzt hat unser Steuergerät sechs CANs, drei LINs, so unter anderem.

Die Kollegen sind jetzt auf die Idee gekommen, dass sie LEDs haben 
wollen an der Box die anzeigen sollen, dass die CAN-Kommunikation 
funktioniert.
LED an = CAN läuft
LED aus = CAN hat ein Problem

Fünf CANs sind dabei nur HighSpeed und dürften immer bei 500kBit laufen, 
theorethisch geht mit dem Gerät auch CAN-FD.
Der sechste CAN kann auf LowSpeed umgestellt werden, damit sollte das 
dann auch laufen.

"Schliess da einfach mal eine LED dran an."

Nun ja, ich war zwar nicht überzeugt, dass da irgendwas bei raus kommt, 
habe dem Ansinnen aber jetzt einfach mal nachgegeben und das 
ausprobiert.
So wie im Anhang, die Schaltung hatte ich gerade zufällig als Teil von 
was anderem rum liegen.

Der BCR135 hat eingebaute Widerstände, 10k in Reihe, 47k gegen GND.

Das erste ist mal, dass damit die Bus-Pegel verbiege.
Das gibt zwar keine Error-Frames, aber schön ist anders.
Direkt eine LED an den Bus dürfte noch hässlicher werden.

Funktionieren tut es nicht.
Zwei Bus-Teilnehmer dran und Botschaften -> LEDs an.
Einen Bus-Teilnehmer abziehen -> LEDs an.

In Ruhe sind CANL und CANH bei 2,5V, oder sind sie zumindest ohne die 
Schaltung.
CANH geht auf etwa 3,5V hoch und CANL auf etwa 1,4V runter für eine "1".

Okay, damit wäre als erstes vielleicht der Transistor durch einen 
Komparator zu ersetzen mit einer Schwelle bei 3V oder so.
Alternativ könnten man einen Transceiver verbauen.

Dann kommt als nächstes das Problem mit der Logik.

Wenn der Bus läuft kommen chaotisch "1" Bits.
Chaotisch, weil das ja bei beliebigen Botschaften funktionieren soll.
Oh ja, Bus-Ruhe ist ja eigentlich auch ein gültiger Zustand.

Wenn der Bus nicht läuft weil nur ein Teilnehmer dran ist und dieser 
senden will, fehlt das ACK und im einfachsten Fall zappelt der Bus dann 
erstmal richtig, weil der CAN-Controller immer wieder und wieder 
versucht, die Botschaft zu senden.
-> noch mehr Bit-Salat

Wie der Bus bei verdrehten Leitungen aussieht habe ich mir gar nicht 
mehr angesehen, das sollte aber auch abgedeckt werden.
Genauso wie Fehl-Anpassung bei fehlendem Abschluss-Widerstand zu 
niedrigem Widerstand...

Übersehe ich noch was, oder ist das "einfach" und passiv wirklich nicht 
machbar?

Aktiv bekomme ich das nicht unter, für einen Controller mit sechs CANs 
habe ich definitiv keinen Platz und sechs Controller wären auch zu fett.
Wobei das selbst aktiv schwierig ist, der zusätzliche Controller darf ja 
weder senden, noch auch nur ein ACK setzen.

[Harald (Gast)]

Rudolph R. schrieb:
> das sollte aber auch abgedeckt werden.
> Genauso wie Fehl-Anpassung bei fehlendem Abschluss-Widerstand zu
> niedrigem Widerstand...
>
> Übersehe ich noch was, oder ist das "einfach" und passiv wirklich nicht
> machbar?

Also sowohl die analoge Seite (Anpassung etc.) als auch die digitale 
Ebene mit 1-2 LEDs abzudecken dürfte schon auf den ersten Blick etwas 
unrealistisch erscheinen.

Man könnte für die digitale Signalbeurteilung einen CAN-Transceiver (wie 
z.B. MCP2551) dranhängen und daran eine LED. Dann könnte man allein 
schon visuell einige Betriebszustände auseinander halten (nichts, 
Dauersendung, flackern...).

Für die analoge Signalbeurteilung könnte man einfach BNC-Buchsen 
einsetzen, wo man schnell und unkompliziert ein Scope beliebiger 
Preisklasse dranhängen kann. An der "Güte" des Rechtecksignals kann man 
auch ohne Expertenwissen schon viel ablesen. Falls es mobil sein soll 
geht auch ein Akkuscope oder vielleicht sogar eines der minimalistischen 
China-LCD-Scopes für wenige Euros aus Aliexpress...

[Rudolph (Gast)]

Harald schrieb:
> Man könnte für die digitale Signalbeurteilung einen CAN-Transceiver (wie
> z.B. MCP2551) dranhängen und daran eine LED. Dann könnte man allein
> schon visuell einige Betriebszustände auseinander halten (nichts,
> Dauersendung, flackern...).

Ich habe mal einen CAN-Transceiver an den Bus geklemmt und meine 
LED-Schaltung von oben an den RXD-Ausgang.

Das bringt überhaupt nichts.

Erstmal "flackert" da bei 500kBit sowieso nichts.

Im ersten Bild habe ich eine zwei-Byte Botschaft, die Buslast ist 
ziemlich niedrig, drei Botschaften die jeweils alle 10 ms gesendet 
werden, eine Botschaft hat acht Byte, die andere zwei.
Die Busruhe wird ja innerhalb der 10ms nur zwei Mal um so 200µs 
unterbrochen, einmal um 500µs, die LED ist rechnerisch 91% an.

Im zweiten Bild ist ein Bus-Teilnehmer abgezogen und durch das fehlende 
ACK fängt der andere Teilnehmer immer wieder an zu versuchen die 
Botschaft zu senden.
Die LED wird etwas dunkler dabei.

Im dritten Bild ist auch nur ein Bus-Teilnehmer dran, zusätzlich ist 
aber auch noch der Terminierungs-Widerstand abgezogen.
Damit wird die LED wieder heller.

Eine unmissverständliche Information kann ich daraus nicht ableiten.
Die Helligkeiten unterscheiden sich nicht so richtig deutlich und nur im 
direkten Vergleich.

Vor allem, bei höherer Buslast wäre die LED auch im Normal-Betrieb 
dunkler.

Vielleicht kann man die Pausen nutzen mit einem retriggerbaren Monoflop, 
wenn für länger als 900µs (200µs) keine Änderung da ist, LED an.

Das sprengt langsam den Rahmen...

Harald schrieb:
> Für die analoge Signalbeurteilung könnte man einfach BNC-Buchsen
> einsetzen...

Buchsen zum Abgriff sind sowieso dran, wenn auch 2mm.
Nur, das Messen wäre ja der nächste Schritt, die LED soll ja "ganz 
einfach" anzeigen, ob der Bus grundsätzlich okay ist...

[H. (Gast)]

Rudolph schrieb:
> Das bringt überhaupt nichts.
> Erstmal "flackert" da bei 500kBit sowieso nichts.
> Eine unmissverständliche Information kann ich daraus nicht ableiten.

Tja, was soll man Dir raten - Du wolltest etwas sehr einfaches, 
möglichst nur mit einer LED. Wenn bei euch mit fast 100% Buslast 
gearbeitet wird dann geht das eben nicht.

Rudolph schrieb:
> retriggerbaren Monoflop,
> wenn für länger als 900µs (200µs) keine Änderung da ist, LED an.
>
> Das sprengt langsam den Rahmen...

Wenn schon ein Monoflop den Rahmen sprengt, dann braucht man Dir 
wahrscheinlich ebenso wenig zu folgendem raten:

- Teilerbaustein 4040 (o.ä.) zwischen MCP2551 und LED
- kleiner nicht-CAN fähiger uC, der sich nur die Flankenwechsel 
anschaut, dafür aber alle 6 Leitungen geeignet "visualisiert"
- 6 Stück LPC11C24 (uC mit intr. Transceiver) werten die jeweiligen 
Botschaften aus

[Rudolph (Gast)]

Die Idee ist jetzt begraben.
Die Forderung, dass die Kiste einfach und kompakt bleiben soll 
überwiegt.

Als Lösung für das Problem würde ich auch einen kleinen Controller mit 
CAN sehen der nicht senden darf und der alle Botschaften empfängt.
Wenn eine Botschaft als gültig durch geht wird eine LED eingeschaltet 
und 100ms oder so später wieder ausgeschaltet.

Das trifft nur weder die Anforderung "einfach", noch bekomme ich das auf 
der Platine mit unter.
Das müsste als Zusatz-Platine dahinter.

[blackengineer (Gast)]

Ich fürchte die beiden LEDs im Schaltbild oben sind einfach verpolt.

[Rudolph (Gast)]

blackengineer schrieb:
> Ich fürchte die beiden LEDs im Schaltbild oben sind einfach verpolt.

Da hast Du völlig recht, der Schaltplan ist falsch.

Aber wo ist jetzt der Grund das schlapp 1 Jahr nach Beendigung des 
Themas wieder hoch zu holen? :-)

[Bülent C. (mirki)]

Rudolph schrieb:
> Aber wo ist jetzt der Grund das schlapp 1 Jahr nach Beendigung des
> Themas wieder hoch zu holen? :-)

...wenn jemand diese unnütze Schaltung nachbaut, das zumindestens die 
LED's leuchten ;-)

[Rudolph R. (rudolph)]

Bülent C. schrieb:
> ...wenn jemand diese unnütze Schaltung nachbaut, das zumindestens die
> LED's leuchten ;-)

Jemand der das wirklich nachbaut wird aber kaum was vom Beitrag gelesen 
haben, geschweige denn den Hinweis. :-)