• Moin die Damen,

    wollte mal etwas vorstellen, was ich gerade gebaut habe bzw noch entwickle.

    Ziel
    Ich wollte ein preiswertes Gerät zur Datenaufzeichnung haben. Besonders auf der Rennstrecke interessieren mich schon ein paar Daten des Fahrzeugs im Nachhinein.
    Ich habe schon mal einen Logger gebaut, damals alle Werte wie TPS, Drehzahl etc direkt von den Leitungen abgegriffen. Das hat funktioniert, war aber fehleranfällig. Diesmal ziehe ich mir die Daten vom CAN-Bus. Das hat den Vorteil, dass ich nicht mehr selbst rumlöten muss und mich auf die Software am PC bzw die Software der Box konzentrieren kann.

    Hardware
    Ziemlich unspektakulär - Arduino UNO mit einem CAN-Shield in der Basisversion.


    Die beiden Teile stellen die Basisversion dar. Damit ist es bereits möglich die CAN-Werte aufzuzeichnen. Ohne GPS jedoch sinnlos. Also muss noch ein GPS Sensor drauf...und Display.


    Hardwarekosten liegen inkl Kabel, GPS und der beiden Boards bei etwa 100 €

    Software
    Die Software zur Auswertung auf dem PC entwickle ich schon seit 2010. Allerdings nicht regelmäßig. Es ist schon einiges zusammengekommen, eine ältere Version sieht man hier

    https://www.youtube.com/watch?v=bJvxGER4A9A

    Die Aufzeichnung lässt sich laden und man sieht die aufgezeichneten Kanäle, dazu den GPS Track mit einer Markierung, wenn man eine Position im Kanal auswählt.
    Die Software für den Arduino entsteht gerade.

    Features
    Auf einen Blick:
    - Aufzeichnung aller Daten, die vom Fahrzeug bereitgestellt werden (Übersicht hier, variiert pro Fahrzeug: http://en.wikipedia.org/wiki/OBD-II_PIDs)
    - Programmierbares Shiftlight
    - GPS Laptimer
    - Programmierbare Displayanzeige.

    Alles natürlich unfertig und in Entwicklung aber in einem Stand, den man schon mal vorzeigen kann :band:

  • Hi,

    deine Auswertungs-Software ist wie es aussieht in Java geschrieben - sehr schön.
    Ich schätze, dass das die Erweiterung und Portierung der Software entsprechend einfach macht. Weiterhin nehme ich mal an, dass du damit jegliche CSV-Daten analysieren kannst und lediglich noch angeben musst, was für eine Art Graph dafür erzeugt werden muss.

    Kannst du etwas dazu sagen, wie viele einzelne Werte du pro Sekunde aufzeichnen können wirst mit dem Arduino?
    Ich schätze mal, dass du durch den Zugriff über CAN deutlich schneller sein wirst als über das reine OBD-Protokoll. Zumindest bei meinem Mitsubishi Evo X hatte ich über CAN ca. 7-8x so viele Werte auslesen können bzw. dadurch die Abtastrate einzelner Werte erhöhen können. Allerdings war das mit einem Laptop als Aufzeichnungsgerät implementiert und das ist weniger optimal, da der Platz im Lotus sowieso schon beengt ist.  ;)


    Hast du deine Auswertungs-Software eigentlich irgendwo bei Github oder ähnlichem online?


    Grüße aus dem Saarland


    Bernhard

    Viele Grüße

    Bernhard
    (dot)

  • Hallo Bernhard,

    hast Du richtig erkannt, ist in Java geschrieben, daher überhaupt kein Portierungsaufwand. Starten und fertig ;)
    Das Format, was ich verwende, ist an CSV angelehnt. Eine Beispielaufzeichnung sieht folgendermaßen aus (Achtung lediglich Testdaten):


    #waypoint|rpm|speed|temp|tps|GPRMC
    0|700|0|40|30|$GPRMC,201059.000,A,5122.3900,N,00655.8252,E,1.00,235.97,260110,,,A*6B
    1|740|0|42|32|$GPRMC,201107.400,A,5122.3933,N,00655.8160,E,7.05,270.78,260110,,,A*64
    2|1700|5|50|60|$GPRMC,201112.400,A,5122.4022,N,00655.7826,E,20.96,292.13,260110,,,A*54
    3|3700|25|55|80|$GPRMC,201118.400,A,5122.4142,N,00655.7091,E,32.97,280.97,260110,,,A*50
    4|2700|45|57|40|$GPRMC,201120.800,A,5122.4200,N,00655.6715,E,35.99,282.71,260110,,,A*5B
    5|3200|55|60|45|$GPRMC,201123.200,A,5122.4271,N,00655.6317,E,37.65,283.10,260110,,,A*55
    6|3000|60|58|45|$GPRMC,201125.800,A,5122.4334,N,00655.5895,E,37.30,284.19,260110,,,A*55
    7|3500|70|65|62|$GPRMC,201128.200,A,5122.4393,N,00655.5502,E,37.81,283.14,260110,,,A*5C
    8|4400|75|74|20|$GPRMC,201130.800,A,5122.4460,N,00655.5070,E,38.91,284.23,260110,,,A*59
    9|4000|70|80|30|$GPRMC,201133.200,A,5122.4521,N,00655.4662,E,38.56,284.71,260110,,,A*5C
    10|3700|65|89|40|$GPRMC,201135.600,A,5122.4600,N,00655.4247,E,39.57,285.33,260110,,,A*5A
    11|2700|50|89|20|$GPRMC,201138.000,A,5122.4674,N,00655.3831,E,39.82,287.27,260110,,,A*51
    12|2900|45|89|20|$GPRMC,201145.400,A,5122.4932,N,00655.2547,E,41.98,290.03,260110,,,A*5B
    13|1700|20|89|20|$GPRMC,201202.600,A,5122.6054,N,00654.9765,E,42.62,316.74,260110,,,A*53
    14|700|0|89|30|$GPRMC,201222.800,A,5122.7877,N,00654.7454,E,41.87,320.60,260110,,,A*5

    Aktuell ergibt sich die Aufzeichnungsrate durch die Updaterate des GPS Sensors beschränkt (10MHZ), da es meiner Meinung keinen Sinn macht, Werte ohne zugehörige Position aufzuzeichnen. Github: nein, ist momentan ein privates Repo auf bitbucket, ich weiß noch nicht, ob ich den Code veröffentlichen will, dafür steckt da einfach viel zu viel Arbeit drin.

    Viele Grüße
    Alex

  • Hi Alex,

    Eine Update-Rate von über 10MHz kann ich ja bald nicht glauben. Wie geht so etwas?
    Ich hatte bei dem Evo X eine Leserate von nur ca. 100 16bit Werten pro Sekunde erreicht. Allerdings waren das jeweils Werte aus der ECU (Pedalstellung, Gang, Stellung der Drosselklappe, Wert innerhalb der LoadMaps usw.) und die ist doch eigentlich sehr eng verdrahtet.
    Ich hätte daher jetzt für das Gesamtsystem eher eine Leserate von ca. 30-40 Werten pro Sekunde erwartet. Wow!

    Ich glaube ich muss mir auch so einen Logger bauen...

    Was das Veröffentlichen von Code angeht, kann ich dich zum Teil verstehen. Ich bin seit 21 Jahren im Open Source und Linux-Umfeld aktiv und habe in dieser Zeit schon zu einigen Projekten Code beigetragen. Oftmals erhält man nach einer Veröffentlichung nichtssagende Beschwerden über seine Software (kann dies nicht oder kann jenes nicht) und auch verhältnismäßig wenig Dank zurück. Aber manchmal ist es auch der Beginn einer Bewegung, die man in Gang setzt und darauf kann man dann schon ein wenig Stolz sein.
    Gerade im Bereich Log-Auswertung gibt es leider noch nicht viel brauchbares bei Github. Daher hatte ich selbst schon überlegt auf Basis von Elastic Search und Kibana etwas aufzubauen. Aber das ist wohl wieder zu kompliziert für relativ kleine Log-Dateien mit ECU- und/oder GPS-Daten.

    Grüße

    Bernhard

    Viele Grüße

    Bernhard
    (dot)

  • Hallo Bernhard,

    meine Aussage zur Updaterate bezieht sich rein auf den Arduino - der käme da locker hinterher. Wie schnell die Daten vom Can Controller im Auto gesendet werden, kann ich momentan nicht sagen, da ich noch nicht im Auto getestet habe :)

    Mit Elastic Search habe ich beruflich schon zu tun gehabt, wir haben damit Volltextsuchen für einen großen Lebensmittelshop mit 4 Buchstaben gebaut ;)

    Gruß
    Alex

  • Hi Alex,

    Wenn es im Auto läuft, kannst du gerne mal über die Datenrate berichten. Je nachdem wie die ist, würde ich mir nämlich auch gerne einen solchen Datenlogger nachbauen.

    Bezüglich deinem neuen Screenshot mit Karte, muss ich sagen, dass das echt ein schönes Feature ist. Das erinnert mich ein wenig an die Stauansicht bei Google Maps - nur mit einer ganz anderen Aussage. Farblich könnte man jetzt z.B. noch die Geschwindigkeit darstellen und durch Strichelung oder Dicke der Linie die Drehzahl. Damit hätte man gleich noch mehr Informationen, die man aus der Karte lesen kann. Wenn man es dann noch weiter spinnt, könnte man darin sogar Schaltpunkte usw. anzeigen.

    Mit welcher Java-Bibliothek hast du die Karte eigentlich eingebunden? Ist das direkt die Google Maps API?

    Bernhard


    ps. Lebensmittelshop und Elastic Search - wow - ich hätte nicht erwartet, dass die Branche doch so modern ist.

    Viele Grüße

    Bernhard
    (dot)

  • Oh doch, die bessern sich. Arbeiten sogar agil und haben eine Microservice Architektur ;)

    Lib:
    Das ist Open Street Map, habe diese Lib verwendet:

    https://github.com/msteiger/jxmapviewer2


    Mit den Linienfarben hatte ich das auch so im Sinn, zumindest vielleicht jeweils eine Farbe für Beschleunigung, Bremsen und konstante Geschwindigkeit. Weitere Infos könnte man im Flyout vom Bubble rein packen

  • Ich konnte nun mit dem OBD Interface Daten aus meinem Karren auslesen. Nun geht es an die Anbindung der SD Karte und das Schreiben der Daten zusammen mit den GPS Koordinaten.

    So sieht es auf der Console beim Testen aus:

    0100 gibt die Übersicht der unterstützten IDs zurück. 4 HEX Bytes, bit codiert. Also spuckt die MEMS3 folgende Daten aus:

    3 - fuel system status
    4 - calculated engine load (%)
    5 - engine coolant temp (c)
    6 - short term fuel % trim - bank1 (%)
    7 - long term fuel % trim - bank1 (%)
    0B - map (kPa)
    0C - rpm (rpm)
    0D - Vehicle speed (kmh)
    0E - timing advance (° rel to #1 cylinder)
    0F - intake air temp (c)
    11 - tps (%)
    13 - o2 sensors present
    14 - bank1, sensor1, o2 sensor voltage, short term fuel trim (v %)
    15 - bank2, sensor1, o2 sensor voltage, short term fuel trim (v %)

    010c fragt also die aktuelle Drehzahl aus, letzte zwei Bytes geben den Wert an. Also 00 00 --> Motor war aus, der nächste Wert 12 54. Die Formel zur Berechnung lautet ((A*256)+B)/4 --> ((18*256) + 84) / 4 = 1173 rpm im Stand.

    >0700 fragt gespeicherte Fehlercodes ab. Bei mir war eine 95 abgelegt, also dezimal 149. Wenn ich das richtig interpretiere, ist es der P0149 Fehlercode --> Fuel Timing Error.

    Mit >0400 gelöscht und bei der nächsten Abfrage >0700 keine Codes mehr abgelegt.

  • Ich hab meinen "Klotz" nun zusammengebaut, programmiert und heute eine erste Testfahrt damit gemacht. Funzt wunderbar, vorerst mit LAN Kabel, ich denke ich baue da ein Wifi Modul dran, sonst ist das Auslesen viel zu fummelig. Ausserdem brauche ich einen besseren GPS Sensor, habe meinen guten in einem Idiotieanfall mit der Batteriespannung versorgt und ein kleines Feuerwerk gehabt...

    http://i.imgur.com/7Zfawb7.jpg

    http://i.imgur.com/3xMhHbN.jpg

    http://i.imgur.com/SY5Rfzc.jpg