Hallo Forum,

Bisherige OBD Systeme funktioneren größtenteils als native MS Windows Anwendung oder IOS/Android App, die sich mittles drahtlosem oder drahtgebunden Anschluss auf eine serielle Schnittstelle in einem kleinen Adpater (Dongle) in der OBD2 Schnittstelle verbinden. Jede Anwendung wurde für eine spzielles Betriebssystem entwickelt und kann in der Regel nur hier eingesetzt werden.

Hier die Idee wie aus meiner Sicht die Zukunf aussehen müsste:

Der OBD Dongle hat eine WIFI Accespoint als Schnittstelle integriert und versorgt sicht nach wie vor aus der OBD2 Schnittstelle mit 12 Volt. Vorteil des Accesspoints ist die Kompatibilität mit alle Smartphones, die sich in der Regel nur auf einen Accesspoint verbinden können oder wollen.
In diesem AccessPoint wird nicht nur ein "Remote Serial Interface" angeboten, sondern auch noch der viel modernere websocket service angeboten. Vorteil des Websockets ist, dass sich eine HTML5 Seite direkt auf den Service verbindet und so die Fahrzeugdaten anzapfen kann. Die bisher verwendeten AT Befehle zur Steuerung des OBD Interfaces werden nun durch die websocket Schnittstelle geschickt. Die Plafformabhängigkeit wurde somit aufgelöst, und der Erstellung von HTML5 Seiten bzw, Webapps steht nichts im wege.

Diese Lösung möchte ich umsetzen.

Folgende Fragen habe ich ans Forum:

• Gibt es bereits eine OBD2 Hardware, die einen Wifi Accespoint integriert hat ?
• Wenn nein wie ich mir am einfachsten einen OBD Adpater mit mit WIFi ACCEsspoint und websockets server ?
  

Das hier hab ich schon gefunden, auf Nachfrage wurde mir jedoch gesagt, dass die von mir gewünschten Funktionen so nicht existieren.
http://www.qualnetics.com/solutions.html

Gruss

Gibt's nicht.
WIFI gibt's, bereitet aber oft Probleme. Bluetooth ist einfacher.
Anstatt mit Hardware und Elektronik zu experimentieren, die Sie anscheinend selber nicht gut kennen und dann auch noch mit OBD Protokollen zu hantieren, würde ich eine JAVA Anwendung für COM-Ports schreiben. Das ist lösbar und auch sehr flexibel, wenn man denn JAVA richtig umsetzt.
Aber meine Erfahrung deutet allgemein bei diesem Thema eher auf eine kurze Aufmerksamkeitsspanne bei den Leuten, die sich damit befassen wollen. Siehe viewforum.php?f=16

_________________

Alles folgende ist Teil der Antwort und wird oben nicht noch mal explizit wiederholt:

Sieh' in die FAQ! Schaue in die Fahrzeugliste, ob Dein Fahrzeug vorhanden ist. Trage Deine Erfahrungen dort ein und hilf so anderen Nutzern!

Ich freue mich über Infos mit Herstellernummern zu VAG Steuergeräten mit CAN TP 1.6/2.0 oder UDS Protokoll wenn die Pinbelegung (Diagnoseleitungen und Spannungsversorgung) bekannt ist.

Nutze PGP für Deine Emails! (PDF lesen)

Dieser Beitrag kann Werbung enthalten.

Hallo Florian,

ich bin KFZ Steuergeräte Software Funktionsentwickler, ich entwickle die Fehlermeldungen, die mittels OBD abgeholt werden und die in der Werkstatt meistens zu teuren Reperaturen führen. Dabei wird die OBD spezifische steuergeräteseitige Programmierung in der Regel von meinen Kollegen übernommen. In der Tat bin ich also nicht der Profi in dem Gebiet OBD, kenne aber genügend Leute die sich bestens damit auskennen.

Meine erste Anwendung habe ich vor 4 Jahren für ein Nokia N73 entwicklet. Dabei habe ich mir eine Anwendung gemacht, die nichts weiter tut als eine einzlne CAN Nachricht über die KWP2000 over CAN Schnittstelle abzusetzen. Das war der Inbetriebnahme Befehl für eines meiner Steugeräte. Ich wollte mir das Laptop hochfahren, Software starten Adapterkabel in Stecker fummeln usw. sparen und lieber mit dem Telefon das schnell erledigen. Mittels ein paar AT Befehlen an den OBDKEY Buetooth war das erledigt, was auf dem Nokia in einem Symbian Script hinterlegt werden konnte.

Meine zweite Anwendung habe ich vor 1 Jahr als Android nativ app geschrieben. Damals wollte ich CAN Daten drahtlos auf meinem Android tablet anzeigen. Wieder war die drahtlose Übertragung wichtig und die möglichst geringe Zeitverzögerung bei der Anzeige. Wieder habe ich den OBDKEY Bluetooth verwendet, der auch in einen Binary Mode zyklische CAN Nachrichten auf die Serielle Schnittstelle legt. Als Entwickler habe ich natürlich die notwendigen CAN DBCs dafür zur Hand um die Daten dann zu interpretieren. Das hat so ganz gut funktioniert, lediglich gibt es sporadische "Hängenbleiber" von über 200ms die keine flüssig Datendarstellung erlaubt, an sonsten erfüllt die Anwendung aber ihren Zweck.

All diese Funktionen kann ich natürlich auch mit meinen (teuren) Entwicklertools machen, die jedoch nur auf meinem Laptop laufen, was nicht Ziel dieser Übung ist.

Nun habe ich, wie ganz oben geschrieben, die Idee beim nächsten Projekt websockets zu verwenden, und wieder soll ein kleiner OBD Dongle die Schnittstelle zum CAN BUS spielen. Dabei steht die flexible Anpassung der Anzeige und Verwendbarkeit auf Tablets und Smartphones im Fokus. Daher meine Fragen oben. Vermutlich habe ich hier tatsächlich einige Dinge falsch beim Namen genannt, mir ist leider nicht klar was da falsch gesagt wurde, um Aufklärung wäre ich dankbar. Ein Anwendung von java applets halte ich bei der Verfügbarkeit von HTML5 nicht zeitgemäß, das es nach meinem Wissen z.B unter Android nicht unterstützt wird. Daher will ich die Aufgabe mit einer modernen Firmware auf einem OBD Adapter lösen und mir hier im Form ein paar Ratschläge abholen befor es an die Umsetzung geht.

Inzwischen ist mir klar geworden dass es einen OBD WIFI Access Point mit websocket server interface leider nicht in der Größe einer Zigarettenschachtel gibt. Daher will ich das Forum fragen ob es anderen Ideen gibt, wie man CAN oder OBD Nachrichten als Websocket Server Interface zur Verfügung stellen könnte oder wie sich bestehende geeignete Hardware umprogramieren ließe.

Auch wäre ich zu Infos zu den genannte Problemen mit WIFI dankbar.

Danke