Priusfreunde.de

Hallo Horst!

hosc schrieb:
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.

Hier
en.wikipedia.org/wiki/CAN_bus#Data_transmission
gibt es dazu ein schönes Bild.
Wie ich es verstanden habe, werden Teilnehmer mit niedriger ID priorisiert, obwohl das auf den Prozess der Priorisierung selbst keinen Einfluss hat. Das Bild veranschaulicht das sehr gut (in deutscher Wikipedia gibt es dieses Bildchen nicht).
Außerdem entsteht dabei kein Datenmüll auf dem Bus - der Teilnehmer mit höherer ID hört auf zu senden und probiert es später - der Datenfluss wird nicht beeinträchtigt.


Ein Teilnehmer, der viel quasselt, belastet somit den Bus bei bereits hoher Last überproportional.

Das stimmt gewiss, aber der Bus müsste da schon Reserven haben und auch bei Überlastung dürfte es nicht zu "Verwechslungen" bei den Antworten kommen.


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.
Eben dieses würde/müsste zu Verwechslungen bei den empfangenen Antworten führen.

Ich versuche mal beim TORQUE-Forum eine Frage dazu zu stellen - mal sehen, ob sich da ein Entwickler findet, der Antworten will

Kann man die HA-Entwickler irgendwie erreichen? Antworten sie auch auf solch skurrile Fragen?

Grüße

Mat

Lares schrieb:
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...

diese TESTER-Address - existiert nur fuer den LIN-Bus. Der LIN-Bus funktioniert ueber die 'K/L'-Anschluesse des OBD-Steckers. (pin 7 und pin 15)
Manche aeltere Toyotas haben diesen Bus verwendet - mit dem KWP2000 Protokoll

nach meinem Wissenstand, kann man diesen Bus im Prius mit 'nem ELM327/STN11xx nicht korrekt ansprechen, weil die zwingend notwendige Initialisierung fehlschlaegt... (init_timing/Baud-rate issue wegen 'krummer' Baud-rate)

der OBD-II CAN-Bus - braucht keine 'Tester Address'.

www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DS.pdf

ein OBDLink-MX benutzt einen STN11xx Chip, der 'by design' 100% ELM327-kompatibel sein will ... also gilt alles was im PDF steht 1:1 fuer den STN11xx.

hirni schrieb:
der OBD-II CAN-Bus - braucht keine 'Tester Address'.
www.elmelectronics.com/wp-content/uploads/2016/07/ELM327DS.pdf
ein OBDLink-MX benutzt einen STN11xx Chip, der 'by design' 100% ELM327-kompatibel sein will ... also gilt alles was im PDF steht 1:1 fuer den STN11xx.
Ich weiss nicht wirklich, was ich dazu meinen soll...
Aus o.g. PDF, Seite 27 zu TA hh Komando würde ich da was anderes herauslesen...

Andere Quellen würden dieses mindesten milde unterstützen - diese ID wird in den Header der Frame übernommen und mit jeder Anfrage versendet. Aufgrund u.A. des Headers wird die Priorisierung gemacht - habe ich da etwas völlig falsch verstanden?

Mat

Lares schrieb:
habe ich da etwas völlig falsch verstanden?

ich interpretiere das so, dass es nur fuer SAE J1939 gilt.

Meine bluetooth-Snoops von HA sagen, dass HA nur 'ATSP6' benutzt ... - sollte also theoretisch nicht in Gebrauch sein.

Logs von der Carista-App - die 'wuseln' da mehr herum - wobei ich da den Eindruck habe, dass vieles davon 'Ablenkung' ist.
(damit man die Snoop-Interpretierung verwirrender macht)

...und um wieder zum Thema zurueck zu kommen:
Ich kann immer noch nicht verstehen, warum die passive Anwesenheit eines zweiten OBD-Adapters den anderen (aktiven) Adapter so "in die Knie" zwingt ... - meine akt. Vorstellung ist immer noch, dass da elektrisch (Terminierung etc.) sich was 'verbiegt' ...

Ich habe bei Torque nachgefragt - hier:
torque-bhp.com/forums/?wpforumaction=viewtopic&t=14320.00

und bei scantool.net Forum:
www.scantool.net/forum/index.php?topic=16134.0
(hier noch keine Antworten, aber es ist noch früh im Amiland).

Nicht vergessen - Torque kann da etwas anders ticken als HA.

Die Tatsache, dass ein Dongle allein (ohne App, ohne Bluetooth Anschluss) auch Probleme verursacht habe ich noch nicht gecheckt, aber ich glaube Dir doch... Dann ist das wirklich merkwürdig.

Ich versuche derzeit so viel Information wie möglich zusammenzutragen - mal sehen was das bringt.

Gruß

Mat

PS. Und ATSP6 gibt dir den ISO 15765-4 CAN (11 bit ID, 500kbaud)-Protokoll, also doch Protokoll mit IDs als Priorisierung?

hirni schrieb:

...und um wieder zum Thema zurueck zu kommen:
Ich kann immer noch nicht verstehen, warum die passive Anwesenheit eines zweiten OBD-Adapters den anderen (aktiven) Adapter so "in die Knie" zwingt ... - meine akt. Vorstellung ist immer noch, dass da elektrisch (Terminierung etc.) sich was 'verbiegt' ...
Gerade bin ich nach einer 14,8km langen Fahrt mit dem Split-Kabel und zwei OBDLinks angeschlossen, wobei nur HA von einem von ihnen Gebrauch machte.

Ich konnte keine Auffälligkeiten feststellen. HA verhielt sich völlig normal, wie jedes andere mal. Ich habe mir noch mal die Daten von HA angeschaut, als auch Torque zum CAN-Bus quatschte - da sind die Spitzen deutlich zu erkennen.
Dies mal ist aber nichts dergleichen zu sehen.

Also - ich kann Deine Beobachtung, hirni, NICHT bestätigen.

Der unbenutzte OBDLink ging dann irgendwann in Standby-Modus. Ich habe den am Ende der Fahrt noch mal abgekoppelt und noch mal eingesteckt, damit er wieder wach wird, aber weiterhin keine Auffälligkeiten.

Gruß

Mat

Lares schrieb:

Also - ich kann Deine Beobachtung, hirni, NICHT bestätigen.


...interessant. ich habe halt keine zwei OBDLink-MX, sondern einen MX und einen Carista (was ein rel. gut gemachter China-Klon ist) ...
Und auch wenn ich z.B. so einen Auto-Door-lock-Dongle dran habe - funktionieren dann im Endeffekt beide nicht. (HA ist zu zaeh, und der Door-Lock-Adapter macht nur sporadisch das was er soll)

... interessant.
ich muss mal die Widerstaende ausmessen - dann sollte das mit der Terminierung klarer sein ...

Dazu kann ich Dir nur noch sagen, dass der User ChristianB eine sehr ähnliche Konfiguration wie Du benutzt, schreibt aber nichts von irgendwelchen Scherereien zwischen den beiden Dongles.

Mat

Richtig. Klappt alles wunderbar: OBDLink ist mit dem Smartphone verbunden und füttert den HybridAssistant und beim ersten Anfahren werden vom anderen OBD-Stecker automatisch die Türen verriegelt. Funktioniert seit geschätzt zwei Jahren problemlos.

Also, Liebe Freunde!

Nach umfangreicher Recherche, vielem Lesen und Dazulernen muss ich einen Schlussstrich ziehen.

Leider sieht es danach aus, dass zwei OBD-Adapter an einem Auto nur unter sehr speziellen Bedingungen störungsfrei arbeiten können.

So wie ich es wollte, kommt es zu erheblichen Konflikten auf der CAN-Bus, die nur mit einem hohen Softwareaufwand zu vermeiden wären, und auch dass nicht ganz sicher...

Wann es gelingen kann?

Wenn einer der Adapter mit dem Netzwerk normal kommuniziert (Anfrage vom Adapter an einen bestimmten ECU im Netzwerk und dann lauschen nach der Antwort) und gleichzeitig wenn der andere Adapter nur die Kommunikation auf dem CAN-Bus abhört, aber nicht dazwischen quatscht.

Also HA und Torque wird nicht funzen.

Es kann auch gelingen, wenn die Adapter sich nicht in die Quere kommen - das heißt, jeder Adapter "spricht" nur mit den ECUs, mit den der Andere NICHT "spricht".
Also, wenn der eine nur mit Motor quatscht, kann der andere ohne Probleme mit der Batterie "sich unterhalten".

Sowas, wie ein OBD-Adapter z.B. mit HA und ein "Adapter", der nur an bestimmten Zeitpunkten sich z.B. an den Comfort-Computer wendet und sagt ihm "verschließe die Türen" müsste funktionieren (und das wurde auch hier bestätigt).

Das Hauptproblem hier ist, wenn sich zwei Adapter an das gleiche ECU (z.B. Hybrid-System-ECU) wenden, und das intensiv, unterschiedliche Daten fast gleichzeitig anfordern und dann haben Probleme die Antworten auseinander zu halten.

So ist der Fall bei mir - HA (normale Nutzung) und Torque, der alle möglichen Daten der Batterie abfragt - da muss es einfach zu Konflikten kommen.


Als etwas wie eine Lösung für meine Anwendung könnte eine Erweiterung der Funktionen vom HA sein.

HA hat die Funktion die Hybrid-Batterie auf Herz und Nieren zu checken, aber das nur im Stand und nach einer fest gelegten Prozedur. Das ist natürlich klasse, aber das macht man eben nicht so oft. Und diese Prozedur treibt den Verbrauch etwas nach oben

Wenn HA z.B. bei jeder zehnten regenerativen Bremsung (hoher Ladestrom) und bei jedem zehnten hohem von der Batterie abgegebenen Strom den Spannungsunterschied zwischen der schwächsten und stärksten Zelle in der Batterie checken würde, könnte man sehr früh erkennen, wenn sich in der Batterie etwas verschlechtern sollte.

Aber das ist schon ein Thema für eine ganz andere Diskussion - die einzige Frage hier - weiß jemand, wie man solche Vorschläge den HA-Entwicklern mitteilt und evtl. diskutiert?

Grüße

Mat

Und jetzt noch einmal ganz zum Schluss.

Ich komme zu der Überzeugung, dass HybridAssistant doch mehr kann, als ich ihm zugetraut habe.

Meine Idee vom ersten Post war:
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.

Es stellt sich heraus, dass ich gar nicht zwei OBD-Adapter brauche!
HA kann genau das machen, was ich wollte!

Wenn man HA startet, verbindet, Battery Check startet und ganz normal losfährt, wird zwar nur die Battery-Check-Oberfläche gezeigt, aber im Hintergrund wird doch alles andere wie gewohnt geloggt!

Man braucht, vermute ich, einen schnellen Adapter, aber sonst bekommt man alle Fahrtdaten PLUS die Hybrid-Baterie Daten wie auf silbernem Tablett serviert!

Die Batteriedaten sind wohl nicht so aussagekräftig, wie wenn man sie so, wie es in der Dokumentation beschrieben ist, sammelt, aber es wäre auch mit zwei OBD-Adaptern nicht besser gewesen.

Anscheinend habe ich mich zu sehr nach der Dokumentation gerichtet, und dachte, während des Batterie Checks würden nur die Batteriedaten geloggt... Es wird alles geloggt PLUS die Batteriedaten.

Euch allen und Euren Familien ein glückliches neues Jahr und einen guten Rutsch!

Mat