Proprietärer 2-Draht-Bus, Botschaften manipulieren/ändern

Proprietärer 2-Draht-Bus, Botschaften manipulieren/ändern (13 Beiträge, 617 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Ich habe 5 Geräte an einem offensichtlich proprietären 2-Draht-Bus.

Die für mich relevanten Botschaften/Telegramme habe ich bereits entschlüsselt.

Ich möchte zumindest eine der Botschaften von einem der Geräte abhängig von ihrem Inhalt verändern, d.h. die "richtige" Botschaft entfallen lassen und durch eine veränderte Botschaft ersetzen.
(Konkret, aber vereinfacht: Wenn 1 von 3 bestimmten Bits gesetzt ist, möchte ich abhängig von der Uhrzeit zusätzlich ein weiteres der beiden nicht gesetzten Bits setzen.)

Ich habe mir überlegt, die Busleitung aufzutrennen und ein selbst programmiertes Gateway dazwischenzuhängen. Das Gateway kopiert die Botschaften der 4 unveränderten Geräte auf den anderen Bus bzw. es liest die Botschaften von dem 1 Gerät, dessen Inhalt ich manchmal verändern will, ein und schreibt die veränderten Botschaften auf den Bus der 4 unveränderten Geräte.

Hier noch einige Infos, die ich über die Geräte/Botschaften habe und für relevant erachte:

Alle 5 Geräte senden permanent in immer der gleichen Reihenfolge am Bus eine "Standard"-Botschaft (enthält als Daten vmtl. irgendeine Seriennummer/Typ o.ä.). Danach kommt noch irgendeine weitere "Abschluss-Botschaft". Wer die sendet weiss ich nicht.
Wenn ein Gerät Daten übertragen will, sendet es anstatt der "Standard"-Botschaft seine "Daten"-Botschaft. Diese "Daten"-Botschaft wird nur 1x versendet, wenn sich der Inhalt ggü. der zuletzt gesendeten "Daten"-Botschaft ändert.
Beim Hochfahren des Bus findet offenbar irgendeine Initialisierung statt, bei der die IDs der Geräte (in meinem Fall 0x00-0x04 bzw. 0xF0 für den Abschluss) vergeben werden. Dabei scheint es keine Priorität zu geben, die IDs scheinen "zufällig". Wird ein Gerät abgeklemmt und wieder angeklemmt, hat es u.U. eine andere ID als vorher. Trotzdem funktioniert der Gesamtverbund problemlos.

Wie gehe ich das am Besten an?

Mein Hauptproblem scheint das richtige Timing zu sein. Wie schaffe ich es, immer die gleiche Reihenfolge einzuhalten?

Bisher habe ich nur mit HTerm "mitgelauscht" und dann die Botschaften entschlüsselt.
Ein Sendeversucht mit HTerm hat keine Reaktion verursacht, sie ist nichtmal bei den "gesendeten Botschaften" aufgeschienen.

BMW 320d E90:

Yamaha FZ6-S Fazer:

Erste Frage wär wohl ob's wirklich sicher ein proprietärer Bus ist, ich mein wozu erfinden wenn's I2C gibt?

Botschaften manipulieren ist bei sowas nicht sonderlich einfach, wäre das Ersetzen des Gerätes eine Option?

________________________________________________________________________

There's a typo in the Bible. It should read "The geek shall inherit the earth".

schließe mich dem Vorposter an - bin ja auch kein Crack in der Richtung, aber Gretchenfrage ist, welche Bussysteme du kennst/identifizieren kannst, sodaß du sie ausschließen konntest bzw. hast du auch nachgesehen, ob da bekannte Chips verbaut sind, die Hinweise auf das benutzte Protokoll geben?
Wie bist du hardwaremässig drangegangen? Oszi/Logic-Analyzer?

Du schreibst, du sniffst mit hterm mit = doch was serielles? Ausgekreuzt oder wirklich Bus? Keine erkennbare bus-contention?
Was für Pegel, ungefähre Taktraten, synchron/asynchron, Datagramformate, Sync-Infos erkennbar?

Daß tatsächlich noch Hersteller was eigenes basteln scheint mir doch sehr unwahrscheinlich?!? Falls das Protokoll direkt von Controllern (Atmega8 oder so) implementiert ist, kann man die Firmware eventuell auslesen und so Hinweise bekommen?

Hm... glaube nicht, dass das I2C ist.

Was da permanent daherkommt, sieht so aus:

55 00 04 00 0E 01 ED 00
55 01 04 00 09 01 F2 00
55 02 03 00 0B F2 00
55 03 03 00 0C F1 00
55 04 04 00 08 01 F3 00
55 F0 00

Meine Vermutungen:
1. Byte: Die 55 ist wohl zum PLL-Synchronisieren.
2. Byte: 01-04 sind die Adressen der einzelnen Geräte.
Das 3. Byte gibt an, wieviele Bytes dann noch kommen.
Dann kommen die Daten.
Das vorletzte Byte ist immer der "Rest" auf 0x100 der vorherigen Bytes ab dem 3. Byte.
Das letzte Byte ist immer 00.

BMW 320d E90:

Yamaha FZ6-S Fazer:

welche Bussysteme du kennst/identifizieren kannst, sodaß du sie ausschließen
konntest

MODBus habe ich anfangs vermutet, ist es aber nicht.

Generell kann ich anhand der Botschafte keine "Master/Slave"-Vorgänge identifizieren, d.h. es sieht erstmal so aus als ob einfach alle Geräte ihre Botschaften auf den Bus legen und sich jeder "nimmt was er braucht".

Ich habe mit einem "Behelfs-Oszi" die Bitabstände ermittelt und daraus die Baudrate (4800) errechnet.
Prinzipiell bin ich der Meinung, dass das, was ich sehe, schon "richtig" ist, siehe dazu insbesondere die Antwort, die ich Deinem Vorposter gegeben habe, insbesondere was die immer gleiche "Summe 0x100" betrifft.

HTerm wurde mir von jemandem empfohlen. Wenn Du was besseres kennst, das für Bus besser geeignet ist, dann nur her damit.
Da alle Geräte an denselben 2 Leitungen hängen und ich nix ausgekreuzt habe, ist das sicher nix serielles.
Möglicherweise sendet HTerm einfach auf der falschen Leitung und deshalb passiert nix???

Die Geräte gibt es schon sehr lange...
Eines davon habe ich aufgeschraubt, da ist ein TI MSP430F5418 drin.

BMW 320d E90:

Yamaha FZ6-S Fazer:

Moment, was heißt daherkommt, nach welchem Protokoll bitte? Du bist hier mindestens einen OSI-Layer höher als ich.

________________________________________________________________________

There's a typo in the Bible. It should read "The geek shall inherit the earth".

bin kein Elektroniker + beschäftige mich nur am Rande mit damit, insofern mein vielleicht punktuell naiver Zugang:

TI MSP430 ... mal geschaut, was dort an Referenzbibliotheken dabei ist und welche Features die für den Bus benutzten Pins unterstützen?

HTerm wurde mir von jemandem empfohlen.

wird schon das passende Tool für den Zweck sein, aber meine Frage ist: mit welchem Interface greifst du das Signal ab?!? FTDI-Seriell-TTL-Adapter?

Meine Überlegung geht dahin, daß möglicherweise für die Synchronisation oder die Bus-Verwaltung spezielle Spannungen aufmoduliert werden die dann mit "Diodenkontruktionen" wieder rausgefiltert werden?
Kurz: ich würd mich mal von Seite des MSP430 her einlesen, was dort so serienmässig üblich und möglich ist. Ev. gibt es dort sogar Debugging-Tools, die genau damit umgehen können?

PS: je mehr ich drüber nachdenke: wenn du mit hterm + einem Serielladapter versuchst, was zu injizieren, dann geht der natürlich davon aus, daß es sich um eine ausgekreuzte Leitung handelt, kann also beim Besten Willen nicht "bus-konform" senden ?????
Entweder du brauchst eine Schaltung, die dir Tx auf die Empfangsleitung/Rx überträgt (wie es AFAIR das Jeti-Protokoll macht?) oder überhaupt was mit bidirektionalem Bitbanging? Ist auf den Geräteplatinen eine Dioden-Schaltung erkennbar, die die Bus-Pins wieder diskriminieren/"splitten"?

07.02.2017, 18:19 Uhr - Editiert von user86060, alte Version: hier

Da hast Du wohl Recht.

Die Spannung zwischen den beiden Leitungen ist immer ~5V oder ~0V.
Daraus habe ich einfach mal eine Baudrate errechnet, die Leitungen an einem ausgeborgten RS-485-auf-USB-Adapter angeschlossen und geschaut, was in HTerm so daherkommt.

Aus der Hexadezimal-Darstellung habe ich dann versucht einen Sinn abzuleiten.
Bisher stimmt meine Interpretation der Daten auch, habe noch keine Botschaft gefunden, wo es nicht passt.

Welches Protokoll zugrunde liegt, habe ich noch nicht herausgefunden.

BMW 320d E90:

Yamaha FZ6-S Fazer:

TI MSP430 ... mal geschaut, was dort an Referenzbibliotheken dabei ist und
welche Features die für den Bus benutzten Pins unterstützen?

Steht noch aus. Die Spezifikation habe ich schon offen, aber noch nicht im Detail reingeschaut.

mit welchem Interface greifst du das Signal ab?!? FTDI-Seriell-TTL-Adapter?

Ausgeborgter RS485-auf-USB-Adapter. In dem Zuge wurde mir auch HTerm empfohlen.
Prinzipiell ist mir egal welche Hardware dafür nötig ist. Wenn ich sicher bin was ich brauche, besorge ich das.

PS: je mehr ich drüber nachdenke: wenn du mit hterm + einem Serielladapter
versuchst, was zu injizieren, dann geht der natürlich davon aus, daß es sich
um eine ausgekreuzte Leitung handelt, kann also beim Besten Willen nicht
"bus-konform" senden ?????

Siehe oben...
Den Gedanken hatte ich natürlich auch schon. Mal angenommen der Adapter ist soweit tauglich, welche Software brauche ich?

Ist auf den Geräteplatinen eine Dioden-Schaltung erkennbar

Nein, habe ich bisher nicht entdeckt.

BMW 320d E90:

Yamaha FZ6-S Fazer:

Ausgeborgter RS485-auf-USB-Adapter. In dem Zuge wurde mir auch HTerm
empfohlen.

wer ist auf diese Idee gekommen? RS485/RS422 sind differentielle/symmetrische Schnittstellen, AFAIK brauchen die sogar 4 Drähte - sowas können die meisten Controller inkl. dem MSP430 ohne extra Treiberchips gar nicht ausspucken. (Was aber nicht ausschließt, daß deren Protokoll "unbalanced" mißbraucht wird, so wie man das notfalls auch mit XLR-Audio tun kann.)

Daß der Adapter da tatsächlich was zuverlässig zu decodieren scheint, ist natürlich eine vielversprechende Beobachtung, aber IMHO noch nicht die Lösung. Mit welchen Baudraten und hast du in hterm den experimentiert?

Erst einmal würd ich - sofern nicht ohnehin eine Internetrecherche, zu den fraglichen Geräten was ergibt - ausmessen, wie die beiden Drähte tatsächlich beschalten sind = handelt es sich um Masse + Bussignal / "1-wire"-verwandtes-Protokoll (brauchen trotzdem eine Masse, aber ohne die Phantomspannung)? Mit welchen Pegeln arbeitet das Drahtpaar?

Kurz: Ich seh da einen Fall für einen Logic Analyzer, mit dem man die Kandidaten, die punkto Verdrahtung und Spannungspegel ins Bild passen durchprobieren kann. Ich glaube, daß du ein Detail auf der elektrischen Seite übersehen hast, das dein Adapter nicht mitbekommt.

Nach wie vor würde es mich wundern, wenn da angesichts der inzwischen üblichen bereits von den Controllern mitgelieferten Protokolle was eigenes erfunden worden wäre.

Aber wie gesagt ... bin kein Elektronik-Crack, nur ein paar Beobachtungen, Erfahrungswerte und was man sich so anliest.

RS485/RS422 sind differentielle/symmetrische Schnittstellen, AFAIK brauchen
die sogar 4 Drähte - sowas können die meisten Controller inkl. dem MSP430 ohne
extra Treiberchips gar nicht ausspucken.

Jein. RS485 braucht nur 2 Drähte für halbduplex.

Mit welchen Baudraten und hast du in hterm den experimentiert?

Alle durch, 4800 scheint die richtige Einstellung zu sein & hat sich wie gesagt auch rechnerisch ergeben, nachdem ich die Leitungen an einem "Behelfs-Oszi" angeschaut habe.

Internetrecherche

Fehlanzeige. Gibt ein paar Leute, die auch schon danach gefragt haben, aber verfolgt bzw. eine Lösung scheint niemand zu haben.
Anfrage beim Hersteller nach Offenlegung des Protokolls wurde leider auch abgelehnt.

Mit welchen Pegeln arbeitet das Drahtpaar?

Zwischen den Drähten liegt ~5V oder +0V an. Bisher habe ich aber wie gesagt kein richtiges Oszi zur Hand, um das zuverlässig anzuschauen.

Ich glaube, daß du ein Detail auf der elektrischen Seite übersehen hast, das
dein Adapter nicht mitbekommt.

Das will ich nicht ausschliessen.
Umgekehrt, warum sehen meine entschlüsselten Botschaften dann so plausibel und sinnvoll aus?
Habe gestern Abend noch ein bisschen weiter analysiert & mittlerweile die Botschaften von 2 Geräten vollständig entschlüsselt.

Nach wie vor würde es mich wundern, wenn da angesichts der inzwischen üblichen
bereits von den Controllern mitgelieferten Protokolle was eigenes erfunden
worden wäre.

Ich habe nur eines der 5 Geräte geöffnet; dort ist eben der genannte Chip im Einsatz. Die anderen 4 sind aber von der Funktionalität sehr viel einfacher, möglicherweise ist dort was anderes drin. Diese Teile sind aber auf einer Hutschiene montiert und mittels Schraubklemmen verdrahtet. Scheue mich davor, da was auszubauen und auch noch aufzumachen.

Habe gestern Abend dann auch noch im Datenblatt nachgeschaut, welche Leitungen von dem genannten TI-Chip relevant sind. Bin dann aber nicht weitergekommen, jetzt habe ich die relevanten Seiten ausgedruckt und werde genauer draufschauen. Am Bildschirm bin ich vor lauter Scrollen durcheinander gekommen.

Aber wie gesagt ... bin kein Elektronik-Crack, nur ein paar Beobachtungen,
Erfahrungswerte und was man sich so
anliest.

Bin für jeden Tipp dankbar.

BMW 320d E90:

Yamaha FZ6-S Fazer:

Jein. RS485 braucht nur 2 Drähte für halbduplex.

hm - tatsächlich.
Faszinierende Situation: RS485 hat "praktisch" tatsächlich verschiedene Eigenschaften, die sich mit deinem Problem decken, gleichzeitig wäre es im Grunde aber nur die elektrische Spezifikation, aber genau die stimmt eigentlich nicht mit dem Szenario überein = selbst wenn dein Adapter das Signal korrekt mitlesen kann - woher "weiß" er, wie er es punkto Spannung senden muß?

Die Sende-/Empfangs-Diskriminierung ist dort auch nicht über Dioden gelöst (sondern http://www.roboternetz.de/bilder/rs485-2leiter.jpg OpAmp - wobei ich aber nicht weiß, ob diese Methode mit TTL-Pegeln in beide Richtungen = also eben auch beim Senden funktioniert, also einen kompatiblen Pegel ergibt, und nicht RS485-differentielle Spannungen (gibt Platinchen, die RS232 über eine externe Referenzspannung auf beliebige Pegel bringen, (also umgekehrt zu 1488/1489 bzw. MAX232), aber deren Schaltung wird sich mit halbduplex auch nicht vertragen).

bleibt mir nur etwas Brainstorming:

Ich glaube, daß du ein Detail auf der elektrischen Seite übersehen hast, das
dein Adapter nicht mitbekommt.

Das will ich nicht ausschliessen.
Umgekehrt, warum sehen meine entschlüsselten Botschaften dann so plausibel und
sinnvoll aus?

genau das: im lesenden Zustand kommt dein Interface grad noch mit mit den elektrischen Gegebenheiten, aber wenn es mit derselben Methode rausschreibt, stimmen möglicherweise die Spannungen nicht? Insofern hast du noch Glück, das du bisher nicht den ganzen Bus geschossen hast ?!?
Auf Seite der MSP430 (ich gehe mal davon aus, daß in allen Geräte ein Ableger davon drin ist - wäre widersinnig, da parallel für verschiedene Controllerfamilien zu entwickeln, wenn EINE idR genügend Varianten zur Auswahl hat) müssen die Pins irgendwie mit dem Halbduplex/Senden-Empfangen klarkommen, falls da wirklich keinerlei Schaltung wie oben verlinkt, am Werk ist = entweder die Pins kennen eine Art Tri-state oder sie müssen über softwaremässiges Timing/Synchronisation zw. input und output umschalten. 4800 ist für die heutigen CPU-Taktraten keine Herausforderung bzw. die meiste Zeit wird wohl gehorcht.
Eventuell kennt der Chip aber auch einen Modus, wo das Pin einen Interrupt losschickt.

Was bleibt jetzt an Möglichkeiten und Schritten?
Herausfinden, wie die Geräte halbduplex pinseitig lösen bzw. was sich vom MSP430 her anbietet

Interface nachbilden ... idealerweise indem man genau so einen hernimmt: http://www.digikey.de/product-detail/de/dlp-design-inc/DLP-2232MSPF/813-1034-ND/2781070 könnte hinkommen. Mit etwas Glück findet sich dann noch Beispielcode, der Schnittstellenübersetzung zw. eigenen Protokollen und dem FTDI spielt.

oder: sich den Spaß antun und direkt mit dem FTDI-Bitbanging-Mode auf einem üblichen FT2232/FT245-Adapter herumspielen? Leider hab ich bis dato nichts gefunden, was da einen schönen Zugang liefert. Unter Linux könnten die one-wire-Pakete helfen (ow*), muß ich mir aber auch erst reinziehen.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung