Nochmal OBD Interface, Messwerte Visualiserung und Speicherung

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Nochmal OBD Interface, Messwerte Visualiserung und Speicherung

      Prolog

      Ich suche immer noch nach ne Lösung zur Realtime Visualisierung und Speicherung von Sensordaten für meinen eGolf. Eigentlich hätte ich am liebsten ja nur freie Software und offene Protokolle, da dies aber im Moment offensichtlich nicht möglich ist habe ich bisher 2 Wege ausprobiert. Die leider noch nicht zum Erfolg führen.

Ich habe mal versucht meine Kern Anforderungen sowie beide bisher versuchten Lösungsansätze aufzuschreiben.

      Und ja ich habe den langen Thread hier im Forum zum Thema (sowie viele andere Quellen da draußen) glaube ich mittlerweile ganz gelesen :)

      Idee dieses Posts wäre:
      • Dass ich ggf. was übersehen oder falsch verstanden habe und ihr mich aufklärt.
      • Er den “langen Thread” mal etwas zusammen fasst
      • Das wir die Anforderungen unten gemeinsam weiter entwickeln und am Ende evtl 1-3 Feature Requests an Projekte da draussen entstehen die wir dann “gemeinsam als Forum” dort einreichen wenn interesse besteht (sonst mache ich es ggf einfach selbst :))
      Freue mich über Feedback!


      Anforderungen:

      1. Interface zum eGolf OBD Interface das kabellos und energiesparend ist (z.B. Bluetooth Low Energie)
      2. Das Anlegen, Verwalten und Speichern von Sets verschiedner Messwerte (ggf. Verschiedener Fahrzeug Controller)
      3. Die flexible Realtime Visualisierung von Messwerten während der Fahrt auf einem Android Gerät. (siehe z.B. Android Torque Pro)
      4. Das Speichern von Messwert-Reihen in einem zur späteren Weiterverarbeitung / Langzeitspeicherung geeignetem, maschienen lesbarem Format (z.B. CSV) mit einem Android Gerät.
      OBDeleven

      Kommt mit einem Bluetooth Interface und kommuniziert über ein proprietäres / verschlüsseltes? Protokoll mit einer Android App (Erfüllt Anforderung 1).

      Grosser Vorteil: Kann sehr viel VW spezifisches lesen und schreiben (kein reines OBD2? mehr PIDs? Ist mir noch nicht ganz klar warum). Auf jedenfall finde ich in OBDeleven alle Messwerte irgendwo die mich interessieren.

      Primärer Usecase scheint aber das auslesen von Fehlern und einfache kodieren von Steuergeräten zu sein. Es gibt zwar auch die Möglichkeit Messwerte in einem Zeitgraph zu Visualisieren (Also teilweise Anforderung 3, aber leider kann ich mir daraus kein “cooles Dashboard” bauen.

      Ebenso lassen sich sich Setts unterschiedlicher Messwerte aufzeichnen und exportieren (Anforderung 4). 

Leider lässt sich weder für Visualisierung noch zur Auzeichnung die Gruppe der gewählten Messwerte abspeichern und später wieder aufrufen (Anforderung 2), sondern mann muss sich jedes mal wieder durch scrollen / klicken.

      Fazit Anforderungen: Kann 1 und 4. 2 Leider gar nicht, 3 nur sehr bedingt (keine Flexibilität: nur Zeitgraph und nur einer.)

      Torque Pro + Bluetooth 4.0 ELM327 OBD2 Interface

      Mit Torque Pro kann man sich unter Android coole Dashboards bauen in dem man verschiedenste Widgets platziert um Messwerte unterschiedlich zu visualisieren (Anforderung 2 und 3).

      Ausserdem kann man Werte auch aufzeichnen und an eine REST API Pushen (Anforderung 4).

      Man merkt zwar das Torque Pro im Moment noch sehr auf Verbrenner ausgelegt ist (Viel Logik zur Reichweitenberechung aus Tankstand Verbrauch etc), aber das “stört nicht”. Da es ausserdem schon recht lange aktiv weiter entwickelt wird, scheint es mir Möglich dass eAuto Spezifika irgendwann implementiert werden, wenns genüg Leute wollen.

      Leider war es mir bisher nicht möglich über mein ELM327 kompatibles bluetooth interface (Vgate iCar Pro) mittles Torque an viele jener Messwerte zu kommen, auf die ich über obdEleven Zugriff habe. Mir ist noch nicht ganz klar ob mir “nur die PIDs der Messwerte fehlen” oder ob ich mit einem ELM327 Interface auf viele gar nicht zugreifen kann, weills dann nen Protokoll bräuchte was der ELM327 gar nicht sprechen kann.

Ansonsten könnte es alles (und mehr) als ich im Moment brauche.

      Fazit Anforderungen: Erfüllt 2, 3 und 4. Leider wg fehlender Messwerte 1 nicht.


      Mögliche Ansätze:

      1. Mir fehlen nur die richtigen PIDs und die lassen sich mit OBDeleven irgendwie rausfinden oder Jemand hat ne Liste, so dass ich sie dann nur noch in Torque Pro einpflegen muss.
      2. Man überredet die OBDeleven Leute: a.) Sets von Messwerten zu verwalten, b) ne Widget/Dashboard Funktionalität einzubauen
      3. Man überredet die OBDeleven Leute Echtzeit Messwerte über irgend nen Weg (z.B. Sockets oder Android Spezifika wie nen Service) anderen Apps zur Verfügung zu stellen und überredet den Torque Pro Entwickler das zu Interfacen.
      4. Irgendwas eigenes implementieren (bitte nicht)
    • Variante 5, ich ich mal angehen wollte wenn sich die Zeit findet: Freematics Esprit ESP32 Devboard mit dem ODB2 Adapter V2.1 kaufen, damit sollte es möglich sein die PIDs mit zu sniffen die OBDeleven verwendet.

      Danach sollte die Implementierung in Torque Pro möglich sein.
      Gruß, Daniel

      Unser Blog zur Elektromobilität, e-Golf und Ioniq: 1.21-gigawatt.net

      Immer einen Besuch wert, jeden 1. Samstag im Monat: Elektro-Stammtisch OWL
    • Also ich habe nochmal versucht mich etwas weiter einzulesen - ich fasse mal zusammen was ich bisher glaube verstanden zu haben:

      Ich kann mich via ODB2 ans Auto hängen. Das ist ein gesetzlich gefordertes interface wodrüber gewisse Daten z.B. zu Motor und Abgasanlage bereitgestellt werden müssen. Das ist das was all die Adapter auf Ebay und Amazon, wie der oben von mir beschriebene, sind - oft auf Basis des ELM327 Chips - bzw des Seriellen Protokolls den er zur verfügung stellt. Leider finden sich da insbesondere beim Elektroauto nur wenig gesetzlich geforderte Daten - und VW "veröffentlicht" dort auch nur das, was sie unbeingt müssen.
      An Daten wie z.B. den Eingangstrom zum Elektromotor oder die Temperatur des HV Akkus sind über ODB2 also gar nicht zu bekommen - also da helfen auch keine PIDs weil diese Messwerte gar keine PIDs auf OBD2 haben.

      Das was obdEleven oder VCDS machen ist direkt auf dem CAN Bus teilnehmen. Allerdings hängt an der Buchse im Fahrerraum nicht der, bzw. die CAN Busse an denen die unterschiedlichen Steuergeräte hängen, sondern man hängt auf einem CAN Bus der nur mit einem CAN Gateway verbunden ist und nicht direkt auf einem der Busse wo all die Steuergeräte hängen von denen ich egtl. Daten will. Mache ich also einen CAN Sniffer an, sehe ich erstmal nichts.

      Ich kann dem CAN Gateway aber über ein VW propritäres Protokoll sagen, dass ich ich gewisse Nachichten von gewissen Steuergeräten empfangen will (vereinfacht also: "will Temperatur Akku Messwerte Messages haben"). Wenn dieser Request erfolgreich was leitet der Gateway die Nachichten dann weiter. Ebenso kümmert er sich darum, die Unterschiedlichen Datenraten der verschiedenen CAN Busse weg zu abstrahieren (Rede also immer mit 500kbps mit dem Gateway auch wenn das egtl. Steuergerät auf nem 100kbps Bus hängt).

      Also wäre es interessant mal mitzusniffen was z.B. der obdeleven Adapter mit dem Gateway so redet - bzw. noch mehr Quellen im Internet auftun wo Leute dies oder Ähnliches getan haben.

      Ein paar Quellen die ich so gefunden habe:

      Aus dem Forum insbedonders guter Beitrag von jamesatfish den ich hier mal xposte da nicht direkt verlinkbar imo:


      Some connection method info that might help people connecting to VAG cars with their CBT.


      Method 1 - K-wire:

      The OBD cable that ships with the CBT is wired so that it connects to the K-wire in VW's OBD port. This is the generic (government mandated) diagnostics connector that you can use to get very simple data out of the car. The K-wire connects to the car's CAN Gateway which is setup to only provide the bare minimum legally required data on this port. This is the same data you can get to with a Bluetooth OBD dongle or generic ebay auto diagnostic tool.
      It's a very simple protocol - single command out, single response back. No handshake or connection required. The requests to make, responses that are received and the formulas to decode returned data into human readable values are all publicly available around the web - search for 'OBD PIDs'.

      Method 2 - CANBus from OBD Port


      VW diagnostic programs (both the factory programs and professional grade 3rd party apps like RossTech VCDS) access devices on the CAN networks using the CANBus pins on the OBD port. These are cabled as if they were power train CAN wires, but they actually connect directly to the CAN Gateway. I need to check the pin spots but from memory they are available at Pin 8 (Can High) and Pin 7 (Can Low) on the OBD connector.
      You can connect at 500kpbs as the CAN Gateway will translate requests onto the lower baud busses as required.
      This CAN connection is data-on-request, so if you connect and start logging the traffic you won't see anything. The CAN Gateway only passes data down this bus if it is specifically requested.

      To request data you need to handshake with the CAN Gateway, negotiate connection settings, request a set of data from a particular CAN device and read the data that is returned. With the right requests you can access data from any of the 3 busses from the one connection - so your CBT can request RPM from the Engine controller, Odometer from the Instrument Cluster, Window Position from the Front Right Door controller etc.
      The protocols to request this data, and the formats the data come back in, is all VW proprietary and they don't publish the specs. To use this method you'll need to reverse engineer the process for the data you wish to request. If you tap the bus on the back side of the OBD connector then for example you can connect a VAGCOM cable to the OBD connector itself, and use VCDS to request and view data from the CAN controllers. If you do this with the CBT logging the bus you will see the data that flows with those connections and you can sift through to find the patterns you want.

      The downside of this connection method is although you can access any controller on any of the 3 busses, you only get data on request, so if you don't know you're looking for something then you can't see it. For example, if you want your CBT to catch a steering wheel button press, you won't see this data on this bus connection unless you were asking the Steering Wheel Controller for the button status at just the right time.

      Method 3 - Directly Tapping CAN Busses

      This method involves finding the 3 CAN Bus wires in the harness and physically tapping into each of them to wire into the 3 busses on the CBT.
      The best spot for this is to find the CAN Gateway (under the dash, driver's side) - follow the CAN power train wires from the OBD connector back to the Gateway box which will have connections to all 3 busses). Connect to the power train bus at 500kpbs, and the convenience and infotainment busses at 100kbps.

      Tapping the busses on the car side of the gateway give you access to most traffic that runs across the busses. VW uses a 'tree' style CAN layout, so there are some controllers that are connected to the network as 'branches' off a parent controller, where the parent controller doesn't necessarily pass all data onto the main bus. If you're trying to access something on a branch you won't be able to watch for the traffic passing by - you'll have to request it yourself.

      Watching the traffic gives an easier method of finding the data you want - simply log the bus traffic, repeat an action (for example pushing one steering wheel button repeatedly) and watch for patterns in the data. Once identified, just write some code to evaluate every CAN packet that goes by on the bus and match the pattern. There's no need to write data requests and listen for responses - you just eavesdrop on the chatty bus traffic and wait for the data you're interested in.

      This is ideal for on-demand data (like button pushes, lock/unlock actions etc) and for frequently transmitted data (for example vehicle speed, RPM etc on the power train bus). If you want less common data (fuel sender resistance perhaps?) that none of the controllers usually pass around on the bus themselves you'll have to form a request and drop it onto the bus yourself to catch the response.