Priusfreunde.de

Hallo,
ich habe jetzt sein gut 1200km den Hybrid Assistant im Einsatz. Grundsätzlich ist er ganz praktisch, manche Sachen stören mich aber:

-Zu starke Abstraktion der Software auf einem Androidgerät. Es kann abstürzen, Verbindungsprobleme bekommen und könnte Langfingern gefallen.
-Recht weit offenes Scheunentor bei Bluetoothverbindung.
-Die meisten günstigen OBD-Adapter schalten sich bei stehendem Fahrzeug nicht automatisch ab und nuckeln die Batterie leer.
-Wenn man nicht wie ich eine Android-Dashcam zweckentfremdet, muss man dauernd sein Handy in eine Halterung klemmen, was einem das Bluetoothradio ansonsten eigentlich erspart.
-Die meisten OBD-Adapter können nur OBD-Nachrichten verarbeiten, fragen also die Steuergeräte nach allerlei Parametern, die teils sowieso schon zyklisch gesendet werden. Das macht an sich keine Probleme, ich finde es aber schöner, möglichst viele Parameter passiv zu erfassen und nur wenige aktiv abfragen zu müssen.

Daher möchte ich mir ein eigenes Kistchen mit ähnlicher Funktion bauen, für den P2 hatte das ja schon jemand konstruiert.
Ich hatte mir beim Yaris damals nacheinander zwei verschiedene Geräte gebaut, die ich in eine Handyhalterung geklemmt habe und mit denen ich ein paar Fahrzeugparameter im Auge behalten konnte.
Das erste bestand aus einem Arduino, einem Bluetoothmodul, dass sich automatisch mit einem OBD-Adapter verband, und einem monochromen 128*64-LCD, auf dem ich mir Kühlwasser- und Ansauglufttemperatur, Motorlast, Drehzahl, tatsächliche Geschwindigkeit (nicht der übertriebene Tachowert) und noch ein paar Werte, die mir gerade entfallen sind, anzeigen ließ.
Das war eher ein mal eben zusammengezimmerter Behelf.

Die zweite Version bestand aus einem STM32-Entwicklungsboard mit aufgestecktem 320*240-Farb-TFT, das die OBD-Abfragen direkt über CAN abgewickelt und manche Parameter (Kühlwassertemperatur, Drehzahl) passiv erfasst hat. Es hing dauerhaft an 12V, konnte sich aber bei ausbleibendem CAN-Traffic in einen Standbymodus versetzen und kam dann mit etwa 0,1mA aus.

Das habe ich damals nicht weiter publiziert, weil vermutlich eh kaum Technikinteressierte so eine Hausfrauenschleuder fahren, aber beim Prius dürfte die Sache schon anders aussehen, daher möchte ich mal in die Runde fragen, ob es Leute gibt, die auch gerne so etwas hätten.

Dann würde ich den Quellcode hier reinstellen. Platinen kann ich grundsätzlich layouten, habe aber aktuell eher wenig Motivation dazu, auch, weil die paar nötigen Bauteile auch auf einer Streifenrasterplatine gut Platz haben.

Ich habe mir ein ernsthaftes (also nicht dauernd abstürzendes) CAN-Interface zugelegt und eine Liste mit ein paar CAN-IDs vom P3 gefunden, so dass ich nicht ganz bei 0 anfangen muss.

Die Hauptfrage ist die der Anzeigegröße. Grundsätzlich habe ich zwei Displays in die engere Auswahl genommen:
OLED 128*64, monochrom

TFT 320*240, monochrom
Da ist dann der Prozessor schon dabei.
Bei dem anderen würde ich einen STM32F103C8T6 nehmen, die gibt es um 1,8€ oder sogar noch darunter komplett mit Platine, Quarz etc. in China.
Eine wesentlich höhere Displayauflösung bekommt der Prozessor ohne spezielle Tricks nicht sinnvoll aktualisiert, das gibt dann Tearing, Ruckeln und Geflacker.
Es gibt auch etwas kleinere TFTs, aber da müsste ich mir erst einen Treiber zurechtstricken.

Ergänzen müsste man das jeweils nur mit einem sparsamen Spannungsregler (LP2950), Transistoren, evtl. einem Relais und einem CAN-Transceiver.

Guten Abend,
das klingt mehr als interessant!
Nur für mich zum Verständnis, ist dann die Funktion ähnlich einem scan gauge?

Wie einfach ist es denn, so etwas ansehnlich aussehen zu lassen? 3D Drucker an der Hand?

Moin,
ich hab ja keinen P3, aber wenn das auch beim P4 funktionieren würde wäre ich durchaus interessiert.

YHSD schrieb:

Nur für mich zum Verständnis, ist dann die Funktion ähnlich einem scan gauge?

Ja, so in etwa.


Wie einfach ist es denn, so etwas ansehnlich aussehen zu lassen? 3D Drucker an der Hand?
Drucker ja, ABS kann er auch drucken, aber beim Inventor habe ich zwei linke Hände


P4: Da müsste ich mal gucken, was dort auf dem Bus unterwegs ist und ob es Gemeinsamkeiten gibt. Ich kenne leider niemanden mit einem P4, werde aber wohl zum Treffen in Köln fahren. Da wird sich schon jemand finden

ea827 schrieb:
-Recht weit offenes Scheunentor bei Bluetoothverbindung.
-Die meisten günstigen OBD-Adapter schalten sich bei stehendem Fahrzeug nicht automatisch ab und nuckeln die Batterie leer.

Aus diesem Grunde habe ich mir den OBDlink MX geholt. Es reicht aber auch der LX. Beide haben kein Scheunentor bei der Bluetoothverbindung. Pairing ist nur möglich, wenn man einen Taster drückt. Sonst nicht. Wenn man das Pairing in der Garage macht, kann eigentlich kaum etwas passieren. Power-Save-Funktionen sind auch toll. Den Adapter kann man ohne Probleme ständig angesteckt lassen. Mache ich seit einigen Jahren so.

Generell finde ich allerdings Dein Projekt gut. Viel Erfolg.

Persönlich würde ich statt des STM32 einen Raspberry Pi3 nehmen. Leistungsfähig und günstig. Touch-Screens gibt es dafür eine große Auswahl. Halterungen und fertige Gehäuse fürs Auto auch. Linux ist fertig und man kann entwickeln. Für Python gibt es auch Bibliotheken, um OBD2 (seriall und Bluetooth) zu nutzen. Ich habe zwar früher fast alles in C entwickelt. Würde ich mir heutzutage wegen des hohen Aufwandes nicht mehr antun.

Grmpf, natürlich ist mit "3rd Generation" doch der P2 gemeint.
www.selidori.com/tech/00000-04999/40-lLwI4.pdf
Also wieder selbst experimentieren wie beim Yaris
Geht auch, dauert nur länger.

Ich habe mal eine Tabelle erstellt, die ich bei neuen Erkenntnissen ergänzen werde. Ein paar IDs habe ich unter attachments.priuschat.com/attachment-fil...h_a_Toyota_Prius.pdf gefunden.
Edit: Scheint auch wieder vom P2 zu sein
Ergo steht jetzt nur drin, was ich ermittelt habe.

docs.google.com/spreadsheets/d/15S1Xc0_k...Blk/edit?usp=sharing

@ea827

habe interesse und kann evtl. beim gehäuse helfen

Das wäre gut, leider musste ich mit Bestürzung feststellen, dass das von mir bevorzugte Board kaum noch zu bekommen ist.
Da blieben echt nur die 2,5 Varianten:
1) Ich konstruiere eine Standardkomponentenlösung (STM32, alphanumerisches 4*20-Zeichen-LCD) mit mittelmäßigem Funktionsumfang
1.5) Ich verwende stattdessen das anscheinend recht oft verwendete SSD1306-OLED-Display, das ist halt ein winziges Mäusekino.

2) Ich arbeite heraus, welche IDs wozu gut sind, aber die Software muss sich jeder selbst aufs Display anpassen, wenn es ein anderes als das von mir verwendete sein sollte. Ist natürlich doof, weil wir dann trölf Display- und damit Gehäusevarianten bräuchten.

Edit: 3) Ich setze (ungern) auf Arduino und nehme den Softwareoverhead sowie die höheren Teilekosten in Kauf.

ea827 schrieb:
daher möchte ich mal in die Runde fragen, ob es Leute gibt, die auch gerne so etwas hätten.

Ja - und auch nein.
Hardware-maessig waere mir Dein Ansatz 'zu schwach'.
Software-maessig - durchaus

Akt. suche ich einen Linux-faehigen SoC - mit socket-CAN Support.
(sowas wie diese Teile: www.solid-run.com/nxp-family/ )

damit koennte man auch z.B. via socket-CAN aufgezeichneter Daten (also ohne Auto) rumspielen/entwickeln....

ich habe durchaus schon mit dem ELM-327 rumgespielt, ist fuer Anfaenger wirklich gut - um zum verstehen was da an Daten rumfliegt - aber - langfristig - nicht so mein Fall.
vor allem gibt's kein capture/replay Support fuer ELM-Interfaces.

Aber irgendwie fehlt mir die Zeit - hier wirklich schnell weiterzukommen. ab und zu mach ich mal was dran.

PID-maessig gibt's ja diese XLS-Files auf Priuschat.com - usw.
...ist rel. gut dokumentiert. Genauso hilfreich ist es, sich von HybridAssistant BT-HCI-logs zu ziehen, und die sich mal genauer anschauen. (dekompilier' HA - und auch wenn es stark obfuscated ist - vieles erkennt man dann doch noch)

Fand ich am Anfang rel. hilfreich das ganze CAN-Gedoens zu verstehen.

ea827 schrieb:
1) Ich konstruiere eine Standardkomponentenlösung (STM32, alphanumerisches 4*20-Zeichen-LCD) mit mittelmäßigem Funktionsumfang

evtl. wuerde mich eine display-LOSE version interessieren

hirni schrieb:
Ja - und auch nein.
Hardware-maessig waere mir Dein Ansatz 'zu schwach'.
Software-maessig - durchaus

Akt. suche ich einen Linux-faehigen SoC - mit socket-CAN Support.
(sowas wie diese Teile: www.solid-run.com/nxp-family/ )

damit koennte man auch z.B. via socket-CAN aufgezeichneter Daten (also ohne Auto) rumspielen/entwickeln....

CAN hast du meines Wissens z.B. bei vielen Allwinner-Prozessoren. Schau mal nach Banana Pi Pro und Cubieboard.
Mir persönlich sind diese ganzen Gerätschaften für den Einsatz im Auto zuwider, weil die SD-Karten auf Betriebsspannungsverlust allergisch reagieren (und irgendwann wird er kommen!), die Hochfahrzeit relativ hoch ist und das Energemanagement fummlig ist und zu guter Letzt, weil ich eigentlich nur ein Zusatzdisplay brauche.
Eine Protokollierung auf SD-Karte oder evtl. auf einem schlaueren Weg (die STMs können auch teilweise Speicher über USB zugänglich machen) geht auch mit etwas schmälerer Prozessorleistung.

Aber wenn wir erst einmal wissen, welche Information sich hinter welcher ID (!=PID, die sind ja bekannt) versteckt, lässt sich das ja für jedes System nutzen.

hirni schrieb:
ich habe durchaus schon mit dem ELM-327 rumgespielt, ist fuer Anfaenger wirklich gut - um zum verstehen was da an Daten rumfliegt - aber - langfristig - nicht so mein Fall.
vor allem gibt's kein capture/replay Support fuer ELM-Interfaces.

So bin ich damals auf den STN1110 gestoßen. Ist teuer, aber wenn man richtig fragt, bekommt man 3 Samples geschenkt
Schließlich habe ich dann doch zuerst eine Can-Initialisierung für den PIC32 gestrickt, dann die günstigeren STMs entdeckt und mir dann ein Grundgerüst gestrickt, das ich seitdem immer nur ein bisschen umbauen muss.


PID-maessig gibt's ja diese XLS-Files auf Priuschat.com - usw.
...ist rel. gut dokumentiert. Genauso hilfreich ist es, sich von HybridAssistant BT-HCI-logs zu ziehen, und die sich mal genauer anschauen. (dekompilier' HA - und auch wenn es stark obfuscated ist - vieles erkennt man dann doch noch)

Fand ich am Anfang rel. hilfreich das ganze CAN-Gedoens zu verstehen.
Die PID-Liste habe ich, aber ich habe den Ehrgeiz, möglichst viele Informationen aus den Paketen herauszuziehen, die eh unterwegs sind, so mülle ich den Bus nicht mit vermeidbarem Traffic zu und kann die wirklich abzufragenden Werte viel flotter abfragen.
Zusätzlich wird z.B. die Geschwindigkeit dermaßen oft gesendet (die und die Raddrehzahlen haben mit die höchste Priorität), dass sich da noch die Latenz des Tachos unterbieten ließe. (Ja, ich latsche manchmal voll aufs Gaspedal und möchte wissen, wann ich es loslassen muss, um nicht geblitzt zu werden )

ea827 schrieb:
Die PID-Liste habe ich, aber ich habe den Ehrgeiz, möglichst viele Informationen aus den Paketen herauszuziehen, die eh unterwegs sind, so mülle ich den Bus nicht mit vermeidbarem Traffic zu und kann die wirklich abzufragenden Werte viel flotter abfragen.

Mir ist schon der Unterschied zwischen solicited und unsolicited bekannt. Aber, weil ich noch nie einen full-snoop gemacht habe, ein wenig navig gefragt:

ich haette gedacht, dass die "unsolicited" Daten doch das gleiche Format haben, wie die "solicited" - gleicher Absender (ECU+8) gleiches Format usw. - oder nicht ?

Nein, das ist die Kommunikation zwischen den einzelnen Steuergeräten.
Sieht folgendermaßen aus, das da ist nur ein kurzer Ausschnitt:

Einige IDs werden seltener gesendet, insgesamt scheinen es um die 100 zu sein. Grundsätzlich wird zumindest beim Yaris anders als bei OBD kein Protokoll auf diese IDs gepackt, die Bytes haben immer die gleiche Bedeutung.
Um 0x6** sind Zentralverriegelung und Karosseriesteuergerät unterwegs, um 0x4** kommen hauptsächlich uninteressante Keepalives, bei 0x2**/0x3** senden Motorsteuergerät und Klimaanlage.
0x0** kommen extrem oft und enthalten u.a. die Raddrehzahlen.

Als Günstigadapter kann ich dir den USB-Tin empfehlen, der stürzt aber gelegentlich ab und verschluckt auch öfter mal Pakete, was durch deren periodische Übertragung am Auto aber weniger schlimm ist.
Für die sackteure Kvaserkiste die ich hier habe findet sich leider nicht sonderlich viel kostenlos, äh, beschaffbare Software.

Kvaser scheint keine große Eile zu haben, beim Marktstart eines Interfaces für über 600€ netto auch zeitig den Matlab-Treiber zu aktualisieren

Logdaten zu bearbeiten ist mit der Frickelsoftware Busmaster leider ein derartiger Krampf, dass ich Parameter wie SOC oder Batteriestrom noch nicht in sinnvoller Zeit identifizieren kann.
Dafür habe ich ein paar andere Daten identifiziert, z.B. Bremsdruck und Lenkwinkel.

Edit:
Tatsächlich werden im 0x7**-Bereich, also OBD, Daten übertragen, bei mir waren es 0x7c6/0x7ce und 0x770/0x778. Möglicherweise war es das Navi (Touch Pro).