Ich schreibe eine Software, um eine Telemetrieanwendung für meinen VW Golf mk4 von 2001 zu erstellen und Parameter von OBD2 mit einem ELM327-kompatiblen Kabel zu lesen.
Es ist mir bisher gelungen. Das Problem, das ich jetzt habe, ist, dass die Software zu langsam ist (3 - 4 Werte pro Sekunde). Einige der Probleme könnten in meiner Software liegen, andere könnten Einschränkungen des OBD2-Protokolls in meinem Auto sein, aber nehmen wir an, dass alles von meiner Software herrührt, und ich werde sie bis zu dem Punkt verbessern, an dem ich sie lesen kann schnell wie möglich.
Ich habe in der Dokumentation für das Kabel gelesen, dass es für ein Auto mit OBD2-Standards vor 2002 verboten ist, Werte schneller als 100 Millisekunden auseinander zu lesen. Darin heißt es, dass Probleme auftreten können , aber sie gehen nicht ins Detail.
Meine Frage ist: Hat jemand eine Ahnung, welche Art von Problemen auftreten können, wenn Informationen zu schnell vom OBD2 gelesen werden , und ob diese Probleme, falls sie auftreten, behoben werden können, indem einfach die Batterieklemmen entfernt und wieder an das Auto angeschlossen werden?
Die ELM -Dokumentation weist darauf hin, dass dies kein reines Abfrageproblem ist. Ich sehe auf Seite 31 dieses Dokuments, dass es um die Rate ging, mit der J1850-Anforderungen beim OBD-System ankommen (dies ist eine Folge der Aktualisierung des J1979-Standards vom April 2002 ). Insbesondere warnen sie Sie davor, Abfragen mit Raten von mehr als 100 Millisekunden (auch bekannt als 10 pro Sekunde) durchzuführen, geben jedoch keine Einzelheiten an.
Es ist wichtig zu verstehen, dass Sie nicht nur passiv Daten lesen. Es läuft eine asynchrone Anfrage-Antwort-Schleife. Soweit ich das beurteilen kann, könnten zu viele zu schnelle Abfragen die Warteschlange für ausgehende Nachrichten im OBD-System überlaufen lassen. Da diese Situation sehr nach einem Pufferüberlaufproblem klingt , ist es nicht unmöglich, dass Sie Ihrem OBD-System, wenn nicht sogar Ihrem gesamten Motorcomputer, fatalen Schaden zufügen könnten.
Da bin ich nervös: Es ist natürlich Ihr Fahrzeug.
Nun, das ist alles gesagt: Es sieht so aus, als ob OBD-Überwachungstools für Ubuntu frei verfügbar sind. Die Handbuchseite für obdgpslogger zeigt zwei interessante Optionen:
-a|--samplerate <samples-per-second>
Sample at most this many times a second. The software will sleep
temporarily at the end of each loop if appropriate. Keep in mind
there is an upper limit to samplerate, typically capped by I/O
on your serial port. Set this to zero to sample as fast as
possible. BE WARNED. Values greater than ten here are forbidden
for cars predating April 2002. If you think your car postdates
early 2002, and you'd like to sample as fast as possible, the -o
option may help
-o|--enable-optimisations
Enable certain elm327 optimisations. This will [usually] make
sampling faster [not a noticeable amount if you're only sampling
once a second], but makes it much easier to accidentally disobey
the standard if you're sampling as fast as possible.
Aus dieser Seite geht hervor, dass sich die beste tatsächliche Rate, die Sie wahrscheinlich erzielen werden, aus Folgendem ergibt:
obdgpslogger --samplerate 10 --enable-optimisations
Sie werden feststellen, dass die meisten OBD-Softwaretools selten mehr als 4 oder fünf Ausgänge pro Ansicht anzeigen. Ich bin auch auf Probleme gestoßen, wenn ich versucht habe, zu viele Werte auf einmal zu lesen.
Da ich aus Erfahrung spreche, würde ich vorschlagen, eine Strategie zu erarbeiten, um verschiedene Werte abzufragen. Zum Beispiel müssen Sie wirklich nur abfragen
Der Trick besteht darin, Dinge, die sich ändern, öfter und öfter abzufragen.
Wechseln Sie beim nächsten Mal in einem Auto mit Bordcomputer zur Sofortverbrauchsansicht und sehen Sie, wie oft sich der Wert ändert. Bei meinem Auto ist es jede Sekunde. Ich würde sagen, dass eine Sekunde eine großartige Basislinie ist, da Sie damit problemlos 9 PIDs bei 100 ms pro Sekunde lesen können.
Nicu Surdu
Nicu Surdu
Bob Cross