OBD 2 Adapter als CAN interface

[Lars L. (lloesche)]

Guten Morgen liebes Forum,

Ich spiele mit dem Gedanken, in meiner Bastelkistenumgebung mit CAN zu 
experimentieren.

Erstmal was verhältnismäßig simples, zwei oder drei Mikrocontroller die 
miteinander fröhlich kommunizieren.
Ich möchte auch gerne meinen Rechner irgendwie in den Bus hängen um 
Pakete zu empfangen und zu senden.

Nun habe ich einen billigen OBD2-Bluetooth Adapter den ich hin und 
wieder für mein Auto benutze.
Da stelle ich mir die Frage, ob es nicht möglich wäre, den Adapter als 
Interface für den Rechner zu verwenden?

Zur Klarstellung, das soll kein KFZ-Projekt werden.

Danke, Gruss,
Lars

[Schorschi (Gast)]

Hi,

such mal nach ELM327 mit Arduino. Da gibt es schon fertige Libs die man 
als Beispiel verwenden kann.

Gruß.

[MBterm (Gast)]

Schorschi schrieb:
> Hi,
>
> such mal nach ELM327 mit Arduino. Da gibt es schon fertige Libs die man
> als Beispiel verwenden kann.
>
> Gruß.

Stimmt. Damit kannst du die meisten Autos auslesen.

[Gerd B. (bertr2d2)]

Gerade am Anfang würde ich ein vollwertiges CAN-Interface nehmen. Das 
ermöglicht auch eine erweiterte Fehlerdiagnose. Sofern Linux eine Option 
ist bietet sich der Banana Pi M1 (integrierter CAN-Controller) oder RPi 
mit MCP2515 an.

ELM327 sind langsam und decken nur eine Teilmenge der CAN-Möglichkeiten 
ab.

[Lars L. (lloesche)]

Gerd B. schrieb:
> ELM327 sind langsam und decken nur eine Teilmenge der CAN-Möglichkeiten
> ab.

Ok, das ist mal ein Punkt. Aber was genau meinst du mit Teilmenge?

Die Frage nach der prinzipiellen Verwendbarkeit so eines OBD Adapters 
bezog sich hauptsächlich auf die Tatsache das er nunmal im Haus ist.

[Soul E. (Gast)]

Lars L. schrieb:

> Ok, das ist mal ein Punkt. Aber was genau meinst du mit Teilmenge?

Stell es Dir vor wie ein Gerät mit LAN-Schnittstelle, das ausschließlich 
das BitTorrent-Protokoll versteht. Ja, man kann damit ein Netzwerk 
prüfen. Es damit Schritt für Schritt in Betrieb nehmen ist aber nicht 
möglich.


> Die Frage nach der prinzipiellen Verwendbarkeit so eines OBD Adapters
> bezog sich hauptsächlich auf die Tatsache das er nunmal im Haus ist.

Der Adapter sendet Diagnoseanforderungen am Bus und erwartet 
entsprechende Antworten. Wenn Du also mit Deinem zweiten Teilnehmer ein 
OBD-Diagnosegateway implementierst dann kannst Du das testen.

Ansonsten wäre irgend ein anderes Gerät, was einfach zyklisch Daten 
sendet, für den Anfang praktischer. Z.B. ein ESP-Sensor, oder ein 
Evalboard mit bekannt funktionierender Demo-Software.

[Reiner O. (elux)]

Soul E. schrieb:

> Der Adapter sendet Diagnoseanforderungen am Bus und erwartet
> entsprechende Antworten. Wenn Du also mit Deinem zweiten Teilnehmer ein
> OBD-Diagnosegateway implementierst dann kannst Du das testen.

Ganz genau so ist es.
Das Datenblatt des ELM327 ist ja nicht geheim, lies es doch mal!

Am einfachsten ist es wahrscheinlich, (Atmel-) Arduinos und diese 
billigen "Ni Ren" CAN - SPI Interfaces zu nehmen. Dazu gibt es genügend 
Bibliotheken und Beispielsketche und kosten tut der Kram auch nix.

Und im Gegensatz zum ebenso möglichen Banana Pi M1 (oder Orange Pi Zero 
mit "Ni Ren") hast Du mit den Atmels keine Probleme bei den 
Pegeln/Stromversorgung; ein nicht zu unterschätzender Punkt: 
Hardwareprobleme ausschliessen zu können, wenn man mit etwas 
"Unbekanntem" anfängt zu experimentieren...



Gruß

Elux

[Michael K. (Gast)]

Gerd B. schrieb:
> Gerade am Anfang würde ich ein vollwertiges CAN-Interface nehmen.

Der Meinung bin ich auch. Sonst bastelt man mehr am Interface als am 
eigentlichen Projekt. Ich hab dafür den USBtin aufgebaut.

[Gerd B. (bertr2d2)]

Michael K. schrieb:
> Gerd B. schrieb:
>> Gerade am Anfang würde ich ein vollwertiges CAN-Interface nehmen.
>
> Der Meinung bin ich auch. Sonst bastelt man mehr am Interface als am
> eigentlichen Projekt.

ich sehe das genauso. Ich stand Anfangs auch vor dem gleichen Problem 
beim CAN-Einstieg. Man braucht etwas, auf das man sich verlassen kann; 
auf etwas wo man weiss das es funktioniert.

> Ich hab dafür den USBtin aufgebaut.

Der USBtin bzw. die SLCAN API hat aber keine erweiterten Möglichkeiten 
wie Erkennung von Bus-Fehlern. Hier mal ein Beispiel des Banana Pis mit 
Linux und SocketCAN bei dem ein CAN-Frame auf den Bus gesendet wird wo 
kein anderer Teilnehmer verbunden ist:

BPi:~# candump -tA -a -xe can0,0:0,#FFFFFFFF
 (2020-05-13 10:27:29.477281)  can0  RX - -  2000008C   [8]  00 08 81 00 00 00 88 00   ERRORFRAME
  controller-problem{tx-error-warning}
  protocol-violation{{single-bit-error,error-on-tx}{}}
  bus-error
  error-counter-tx-rx{{136}{0}}
 (2020-05-13 10:27:29.477287)  can0  RX - -  20000004   [8]  00 20 00 00 00 00 88 00   ERRORFRAME
  controller-problem{tx-error-passive}
  error-counter-tx-rx{{136}{0}}
 (2020-05-13 10:27:29.483440)  can0  RX - -  20000040   [8]  00 00 00 00 00 00 8F 00   ERRORFRAME
  bus-off
  error-counter-tx-rx{{143}{0}}
 (2020-05-13 10:27:29.500108)  can0  RX - -  20000100   [8]  00 00 00 00 00 00 00 00   ERRORFRAME
  restarted-after-bus-off

Gerade am Anfang sind solche Fehlermeldungen sehr hilfreich.
Der RPi, oder jeder beliebige SBC mit MCP2515 liefert so etwas auch.

Gruß

Gerd