Priusfreunde.de

Hallo Freunde!

Letztens habe ich eine Idee, meine Hybridbaterie auf Herz und Nieren zu prüfen.

Klar, geht es einfach mit einem guten OBD-Adapter und entsprechender App.

Meine Idee war aber, zwei OBDLinks (die ich zufällig habe), gleichzeitig an das OBDII anzuschließen, damit ich mein Hybrid Assistant, wie immer, laufen und loggen lassen kann, das zweite OBDLink würde dann die Batteriedaten auf einem zweiten Smartphone mit TORQUE auslesen und loggen.

Soweit die Idee.

Ein Y-OBD-Kabel gekauft, ins Auto eingesteckt, an anderen Enden ein OBDLink MX+ für Hybrid Assistant und ein OBDLink MX für TORQUE eingesteckt. Beide Geräte arbeiten mit Bluetooth.
Zwei Smartphones an je ein Gerät gekoppelt, die Apps gestartet und losgefahren bin ich.

Bei der Fahrt habe ich beim Hybrid Assistant gemerkt, dass die angezeigten Daten nicht so konsistent und sicher waren, wie sonst. Da tanzten die Werte schon häufig deutlich aus der Reihe...
Später, beim auswerten der von TORQUE gesammelten Daten musste ich leider auch feststellen, dass viele Werte einfach nicht glaubwürdig waren...

Jetzt frage ich mich, was der Grund dafür wohl sein kann.

Interferenzen beim Bluetooth? Eher nicht, da Bluetooth Frequency Hopping nutzt mit etwa 1600 Hopps pro Sekunde - da sind Interferenzen eher unwahrscheinlich. Es sei denn, jemand weiß es besser

Konflikte auf der CAN-Bus? Könnte sein, aber ich dachte immer, dass die Werte nicht von den OBDLinks aktiv angefordert werden, sondern die lauschen nur, was auf der Bus kommt und zeigen es an. In diesem Fall wären Konflikte eher nicht möglich.

Es sei denn, die Geräte fragen aktiv die Werte ab - da könnte es zu Konflikten kommen - weiß es jemand genauer?

Hat vielleicht jemand schon sowas probiert?

Grüße

Mat

Lares schrieb:
Es sei denn, die Geräte fragen aktiv die Werte ab - da könnte es zu Konflikten kommen
Natürlich ist das so.
Die Kommunikation zwischen dem oder den Steuergerät(en) des Fahrzeugs (Server) und dem angeschlossenen Tester (Client) erfolgt als Frage- und Antwortspiel.
www.obd-2.de/programmierer-tips.html

Lares schrieb:
Jetzt frage ich mich, was der Grund dafür wohl sein kann.

ja, ich habe auch so ein Y-Kabel, und irgendwie funktionieren ZWEI Dongles nicht gleichzeitig, selbst dann nicht, wenn die eine Dongle 'nur da' ist - aber ansonsten nix macht.

ich vermute stark (ohne es wirklich weiter gemessen zu haben) - dass es an der doppelten CAN-BUS Terminierung liegt ...
(weil ja jetzt beide Dongles den Bus parallel terminieren, jeweils mit 120 Ohm ...)

Aber nochmal: Nur meine Vermutung...

Die Beobachtung an sich kann ich aber bestätigen - geht nicht wirklich...

Interferenzen beim Bluetooth?

absolut ausgeschlossen - da sind keine Probleme zu erwarten.

Konflikte auf der CAN-Bus?

EIGENTLICH sollte das der CAN-Chip (ELM327/STN11xx) (bzw. mehrere) autom. machen. (Stichwort: Collision-Avoidance)


Könnte sein, aber ich dachte immer, dass die Werte nicht von den OBDLinks aktiv angefordert werden, sondern die lauschen nur, was auf der Bus kommt und zeigen es an. In diesem Fall wären Konflikte eher nicht möglich.


Es gibt 'unsolicited' Nachrichten (beispielsweise die Rad-drehzahlen oder Geschwindigkeit) - die tatsaechlich 'einfach so, ungefragt' gesendet werden - aber die meisten Daten, die HA haben will - muessen aktiv angefragt werden ...

Es sei denn, die Geräte fragen aktiv die Werte ab - da könnte es zu Konflikten kommen - weiß es jemand genauer?

...gute Frage, diesen Punkt weiss ich nicht 100% sicher.

Meine bisherige Vorstellung (was ich aus den ELM-Manuals lese ) ist - dass beim OBD-CAN Protokoll (also nicht LIN!!!) dies praktisch egal ist, weil der ELM/STN11xx chip automatisch Antworten auf selbst abgeschickte Befehle sucht/filtert/anzeigt.

Und damit sollten mehrere ELM/STN-Chips am gleichen CAN-BUS eigentlich gehen ...

Hat vielleicht jemand schon sowas probiert?

wie oben schon geschrieben: Ja ausprobiert, geht aber nicht wirklich.

... geht elektrisch nix kaputt, aber faellt halt sofort auf, dass da was nicht stimmen kann

Vielleicht kann aber jemand, der CAN-Zeug hauptberuflich macht, dies genauer erklaeren

Ich hab im Prius meiner Frau den ScanGaugeII drin.
"Notfalls" oder für Langstrecke hänge ich da auch über Y-Kabel noch ein Bluetooth Dongle mit HA dran. (Ich fahre gerne mit HA)

Auch dort muss man einfach feststellen das in den Messwerten gelegentlich ein Fehler auftritt. Statistisch ist das aber nicht relevant.

Der ScanGaugeII liest aber auch nicht so schnell.

Bei zwei Dongels, die beide Versuchen so viele Daten wie Möglich zu bekommen, ist am Ende sicher viel mehr Schrott dabei.

Also zuerst ein Danke an alle - ich dachte, ich bekomme keine relevanten Antworten und, wie man sieht, gibt es hier schon Leute die einiges über den Durchschnitt ausprobieren

Es würde schon Sinn machen, was hirni über die Terminierung schreibt - ist mehrere Takten im Gehirn wert.

Außerdem habe ich nicht geschrieben, was ich da alles über TORQUE abgefragt und geloggt habe. Es waren alle Spannungswerte der 14 Zellen, alle inneren Widerstände der Zellen, Nummer der Zellen mit der niedrigsten und höchsten Spannung, Differenz zwischen der höchsten und niedrigsten Spannung, Temperaturen der Batterie, den Strom und einiges mehr, was TORQUE von sich schon abfragt...

Wie man sieht, war das schon eine Menge an Daten. Jetzt zeigt TORQUE die Daten ja an und loggt sie mit - ob sie jetzt doppelt abgefragt werden? Möglich - keine Ahnung.

HA braucht auch ne menge an Daten...

Da war schon viel los auf dem CAN-BUS

Hirni hat auch geschrieben, dass das ganze nicht wirklich funktioniert, "selbst dann nicht, wenn die eine Dongle 'nur da' ist - aber ansonsten nix macht."

Das muss ich auch mal versuchen. Ich glaube, ich habe eine Dongle raus genommen um doch brauchbare Batteriedaten zu bekommen.

Man könnte auch mal eine Dongle in Alufolie einwickeln und schauen ob sich was ändert. Mache ich bei Gelegenheit.

Auf jeden Fall bleibe ich noch ne Weile dabei - es müsste doch gehen

Grüße

Mat

Wenn man eine BUS-Schnittstelle mit zwei Geräten bedienen will, dann braucht es ein Steuergerät in der Mitte des "Y", das die Kommunikation entsprechend verteilt. Nur dann ist es ne saubere Sache.
Bei den PC-Netzwerken heißen die Teile übrigens "Switch".

Hmmm... Soweit ich es verstanden habe, sind Swiches bei VAN-Bus nicht notwendig...

Lediglich können (müssen nicht) s.g. Buswächter eingesetzt werden.

Wikipedia sagt:
"Der CAN-Bus arbeitet nach dem „Multi-Master-Prinzip" d. h., er verbindet mehrere gleichberechtigte Steuergeräte."

Könntest Du es weiter erläutern?

Mat

Hallo,

auch wenn ich mich nicht speziell mit CAN-Bus auskenne, dürfte es Analogien zu anderen (Feld-) Bussystemen geben.
Bei einem 'linearen' Bus sind meist die Enden bzw. letzten Teilnehmer terminiert. Der OBD-Stecker dürfte kein Ende sein, da ja nicht generell ein Teilnehmer dranhängt.
Die Protokolle sind seriell, wobei ein Telegramm eine gewisse Struktur hat. Teil dieser Struktur ist in der Regel eine Fehlerüberwachung, z.B. durch CRC-Checksummen. Wird über die CRC ein Telegramm als fehlerhaft erkannt, sollte es verworfen werden und erneut angefragt werden. Das führt zu einer geringeren Transferrate als im ungestörten Zustand.
Die CRC kann aber nicht alle Fehler erkennen, hier würde das Telegramm dann zwar angenommen werden, aber der Daten-Inhalt ist 'Müll'.
Teilnehmer melden sich auch schon mal hier-und-da im Bus, um anzuzeigen, daß sie da sind - auch wenn sie nach außen hin inaktiv sind.
So gesehen kann ich mir durchaus vorstellen, das z.B. ein HA, der viel am Bus 'quatscht', sich mit anderen Teilnehmern kabbelt und die Datenrate / -konsistenz abnimmt.

Gruß,
Horst

Wieder einmal - soweit ich es verstanden habe, sendet jedes Gerät an dem Bus "Nachrichten" sozusagen an alle.

Jede "Nachricht" trägt eine Priorität in sich. Je niedriger die Priorität-Nummer, um so dringlicher ist die Nachricht und um so eher kann sie verschickt werden.

Geräte, die Nachrichten mir niedrigerer Priorität senden wollen müssen warten bis nichts dringlicheres gesendet werden will.

Jetzt frage ich mich, welche Priorität setzen die OBDLinks bzw. HA oder TORQUE in die Nachrichten/Anfragen, die sie versenden wollen?

Ist das frei einstellbar bei der Software? Mus man sich da an irgendwelche Regeln halten?

Ich kann mir nicht vorstellen, dass z.B. ein HA eine dringlichere Nachricht versenden kann, als z.B. ABS oder die Airbags :O

Was passiert, wenn zwei Geräte Nachrichten mit der selben Priorität versenden wollen, und dies oft

Ich glaube irgendwo gelesen zu haben, dass es bei CAN-Bus auch ein Mechanismus gibt, dass, wenn ich eine Anfrage versende, erkenne ich auch die Antwort in der Flut der Daten am Bus. Das hat zufolge, dass sich ein Gerät nicht mit Nachrichten, die nicht an ihn gerichtet sind oder Antworten an fremde Fragen beschäftigen muss.

Das wiederum würde voraussetzen, dass beide Dongles Antworten auf "eigene" Fragen erkennen sollten und es zu keinen Konflikten kommen dürfte...

Alles sehr interessant, aber ich glaube mir fehlt das Wissen - die Übersicht über das große Ganze...

Verloren im Dschungel des CAN-Bus...

Mat

Bei Bus-Systemen habe einzelne Geräte in der Regel auch eine Identifikationsnummer (kurz ID). Damit alle Geräte auch wissen, wer etwas angefragt hat und für wen die Antwort ist. Je nach System nutzt man feste IDs, bei manchen Protokollen werden die aber auch z.T. dynamisch angegeben (z.B. der USB-Bus am Computer). Jetzt könnte es sein - aber ich habe mich nie mit dem CAN-Bus speziell befaßt - dass ein Gerät am Diagnoseport immer die gleiche ID haben soll. Dafür gibt es ja genau einen Stecker im Auto, würde also hier durchaus Sinn machen. Also gehen wir mal davon aus, dass ein ODB-2-Bluetooth-Adapter immer die ID 0 hat. Dann würden an einem Y-Kabel auch zwei Geräte mit der ID 0 arbeiten.

Unabhängig von der Terminierung der Leitungsenden wüssten dann die Geräte aber nicht, dass sie eine Antwort erhalten, die gar nicht zu ihrer "Frage" paßt. Und dann hätte man auch falsche Werte.

Es gibt leider viele verschiedene Bus-Systeme und Protokolle, einige sind dabei identisch, heißen nur anders, aber es kommt immer auf den Einsatz an. Bei manchen Protokollen gibt es max. acht Geräte (z.B. das alte SCSI-Festplatten-Prootkoll bzw. der SCSI-Anschluß, war bis Ende der 90er noch verbreitet), andere können da viel, viel mehr.

Zur Terminierung: bei hochfrequenten Signalen können elektrische Ströme an einem nicht terminierten Ende "zurückprallen", ähnlich wie ein Ball, den man in ein geschlossenes Rohr wirft. Das klingt jetzt etwas an den Haaren herbeigezogen, ist aber nachweisbar. Bei alten Ethernet-Verbindungen hat man früher Koaxilkabel genutzt, auch hier was ein Abschlußwiderstand notwendig. Und auch bei KabelTV ist in der Regel in der letzten Dose ein solcher verbaut, um das Signal am Ende zu "reinigen", damit diese Reflektionen nicht die Daten stören.

Lares schrieb:
....
Das wiederum würde voraussetzen, dass beide Dongles Antworten auf "eigene" Fragen erkennen sollten und es zu keinen Konflikten kommen dürfte...


Ich denke, die Konflikte kommen eher beim Senden zustande.
Nehmen wir mal TCP/IP : ein Teilnehmer will sein Telegramm senden und stellt beim Kontrollhorchen auf dem Bus fest, daß jemand anderes gleichzeitig sendet (collision detect). Er wartet daraufhin eine zufällige Zeit und probiert es nochmal. Da der andere Sender die Kollision auch gemerkt hat und ebenso eine zufällige Zeit wartet, ist die Wahrscheinlichkeit gering, daß beide wieder zusammenrasseln. (carrier sense multiple access)

Lediglich ein 'Dauerbrabbler' könnte den Bus blockieren (da kommen dann Buswächter ins Spiel...).

Ein wichtiges Steuergerät wartet nur möglichst kurz, ein Gerät niedriger Priorität wird eher was länger warten.
Auf jeden Fall erhöht die Anzahl der Busteilnehmer (insbesondere bei gleicher Priorität) die Wahrscheinlichkeit von Kollisionen.

Gruß,
Horst

Sooo... Ich habe mich etwas umgeschaut in diversen Foren, z.B. bei Torque, bei Priuschat.com und bei ScanTool Forum.

Das Thema scheint seit langem ab und an im Gespräch zu sein und man kommt nicht wirklich zu einer schlüssigen Lösung.

Z.B. arbeitet ScanGauge anscheinend mit anderen OBD-Adaptern und Y-Split-Kabel ohne Probleme, aber Kombinationen von anderen Adaptern (z.B. zwei Bluetooth Adapter u.Ä.) nicht.

Kann daran liegen, dass ScanGauge nur einige wenige PIDs abfragt und anzeigt (kann sein, dass er sogar nicht einmal die Dinge aktiv abfragt, sondern nur passiv am CAN-Bus lauscht).

Vielerorts wird gesagt, dass wenn ein Adapter nur den Bus abhört und der Andere mit ihm Quatscht (Frage-Antwort), dann soll es gehen.

Wenn beide Fragen auf den Bus schicken und Antworten abwarten, dann noch mir den Fragen die Gleichen ECUs anpeilen, dann kommt es zu Konflikten.

Dann habe ich beim Torque-Forum Folgendes gefunden:
torque-bhp.com/forums/?wpforumaction=viewtopic&t=6422.0

Dort heißt es am Ende:
"I would guess that both apps are
using the same tester address which
would confuse the network… but I
could be wrong."

Also beide Apps nutzen die gleiche Tester-Adresse - wen dem so wäre, wäre es offensichtlich, dass es zu Konflikten kommen muss!
Dann würde es nicht so viel von den Adaptern selber abhängig, sondern von den Apps, die durch sie Zugriff zum Bus erlangen.

Die Tester-Adresse könne man mit dem AT-Kommando TA einstellen (ATTA hh), aber da lehne ich mich schon sowieso viel zu weit aus dem Fenster...

Gibt es hier jemanden der mehr erfahren als ich in Sachen Netzwerke ist?

Jedes Kommentar, jeder Gedanke wäre wertvoll!

Mat

Wie ich schon geschrieben hatte, auch mit Scan-GaugeII gibt es offenbar unbemerkte Kollisionen.
Die sind halt selten, weil ScanGauge so langsam ist, das man zuschauen kann, wie ein Wert nach dem Anderen auf dem Display aktualisiert wird.

Berücksichtigt man weiterhin, das bei "OBD-Adaptern" die Geschwindigkeit unterschiedlich ist, scheint der Adapter / die Bluetooth-Strecke der Flaschenhals zu sein, nicht der CAN-Bus.
Also hat der CAN BUS bei EINEM BT-Adapter noch etwas Reserven, so dass Abfragen des ScanGaugeII meistens in Phasen fallen, wo der Bus Zeit hat.

Mit zwei schnellen OBD-Adaptern kommt es zu vielen Kollisionen, also entsteht viel Müll auf dem Bus.
Das hatte ich oben aber alles schon geschrieben.....

Zwei Adapter ist jedenfalls Missbräuchliche Nutzung der Schnittstelle. Dafür wurden die Protokolle auf dem Bus sicher nicht entwickelt.

Also, wie Du schreibst, frankenfrank, der Bus müsste Luft nach oben haben, aber auch wenn das nicht der Fall wäre, und die Apps, die hinter den Adaptern das Geschehen steuern den Regeln entsprechen würden, dürfte es höchstens zu nicht beantworteten Anfragen kommen, nicht aber zu Situation, wo eine App die Antworten der anderen liest und für eigene hält.

Solchen Fall vermute ich stark nachdem ich einiges gelesen habe.

Klar, wurde die OBD-Schnittstelle nicht explizit dafür gebaut, aber auf dem CAN-Bus dürfen ja viele ECUs stehen und über den Bus kommunizieren - eben solange sie es Regelkonform machen.

Wenn beide Apps (oder beide Adapter) richtig unterschiedliche Nodes im Netz darstellen würden (sprich unterschiedliche IDs hätten), dürfte es zu keinen Konflikten kommen - beide Apps/Adapter könnten eigene Frames auseinander halten.

Liegt in meinen Überlegungen ein Fehler vor?

Und ob zwei Adapter Missbräuchliche Nutzung der Schnittstelle darstellen? Es gibt auf dem Bus ja mehrere "Adapter" (ECUs), die perfekt miteinander kommunizieren...

Ich bin wirklich kein Netzwerkmensch, aber ich finde es mindestens einer Anfrage an die Entwickler der Apps wert, um zu checken, ob sie nicht wirklich eine "default Node ID" nutzen, und die ist dann bei beiden Apss die selbe.

Findet Ihr nicht?

Mat

Hallo,
ich hab mal nachgeschaut - beim CAN-Bus wird ein modifiziertes CSMA-CD-Verfahren (hatte ich oben beschrieben) eingesetzt. Die Modifikation priorisiert Teilnehmer mit hoher ID, damit wichtiger Datentransfer funktioniert.
Adapter unterschiedlicher ID dürfen ruhig kollidieren, das wird ja durch das Verfahren aufgelöst.
Es gibt die Faustregel, daß bis 30% Bandbreitennutzung Kollisionen zwar durchaus vorkommen, aber praktisch keine Auswirkung haben. Ist jedoch nur noch 30% Bandbreite frei (also 70% Nutzung), wird die Kommunikation wegen zu vieler Kollisionen zunehmend zusammenbrechen.
Ein Teilnehmer, der viel quasselt, belastet somit den Bus bei bereits hoher Last überproportional.

Wenn Adapter zunächst mit gleicher ID senden und nicht auf freie IDs ausweichen, kann das übrigens locker zu Datenmüll in den Antworten führen.

Gruß,
Horst