Ladedruckanzeige für den THP

[macs1971]

Hi,

@ Deep-Sea: Ich finde das ist doch arg Geschmackssache. Mir würde das für mein Auto nicht wirklich gefallen.

Ein anderer möglicher Einbauort wäre doch vielleicht das leer Fach unter dem Radio. Da passen dann auch mindestens zwei solche Rundinnstrumente hinein.
andererseits hat man sie in der Einbauposition wie auf dem Foto dann wirklich im Blick.

Gibt es nicht nachrüstbare Headup Displays, die solche Daten auf die Frontscheibe im unteren Bereich projezieren können?

Womit wir wiedermal ziemlich weit vom Thema abgewichen wären.
Also so eine Ladedruckanzeige fände ich schon auch praktisch. Gerade in anbetracht der Tatsache, das viele von uns doch immer wieder Probleme mit der Motorleistung haben. Vielleicht hilft eine solche Anzeige das Problem besser zu lokalisieren.

[DFman]

Gerade in anbetracht der Tatsache, das viele von uns doch immer wieder Probleme mit der Motorleistung haben. Vielleicht hilft eine solche Anzeige das Problem besser zu lokalisieren.

Exakt dafür habe ich mir mein Interface ja auch gebaut :-) Mein Händler konnte die Motorprobleme allerdings beseitigen, bevor ich mein Gerät zum Einsatz gebracht habe... was mein Händler aber mit seinem Diagnosegerät gesehen hat (und auch mit selbstgebauten Geräten angezeigt werden kann) ist der Kraftstoffdruck, der bei Vollgas plötzlich bei 20 Bar oder so liegt, statt bei 120 Bar... so eine Anzeige kann wirklich helfen. Ich würde aber versuchen, ein Interface mit Display oder so zu nehmen, das wie gesagt alle OBD II Codes anzeigen kann, nicht nur den Ladedruck. Und solche Interfaces gibts wie gesagt, kosten halt über 100,- oder sogar über 200,- EUR. Oder selber bauen. Oder per Handy via Bluetooth Interface, welches man bei ebay auch schonmal für 30,- EUR bekommt...wenn man es in Ebay USA kauft, nicht in Ebay Deutschland...denn die billigen Teile komme eh von Hongkong und co. Da verkauft ein und derselbe Ebayer in Deutschland das Teil für 70,- EUR, in den USA für umgerechnet 30,- EUR... und Versandkosten ist wie gesagt egal, da von Hongkong geliefert wird. Noch dazu haben viele ein Handy im Auto, sparen sich so irgendwo weitere Instrumente zu installieren...

Nachtrag:
Hier
gibts z.B. einen Bausatz inkl. Display, mit dem man auch alles mögliche anzeigen lassen kann. 99,95 EUR kostet der Komplettbausatz im Shop. Der verwendete Chip, der ATmega644, ist der Vorgänger des Chips, den ich bei meinem Interface genommen habe, aber denke der reicht. Kann aber natürlich nicht versprechen, ob der Bausatz in unseren CCs funktioniert. Wie gesagt, habe ein selbstgebautes Interface, was etwas anders aufgebaut ist als der Bausatz. Aber man kann sich im Shop für 5,- EUR auch so ein Gerät mieten, so kann man erst einmal testen, obs im eigenen Wagen funktioniert. Kauft man das Gerät und trägt die Ergebnisse des Tests (obs klappt oder nicht) in eine Liste ein, so bekommt man die 5,- EUR auch verrechnet...

[macs1971]

Hi,

@DFman: Ist ja alles schön, aber für die meisten von uns wahrsscheinlich definitiv zu abgedreht. Wir haben leider nicht alle ein abgeschlossenes Elektrotechnikstudium.


Mir persönlich würde da schon ein einfaches Rundinstrument reichen, auf dem ich den momentanen Ladedruck angezeigt bekommen.

[DFman]

@macs1971:

Hier sind doch einige, die sich mit Elektronik ein wenig auskennen, so ist das nicht. Denke Du unterschätzt manche hier Und der Bausatz ist wirklich simpel, da muss man nur löten können. Ich rede ja nicht davon, dass jeder sich sowas selber bauen soll wie ich es gemacht habe (obwohl auch das einige hier im Forum können). Die Anleitung zum Bausatz ist ausführlich, was wohin kommt ist auch klar. Es wird alles mitgeliefert. Also wer löten kann, wir das ganze ohne Elektrotechnikstudium (welches ich auch nicht habe) hinbekommen. Und man bekommt eine Anzeige, die alles mögliche anzeigen kann (auch mal Kraftststoffdruck, Last und vieles mehr), für einen Preis, der vermutlich noch deutlich unter dem eines Rundinstrumentes liegt, welches auf CAN-Basis den Ladedruck ausliest, oder? Ist halt die Frage, ob dieser Bausatz auch im CC funktioniert. Aber für 5,- EUR kann man es ja testen, wenn man möchte.
Also abgehoben finde ich das ganze nicht. Ein Rundinstrument irgendwo an den CAN-Bus anzuschließen (es wird dafür wohl keinen vorgesehenen Stecker geben) ist ja auch nichts für Leute, die absolut keine Ahnung von Elektronik und Löten haben...
Hier
gibts so einen Trip-Computer mit CAN-Bus Auslese, wenn man nicht selber einen Bausatz zusammenbauen möchte. Kostet natürlich mehr.
Oder
hier
etwas günstiger.

Hier
gibts das ganze schön verpackt in einem Rundinstrument (OLED Display, man kann dort verschiedenste Dinge anzeigen lassen, die über OBD ii auslesbar sind). Aber eben teuer. Daher die kostengünstigere Alternative mit dem Bausatz...wie gesagt, ich sehe diesen Vorschlag mit dem Bausatz als durchaus gerechtfertigt im Anbetracht der Preise für solche Displays.

Alternativ bleibt ja noch der Vorschlag, das Handy zu nutzen (Android, iPhone). Zum Android habe ich ja schon was gesagt, für das iPhone gibts sowas natürlich auch. Mit einem 30 oder 40,- EUR Bluetooth OBD ii Adapter kann man da schon viel ausrichten. Für Leute, die nicht basteln wollen (beim iPhone wäre das ja beim OBD ii Bluetooth Adapter ja eher ein softwaremäßiges basteln), gibt dann

hier

eine fertige Lösung. Liegt preislich auch recht weit oben, man erspart sich dann aber ein zusätzliches Instrument...

Wie gesagt, ist ja alles nicht verbindlich. Sollten ja nur hilfreiche Optionen sein (welche jeder selber umsetzen kann, muss dann auch jeder selber entscheiden, oder?), denn bisher gabs ja zum ursprünglichen Topic wenig Beiträge, stattdessen wurde kräftig Off-Topic diskutiert

[Deep-Sea]

Hach, das Thema CAN, OBD und Co. hat mich auch schon - zumindest in der Theorie - beschäftigt. Ich blick aber noch net wirklich durch.
Peugeot nutzt doch KWP2000, oder? Das baut (in unseren 207ern) auf CAN auf und KWP2000 wiederum wird als OBD-II Protokoll genutzt?! Kommt das so hin?
Kann ich also über KWP2000 weitere Daten lesen, die über OBD-II nicht verfügbar sind? Ich habe mal gelesen das PUG OBD-II eh nur halbherzig implementiert hat.
Oder könnte ich gleich Daten am rohen CAN abgreifen? Das Problem ist aber wohl das gleiche wie beim KWP2000: Welcher Wert hat welche ID und ist wie codiert? :keineahnung:
Fragen über fragen.
Vlt. muss ich einfach mal 'nen CAN-Sniffer anschließen und gucken ^^ ...

[DFman]

Vlt. muss ich einfach mal 'nen CAN-Sniffer anschließen und gucken

Gucken reicht nicht, auch verstehen was man da sieht Viel Spaß Dann lieber direkt an der OBD II Schittstelle abgreifen, da gibts zumindest Standards, wo man nachsehen kann, was wie codiert ist ... so hab ichs jedenfalls gemacht. Einfach irgendwo an die CAN-Leitungen ein Kabel dran stecken und auslesen, ist da eher schwierig. Es sei denn, man kennt die Codes... und die stehen scheinbar noch nicht einmal in den technischen Dokus von Pug für die Werkstätten...

Achso, hatte ich vergessen: Ja, liegst richtig. Der 207er hat einen ganz normalen CAN-Bus nach der international einheitlichen Norm ISO 11898. Als "Übersetzer" zwischen ECU (Motorsteuereinheit) und OBD-II Schnittstelle dient bei Pug im 207er das Keyword protocoll 2000 (KWP 2000) konform ISO 14230-4. An Pin 7 und 15 der OBD-II Schnittstelle habe ich die K-Line und L-Line abgegriffen. Die L-Line benutze ich aber nicht....sie dient bei manchen Fahrzeugen praktisch zum "Aufwecken" der Kommunikation zwischen ECU und OBD Schnittstelle. Beim 207er scheint dies direkt über die K-Line statt über die L-Line (die K-Line ist ja die eigentliche Kommunikationslinie) zu klappen (Für Insider: Übertragung einer 0x33 (5 baud) an die ECU, danach natürlich wieder auf 10400 baud schalten !).
Also wie gesagt: ich würde an der "vorübersetzten" OBD-II Schnittstelle angreifen!

[Deep-Sea]

@DFman:
Schon klar, dass gucken allein nicht ausreicht.
OBD-II ist soweit ja schön, aber wie gesagt bekommt man ja nur einen Teil der Informationen, die durch den CAN-Bus fliegen. Außerdem wäre es gerade für eine Ladedruckanzeige, die ja oft aktualisiert werden muss, interessant, die Daten einfach so zu bekommen und nicht ständig zu pollen. Das belastet nur die Bus-Bandbreite und erhöht die Prozessorlast vom Steuergerät.

Und welcher Wert welche ID hat ... nun, dass das ein Problem ist, sagte ich ja schon. Einige Werte kann man sicher recht einfach herausbekommen, wie z.B. - sofern vorhanden - den aktuell eingelegten Gang. Aber gerade Werte wie den Ladedruck ...
Ist hier denn keiner bei Peugeot in der Entwicklungsabteilung angestellt?

[DFman]

Wenn man beachtet, dass die baudrate bei 10400 Symbolen / Sek liegt (siehe oben mein Nachtrag zu meiner Nachricht 21), und der Ladedruck nur in einem Byte codiert ist, und auch die anderen Daten nicht sehr aufwendig codiert sind, ist das System eigentlich weit davon entfernt, ausgelastet zu sein. Auch wird diese zusätzliche Kommunikation die Bandbreite nicht merklich schmälern. Der Temperatur/Drucksensor des Ansaugtrakts (interne Sensornummer 1311) wird stets von der ECU (1320) ausgelesen, auf diesem Stück noch analog! Über den CAN IS gehts dann digital ab zum BSI. Dort dann über den CAN DIAG über die K-Line zur OBD-II Schnittstelle. Der CAN DIAG ist ein eigener Bus der nur der Diagnose dient, lediglich BSI und OBD-II Schnittstelle verbindet. Ich denke der Bus ist genau für solche Auslesevorgänge vorgesehen, warum dann nicht benutzen. Die Poll-Rate ist ausreichend, der Ladedruck wird ausreichend schnell aktualisiert.

Eine ganz andere Möglichkeit wäre natürlich, den Sensor direkt auszulesen. Wie gesagt: Zwischen ECU und Sensor ist noch alles analog! Die Spannung am Drucksensor geht linear mit dem Druck! 1V entspricht einem Druck von ungefähr 500 mbar, 3V sind ungefähr 1600 mbar... nur so ungefähr, müsste man selber noch kalibrieren. Intern im Sensor wird das Prinzp einer Wheatstonesche Messbrücke benutzt. Der Sensor hat 4 Anschlüsse. Die Anschlüsse 2 (+5V) und 4 (Masse) speisen die Brücke mit Spannung. Ein Arm der Brücke läuft über Piezo Sensoren (Druckmessung), der andere über Vergleichswiderstände. Je nach Druck ändert sich der Widerstand der Piezostrecke. Die Differenz zwischen fester Widerstandsbrücke und variabler Piezostrecke wird mittels OpAmp verstärkt und ausgegeben, und zwar an Pin 1. An Pin 1 liegt letztendlich also das "Drucksignal" an (an Pin 3 ein Temperatursignal). Man benötigt also den Pin 1. Müsste man mal nachmessen, was dort an Spannung gegen GND anliegt, wenn man einmal etwas Ladedruck aufbaut... ggf. kann dort direkt ein analoges Ladedruckmessgerät angeschlossen werden (im Prinzip reich ein Drehspulmessinstrument, man muss sich eben eine passende Skala selber aufzeichnen/kalibrieren), wenn dieses einen ausreichend großen Innenwiederstand hat und somit die Fahrzeugelektronik nicht stört...ansonsten klappt die Entladung des Turbodruckes beim plötzlichen Gas wegnehmen (plötzliches Schließen der Drosselklappe) nicht mehr richtig... es kann Druck gegen die Drosselklappe aufebaut werden, der reflektiert und zurück am Turbolader mit der Zeit dessen Turbinen zerstören kann! Also alles auf eigenes Risiko! Wenn der berechnete Ladedruck durch einen zusätzlichen analogen Abgriff zu sehr modifiziert wird, kann das ganze übel enden! Übernehme kein Gewähr!

[Deep-Sea]

So, ganz langsam zum mitschreiben

Tatsachen:

• Der CAN-Bus ist nach ISO 11898 aufgebaut.
  Gut zu wissen, aber wenn man wirklich nur OBD-II nutzt unwichtig, oder?
• Für OBD-II wird ISO 14230-4 ("KWP2000") mit 10,4 kBaud genutzt.
  Also klar, K-line und L-line (Grundlegend definiert in ISO 9141).

Frage:

• Was hat nun aber CAN DIAG damit zu tun?
• Kann man über KWP2000 nun nicht trotzdem noch andere Dinge lesen sofern man die ID kennen würde? Denn darüber konfigurieren die Werkstätten doch das ganze Auto, oder?

Nachtrag:
So, endlich mal die ISO-Normen gefunden. Ich werd's die Tage mal testen ...

[DFman]

Tatsachen:

• Der CAN-Bus ist nach ISO 11898 aufgebaut.
  Gut zu wissen, aber wenn man wirklich nur OBD-II nutzt unwichtig, oder?
• Für OBD-II wird ISO 14230-4 ("KWP2000") mit 10,4 kBaud genutzt.
  Also klar, K-line und L-line (Grundlegend definiert in ISO 9141).

Korrekt, der CAN-Bus selber spielt keine direkte Rolle, wenn man nur über die OBD-II Schnittstelle ausliest. Kann man also getrost vergessen. Zum zweiten Punkt: K-line ja, L-line wird bei Pug nicht benutzt.

Frage:

• Was hat nun aber CAN DIAG damit zu tun?
• Wo bekomme ich mal Infos, sprich Protokollbeschreibungen, zu KWP2000? Ich finde einfach nichts gescheites.
• Kann man über KWP2000 nun nicht trotzdem noch andere Dinge lesen sofern man die ID kennen würde? Denn darüber konfigurieren die Werkstätten doch das ganze Auto, oder?

Pug unterteilt das digitale Bus System in verschiedene Sub-Busse. So z.B. in den Can-comfort (für Radio, Klima und co), den CAN-Diag (Diagnose-Can, verbindung zwischen BSI und OBD-II Schnittstelle) usw...

Es gibt zahlreiche Quellen, wo man die entsprechenden ISO Normen einsehen kann. Die ISO 14230-4 findest Du

hier.

Wie man dort sieht, wird vieles von den Normen ISO 14230-1 bis 3 übernommen, bzw. sind sie Bestandteil, vor allem im Bereich der OBD. Diese Normen findest Du hier:

1

2

3

In der 14230-1 findest Du z.B. Hinweise, was man beachten muss, wenn man sich selber ein OBD-II Interface bauen möchte. In der 14230-2 und 3 gehts dann ans eingemachte (wobei die 14230-2 sich nur mit dem Data Link Layer beschäftigt), dort findest Du viele Infos, wie der Chip über KWP2000 kommunizieren muss (bei mir fand unter anderem der ATmega644PA Einsatz).

Über das KWP2000 Protokoll können nun diverse Pids abgefragt werden, welche im SAE J1979 Standard verankert sind (in Europa ISO 15031-5, aber ist eh alles gleich). So liefert der PID 0B im Mode 1 den "Intake manifold absolute pressure" zurück. Den Ladedruck. SAE J1979 ist also der Normsatz, KWP2000 das unterlagerte Bussystem. Bzw. genauer: Das zugrunde liegende Bussystem ist das K-Line System nach ISO 9141 (bidirektionaler Ein-Draht-Bus), das Kommunikationsprotokoll ist KWP2000. Es liegt mit dem K-Line Bus also ein zeichenbasierter Bus (UART) vor, kein bitstrombasierter Bus wie beim CAN nach ISO 11898 und andere. Dies nur als erklärende Ergänzung.


Ja, die Werkstätten können über das PPS (Peugeot Planet System) das Fahrzeug über die OBD-II Schnittstelle konfigurieren. Im Prinzip ist sowas explizit im KWP2000 Protokoll verankert. Über die SID 34h kann man den Service "Request Download" aufrufen (Initialisierung der Übertragung von Datenblöcken vom Diagnosegerät aus an ein Steuergerät), danach per SID 36h ("Transfer Data") den eigentlichen Datentransfer starten. So kann man beispielsweise die Motorsteuersoftware (ECU) neu flashen Aber ganz ehrlich: Das Thema wird mir dann etwas zu heiß, denke hier möchte ich nicht weiter ins Detail gehen. In meinen OBD-II Interfaces habe ich solche Requests gar nicht erst implementiert, so dass ich sicher sein kann, dass nichts geschrieben werden kann.

Aber ich denke, das ganze wird dann langsam doch wieder off Topic... hatte ja eigentlich versucht, mit dem Tipp, ein kommerzielles OBD-II Interface zu nutzen (oder einen Bausatz), wieder BTT zu kommen...nun wirds aber wieder sehr speziell...

Denke, man sollte lieber überlegen, obs eine nette kommerzielle Lösung für die Ladedruckanzeige gibt (OBD-II basiert) oder man einfach das analoge Spannungssignal am Ladedrucksensor wie oben von mir erklärt abgreift und verarbeitet... zur OBD-II Programmierung kann man dann ja vielleicht einen extra Thread aufmachen?

[Deep-Sea]

Ja jetzt postest du die Normen, wo ich sie schon selbst gefunden habe *gg* aber trotzdem danke
Na gut, so weit habe ich jetzt alles kapiert. Sieht dann ja doch gar nicht so schwer aus wie gedacht, vlt. komm ich noch vor dem Wochenende dazu, mal 'ne PID auszulesen - die englische Wikipedia hat darüber ja 'ne recht detaillierte Liste: OBD-II PIDs.

Des weiteren hatte ich natürlich nicht vor, wichtige Daten des Autos mittels KWP2000 auf gut Glück zu manipulieren, aber ich bin halt neugierig

Extra Thread?! Joa mal gucken ob dafür Interesse vorhanden ist ...

[DFman]

Das softwaremäßige Auslesen ist ja nicht das Problem. Ich nutze wie gesagt OBD-II Freeware dazu! Warum mir die Mühe machen, dasselber auseinander zu friemeln. Nur bei der Stand-alone Lösung bin ich nicht ums manuelle PID Auslesen herumgekommen.

Womit möchtest Du das ganze denn auslesen? Was selbst gebautes?

Des weiteren hatte ich natürlich nicht vor, wichtige Daten des Autos mittels KWP2000 auf gut Glück zu manipulieren, aber ich bin halt neugierig

Ganz bekannt ist in diesem Zusammenhang KWP2000 Plus...das ist eine kommerzielle Hardware und Software Lösung, mit der man die ECU flashen kann. Tuner benutzten sowas oft, um eine modifizierte Motorsteuerung aufzuspielen... aber wie gesagt, selber da was flashen, das ist möglich. Aber dafür bräuchte ich viel Zeit, um mich wirklich zu vergewissern, was ich da genau mache...momentan zeitlich nicht möglich.

Extra Thread?! Joa mal gucken ob dafür Interesse vorhanden ist ...

Na sagen wir mal Du versuchst nicht irgend einen PID auszulesen, sondern DEN Pid, der den Ladedruck wiedergibt...dann ist das ganze zumindest noch etwas Thread konform

[Deep-Sea]

Ja mit fertiger Soft- und Hardware etwas auszulesen schafft ja jeder
Ich weiß es noch nicht genau, aber ich denke mal es wird ein µC werden. Allerdings ein PIC und kein Atmel (Ich will ja aber irgendwie noch 'nen kleinen Touchscreen ansteuern ... da habe ich Angst, dass die Kleinen damit überfordert sein könnten )
Vor dem Wochenende die PID (*zwinker*) auszulesen wird nun doch nix, da ich mich entschieden habe erst mal einen OBD-II Stecker und einen IC zum anpassen der Pegel zu bestellen. Bzw. ich hab's schon bestellt, jetzt heißt es warten. Ist aber besser als da mit losen Drähten und 'ner zusammengebastelten Platine ran zu gehen.

Vom flashen mittels KWP2000 habe ich schon gehört, aber das ist mir zu heiß. Wenn du es mal gepackt hast und dein Auto einige zehntausend Kilometer überlebt, komm ich vlt. auf dich zurück - wenn der Preis stimmt

[DFman]

Hab ja beides gemacht, bei der Standalone Lösung habe ich Hard- und Software (Assembler, war in diesem Falle einfacher als in C) selber zusammengebastelt, bei der EML327 Lösung nur die Hardware... geht dann per USB an den PC, dort gibts Freeware Progs, die den EML327 unterstützen. Ob PIC oder Atmel ist im Prinzip egal. Ich mag die PICs nicht so sehr, allein schon wegen dem banked memory access. Aber bei zusätzlicher Peripherie kann ein PIC teilweise etwas besser zu handeln sein als ein Atmel. Aber bis auf ein LCD Display hab ich nicht viel zu steuern gehabt. Und das in Assembler zu programmieren ist dann mit dem Atmel irgendwie einfacher...

Bin dann mal gespannt, ob Du erfolgreich DEN Pid auslesen kannst...

[Deep-Sea]

Und hat das Auslesen geklappt? Hast du das nur wegen deinen Motorproblemen gemacht?

So lange ich auf den Stecker + IC warte, kümmern wir uns doch schon mal um Dinge, die eig. noch weit in der Zukunft liegen
Angenommen man liest den Ladedruck (und sonstige interessante Dinge) erfolgreich aus. Wie und wo stellt man sie nun dar?
Ich persönlich bin ja für die A-Säule. Aber aus GFK da einen "Aufsatz" zu bauen ... sicher möglich, wenn man Erfahrung mit GFK hat, die habe ich aber nicht.
Dann noch Rundinstrumente selber bauen ...
Wird ein ganz schönes Projekt ...
Immerhin habe ich schon mal ein Ladedruck-Symbol gezeichnet - also haben wir ja schon das Wichtigste fertig