Hallo, ich bin im Besitz von ein paar dieser Autotelefone. Das alles funktioniert zwar noch, ich würde aber gerne eine eigene "Kiste" bauen, mit der ich den Hörer betreiben kann, die "Kiste" dann aber per Bluetooth ein normales Mobiltelefon ansteuert und betreibt. Den Bluetooth-Teil habe ich im Wesentlichen im Griff, allein mir fehlt die Kenntnis des Hörers. Ich habe zwar die Leitungen des Anschlussteckers schon identifiziert, ein- und ausschalten geht auch schon. Es gibt aber zwei Datenleitungen, auf denen Datenverkehr zu sehen ist. Dabei findet man einen permanenten Datenstrom, der mit einem eindeutigen Puls von 4µs einen Blockmarker hat, danach kommt ein Startbit und 64 weitere Bits in Manchester-Codierung. Soweit klar, lässt sich auch im Scope gut sehen. Was ich überhaupt nicht weiss, wie ich diese Daten interpretieren soll. Ich bin schon soweit, dass der kurze Puls eine 0 darstellt, der lange eine 1. Ich habe auch eine Lochrasterplatine gehäkelt, mit der ich beide Datenströme mitlesen kann und als serielle Ausgabe auf den PC bekomme. Ich werde trotzdem nicht schlau aus den Ganzen. Vor allem die schiere Datenmenge machts nicht einfacher. Es läuft ein permanenter Datenstrom, auch wenn auf dem Hörer nichts passiert und die Basis-Unit sich langweilt. Wenn der dann wenigstens immer gleich wäre, könnte man ja nach IDLE-Paketen filtern, aber auch das ist nicht so. Meine Frage daher: Hat jemand mehr Informationen über das Datenprotokoll der Motorola 2700 Geräte und kann mir da ein paar Tips geben? Intensive Suche im Netz hat nichts gebracht, leider. Drum hoffe ich, dass hier jemand was weiss. Schon einmal Danke im Voraus und viele Grüsse engiadina
Angehängte Dateien:
-
tek00001.png
90 KB
Das Teil hat bis zu 8 Watt Ausgangsleistung, auf meinem abgelegenem Campingplatz bin ich der einzige mit Handyempfang. Also behalten.
Naja, hab ich ja vor. Man kann aber den Hörer abstecken (RJ45) und woanders dranstecken - eben an meine zu bauende "Kiste". Dass man über den Datenbus einiges machen kann, weiss ich aus alten BMW-Zeiten. Da war das 2700 (getarnt als BMW Telefon) sehr gut integriert in die Fahrzeugelektronik, das Auto konnte sogar die Telefonbucheinträge auslesen und einen Kartenleser unterm Handyhalter gabs auch.
Rüdiger B. schrieb: > 8 Watt Ausgangsleistung Rüdiger B. schrieb: > bin ich der einzige mit Handyempfang. Du widersprichst dir. Erst schreibst du "Ausgangs"leistung, also senden, dann schreibst du Handy"empfang" also das Gegenteil von senden. ?
Das liegt am GSM Protokoll, es wird die Leistungsangabe mitgesendet und die Basisstation erhöht daraufhin die Leistung.
Guido W. schrieb: > Hallo, > > Meine Frage daher: > Hat jemand mehr Informationen über das Datenprotokoll der Motorola 2700 > Geräte und kann mir da ein paar Tips geben? Intensive Suche im Netz hat > nichts gebracht, leider. Drum hoffe ich, dass hier jemand was weiss. > > Schon einmal Danke im Voraus und viele Grüsse > engiadina Nokia hat bei seinen Autotelefonen zu der Zeit zwischen Grundgerät und Hörer das Protokoll HDLC, also High Level Data control, in der Sicherungsschicht verwendet, vielleicht war das auch bei Motorola so? Hast Du noch nen DOS Rechner oder ne DOS VM zur Verfügung? mfg
:
Bearbeitet durch User
Ja hätte ich. Hab aber auch einen Microcontroller / Arduino, der mir die Daten in Echtzeit auf der seriellen Schnittstelle ausgibt. Was hast Du vor?
@Guido, das finde ich extrem spannend. Falls Du weiterkommst, würde mich das auch interessieren. Bin am überlegen was ähnliche zu machen allerdings mit einem Siemens P1. Danke, Stefan
Angehängte Dateien:
-
IMG_4974.jpg
240 KB
Ein paar neue Infos habe ich in der Zwischenzeit: Ich vermute, der Hörer hat keine eigene Intelligenz im Sinne eines µP. Das ist eher ein GA oder was ähnliches, das durch den Datenstrom von der BaseUnit gesteuert wird. Mit zu der Erkenntnis beigetragen hat der MC145503 auf dem Board vom Hörer. Das ist ein PCM-fähiger Wandler für Sprache und kann seriell angesteuert werden. Zunächst ist der Datenstrom zu sehen. Der läuft permanent in beide Richtungen und liefert alle 125 µs 60 Bits. Darüber kann ich ein wunderbares Taktsignal erzeugen, da ich alle 2µs einen Takt habe. Der Datenstrom vom Hörer zur ControlUnit hat normalerweise ein Idle-Paket (0x7FF8000000000000). Bei Tastendrücken sind eindeutige Make- und Brake Codes zu erkennen. Ein Tastendruck beginnt immer mit 0x7EA7FFE In den nächsten vier Bytes ist die Taste codiert, für die Taste 1 zum Beispiel 0x7EA7FFE 7E7E7EBE0 Wird die Sprache aktiviert, gibts ganz viele Datenpakete, die nicht Idle sind, sieht also so aus, dass da PCM-Daten transportiert werdem. Beobachtet man den Datenstrom von der ControlUnit zu Hörer ist ein klares Muster zu erkennen. Das erste Byte wechselt nach einem Muster (hab ich noch nicht ganz geknackt), das zweite Byte ist immer F8. Danach kommen diverse 0 Bytes. Beispiel 0x91F80000000000 Ich vermute nun, dass über das erste Byte verschiedene Ausgänge des GA aktiviert werden. Da das Byte ständig wechselt, könnte man darüber auch einen Scan der Tastenmatrix erzeugen. Muss mal sehen, welche Daten von der ControlUnit kommen, wenn ein Tastendruck übertragen wird. Vielleicht sieht man dann eine Zuordnung. Mit diesem Prinzip kann man auch die PCM-Sprachübertragung realisieren, die PCM-Daten haben dann einfach einen spezifischen Präfix und werden in den PCM-Chip getaktet. Interessant ist auch, wenn man einen BMW-Hörer an die ControlUnit vom 2700 steckt. Funktioniert leidlich, lediglich ein paar Tasten haben eine andere Bedeutung. Spannend ist dabei dass die Tastencodes unterschiedlich sind. Der BMW-Hörer produziert den Tastencode 0x7EA7FFE7FFFFF3F0 für die Taste 1. Präfix passt, nur die Codierung ist völlig anders. Die ControlUnit frisst aber auch diesen Code - warum auch immer. Gibt also noch einiges zu tun, aber schon ein paar Erkenntnisse.
Angehängte Dateien:
-
IMG_4975.jpg
240 KB
Weiss jemand was über den verwendeten Baustein? Der findet sich sowohl im Hörer als auch in der ControlUnit wieder. Unter SCV38138CB05 findet man das Ding zwar bei diversen Bauteilschüttlern aber kein Datenblatt. Zweite Frage, hat jemand eine Idee, was der LCD-Controller für ein Typ sein Könnte? Das Display ist 2x12 mit 5x7 Zeichen und ein paar Symbolen ausgestattet. Bin für jeden Tip dankbar.
Guido W. schrieb: > Unter SCV38138CB05 findet man das Ding zwar bei diversen > Bauteilschüttlern aber kein Datenblatt. "SC" steht für kundenspezifisch, die Zahl hinter dem "V" bezeichnet die ROM-Maske. Um welchen Controllertyp es sich handelt kann man mit etwas Glück an der Position der Takt- und Versorgungsanschlüsse erkennen.
@Guido. bist Du weitergekommen? Würde mich freuen zu erfahren wie Du zurechtkommst. Danke Stefan
Hast Du es mal über Fahrzeug Dokumentation versucht?
Angehängte Dateien:
-
IMG_4991.jpg
240 KB -
IMG_5002.jpg
240 KB
@Stefan Ja ein wenig schon, hatte aber viel zu tun und musste mich um andere Dinge kümmern. Das erste wechselnde Byte hat mich beschäftigt. Das ist nicht zufällig aber auch kein eindeutiges Muster. Es gibt zwar Bytes die häufiger auftreten, aber eindeutig ist das alles nicht. Dann habe ich am Grafikcontroller gelauscht und mal geschaut, was da passiert und ob man die Zeichen sehen kann, die so auf dem Display erscheinen. Das hat gut funktioniert, tatsächlich ist der Controller wohl ein HD44780 Derivat. So konnte ich dann die Controllerbefehle den Datensätzen zuordnen. Es gibt zwei Befehlsgruppen, 0xE7 als Header - steuert die RS-Leitung des Displays und 0x67 als Header, Datenbyte an Display (wird in zwei Nibbles ans Display übertragen, Aufspaltung macht der Controller im Hörer). Ach ja, Idle-Pakete haben den Header 0xF8 Soweit gut, mit der entsprechenden Decodierung kann ich auch die Befehle ans Display aus den Steuerbefehlen rauslesen. Wo ich gerade hänge, ist die gesamte Codierung und das erste Byte des Datenwortes. Das zweite ist eindeutig der Header. Da das erste Byte eben kein wiederholbares Muster hat, schwankt die Theorie der Abfrage mit dem ersten Byte etwas. Im Moment rechne ich auf dem Thema Hamming-Code herum. Die Daten sind interleaved, soweit lässt sich das bei den Displaydaten nachvollziehen. Wenn ich da einen Hamming 12/8 ansetze, bekomme ich auch meine Daten. Es aber nicht sehr sinnvoll, 60 oder 62 Bits zu schicken, und nur die letzen Bytes zu sichern oder das alles in Dreiergruppen zu sichern. Bei 60 Bytes hätte ich fünf Dreiergruppen, ergibt aber auch nicht sehr viel Sinn. Ich versuche gerade noch zwei weitere Bits im Datenstrom zu isolieren um dann einen Hamming 62/56 zu bekommen und den dann sinnvoll zu decodieren. Da bin ich gerade dabei, hier ist es zu heiss und der Job verlangt gerade meine volle Aufmerksamkeit. Ich sage Bescheid, wenn ich was Neues weiss. Wenn jemand echt fit mit diesen Dingen sein sollte - Unterstützung ist immer willkommen. @Alexander Was genau meinst Du mit Fahrzeugdokumentation? Viele Grüsse
Für MB gibt es das WIS da kann man sich alle möglichen Dokumente anschauen, bis hin zu CAN Frames. Mit BMW kennst Du Dich besser aus.
Angehängte Dateien:
-
IMG_5024.jpg
390 KB
Kleine Zwischeninfo: Ich habe das BMW-Interface ausgegraben, das damals die Verbindung zwischen I-Bus und Motorola Bus hergestellt hat. Der Philips ist ein klasischer UART, dessen Datenleitungen an den 68000 gehen. Die Rx und Tx Leitungen gehen zum Elmos 10020B, DER Transceiver für den BMW I-Bus. Interessant ist aber wieder mal der SCV38138CB05, den findet man ja auch im Hörer und in der Base-Unit. Das Tierchen ist damit der heisseste Kandidat für die Codierung und Decodierung der Daten auf dem Motorola-Bus. Ich muss mal sehen, wie man dem Ding am besten auf den Leib rückt ...
Und noch ein Info-Fetzen. Der SCV38138CB05 trägt ja noch die Kennung 43E07. Unter dieser Kennung kommt man weiter, das ist der "berühmte" Bus Interface Controller (BIC) der den Motorola DSC-Bus bedient. Wem der Begriff EMMIBox etwas sagt, dieses Gerät war zum Freischalten und Modden der Telefone notwendig und arbeitet über den besagten Bus. Alle bekannten Implementierungen benötigen den 43E08 (oder 43E07). Dass jemand diesen Chip in Software ersetzt hat, ist nicht zu finden. Das das geht, sieht man zum Beispiel am Motorola V.3688, dass auch den DSC-Bus hat aber diesen per Software abbildet. Ziemlich frustrierend alles. Hat denn jemand hier wenigstens einen Schaltplan einer EMMIBox oder weitere Informationen zum DSC-Protokoll oder zum Chip? Dass das Ding bis jetzt noch keiner reengineert hat, ist nicht gerade ermutigend.
Um den DSC-Bus mitzuschneiden eignet sich jeder einfache Logicanalyzer, so schnell ist der Bus ja nicht und das dann mit einem Mikrocontroller nachzubilden sollte auch nicht so schwer sein. Hier gibt es einen Schaltplan für ein DSC-Bus Interface: http://motpages.50webs.org/hardware.html Die Datei mit dem Schaltplan ist die hier: http://motpages.50webs.org/download/dscpcx.zip
Dieter S. schrieb: > und das dann mit einem Mikrocontroller nachzubilden sollte auch nicht so > schwer sein. hier gehts nicht um die Hardware
Dieter S. schrieb: >Um den DSC-Bus mitzuschneiden eignet sich jeder einfache Logicanalyzer Ja, dafür hab ich das einfache Interface mit einem Arduino gehäkelt. Zwei Komparatoren, ein paar Kondensatoren und das war fertig. Bus-Mitschnitte habe ich ausreichend. >und das dann mit einem Mikrocontroller >nachzubilden sollte auch nicht so schwer sein. Naja, bei der Codierung hänge ich. Die Daten werden in einer Art Manchester-Code übertragen und mit einem ständig wechselnden Header vorangestellt, selbst bei Idle-Blöcken. An der Stelle könnte ich echt Unterstzützung brauchen.
:
Bearbeitet durch User
Alexander schrieb: > > hier gehts nicht um die Hardware Die von mit verlinkte Seite enthält ausreichend Informationen zum DSC-Bus, damit kann man das Protokoll und die Kommunikation analysieren. Der DSC-Bus ist wohl mindestens 25 Jahre alt, die Nachbildung in Software machbar.
Ich kenne die Seite sehr gut, dennoch danke für den Tipp. Die erwähnte Datei für das Bus-Interface kann ich nicht öffnen, brauch ich aber auch nicht (s.o.) Hast Du mehr Informationen über das DSC-Busprotokoll?
Guido W. schrieb: > > Naja, bei der Codierung hänge ich. Die oben verlinkte Seite enthält ein paar Informationen zum DSC Bus. Die PCM Audio Daten auf dem Bus sollte man erkennen können, insbesondere wenn man Testtöne aufzeichnet.
Was ich gemacht habe, war die Display-Befehle mitzuschreiben und diese in den Paketen wiederzufinden. Das habe ich zwar hinbekommen, die Daten sind aber dermassen schräg codiert, dass ich mit PCM erst gar nicht anfange. Aus 15 Bit werden 8 Bit extrahiert und diese dann als Displaydaten generiert. Was nicht klar ist, wie der Header entsteht. Jedes Paket hat einen Header mit einem Byte, dann kommt ein Identifier, zum Beispiel 0x67 für Displaydaten. Hier sind ein paar Beispiele mit decodierten Daten: DE67FFFFFFFFFFF0 0x00 DE67FFFFFFFFB790 0x47 C667FFFFFFFFD7F0 0x03 DE67FFFFFFFF5F50 0xCC EE67FFFFFFFFFFF0 0x00 D267FFFFFFFF5FF0 0x0C F067FFFFFFFF5FF0 0x0C E467FFFFFFFFAF90 0x46 8E67FFFFFFFFFFF0 0x00 F667FFFFFFFFB790 0x47 8467FFFFFFFFE7F0 0x01 D867FFFFFFFF5F50 0xCC D867FFFFFFFFFFF0 0x00 C667FFFFFFFF5FF0 0x0C 8467FFFFFFFF5FF0 0x0C E867FFFFFFFFAF90 0x46 F067FFFFFFFFFFF0 0x00 E267FFFFFFFFB790 0x47 B267FFFFFFFFFFF0 0x00 F667FFFFFFFF5F50 0xCC B267FFFFFFFFFFF0 0x00 E267FFFFFFFF5FF0 0x0C E467FFFFFFFF5FF0 0x0C 8867FFFFFFFF6F90 0x4E F067FFFFFFFFFFF0 0x00 8267FFFFFFFF7790 0x4F E467FFFFFFFF3FF0 0x08 A667FFFFFFFF4750 0xCD EE67FFFFFFFFE7F0 0x01 B467FFFFFFFF5FF0 0x0C F067FFFFFFFF5FF0 0x0C EE67FFFFFFFFAF80 0x56 D467FFFFFFFFFFF0 0x00 EE67FFFFFFFFB780 0x57 D267FFFFFFFFFFE0 0x10 E267FFFFFFFF6F50 0xCE Das erste Byte ist das fragliche - was ist das?
Guido W. schrieb: > > Hast Du mehr Informationen über das DSC-Busprotokoll? Wenn ich in vergleichbaren Fällen nicht durch scharfes Hinsehen erkenne worum es geht hole ich mir die nötigen Informationen normalerweise aus der Firmware der entsprechenden Geräte wenn es sonst keine andere Informationsquelle gibt.
Guido W. schrieb: > > Das erste Byte ist das fragliche - was ist das? Ich würde zuerst versuchen dass ich bekannte Daten erkennen kann und auf dieser Basis dann den Rest analysieren. Bekannte Daten wären z.B. die PCM Audiodaten von Testtönen (z.B. Sinussignal oder die Code-Töne wenn man Tasten am Telefon drückt).
Dieter S. schrieb: > Wenn ich in vergleichbaren Fällen nicht durch scharfes Hinsehen erkenne > worum es geht hole ich mir die nötigen Informationen normalerweise aus > der Firmware der entsprechenden Geräte Naja, die Header-Bytes werden nicht in der Firmware erzeugt sondern im BIC. Da komme ich mit der Firmware nicht weiter. Der Hörer vom 2700 hat übrigens ausser dem BIC keine weitere Intelligenz, alles nötige muss da drin stecken.
Dieter S. schrieb: > PCM Audiodaten von Testtönen (z.B. Sinussignal oder die Code-Töne wenn > man Tasten am Telefon drückt). Beim Tastendrücken bleibt der Hörer stumm - keine Audiosignale. Der Ton kommt von der Control-Unit. Wie ich Testtöne in der Control-Unit erzeuge weiss ich nicht. Bestenfalls eine Nummer anrufen, auf der ein Ton abgespielt wird. Das krieg ich hin. Erst mal will ich aber die Codierung der Datenblöcke verstehen.
Angehängte Dateien:
-
DSC_IP_Primitives.PNG
140 KB
Die DSC IP Primitives aus der Doku des Motorola g18 GSM/GPRS Modul sind Dir bekannt? Eine Seite davon siehe Anhang, weitere Details stehen in der g18 Doku. Eventuell passt ja etwas davon auch bei Deinem Telefon.
Ja, passt leider nicht ganz. Das sind die uncodierten IP Primitives, die codierten wären es aber gewesen. Beispiel: Das Datenpaket 0x8867FFFFFFFF6F90 auf dem Bus hat den Header 0x88, die Codierung 0x67 und die Nutzdaten 0x6F9. Der Rest wird ignoriert. Aus den codierten Nutzdaten 0x6F9 errechnen sich die eigentlichen Nutzdaten 0x4E. Das wiederum sind Displaydaten, die in zwei Nibbles an den Displaycontroller übertragen werden: Also erstes Nibble 0x4 mit schönem E Clock, dann kommt Nibble 0xE auch mit E Clock. Macht alles der 43E07 ohne weiteres Zutun. Dass diese Daten so korrekt sind, weiss ich, da ich die Daten auf der Schnittstelle zum Display mitprotokolliert habe. Daher weiss ich was für Daten kommen müssen und die kann ich dann einem Datenpaket zuordnen. Wie gesagt, die letzten Bytes kann ich ja schon decodieren, die anderen Bytes sind noch schleierhaft für mich. Insbesondere das erste Byte 0x88 habe ich noch nicht. Das wechselt bei jedem Paket, manchmal ist ein Muster zu erkennen, es sind ca. 15 bis 20 unterschiedliche Bytes, die sich dann wiederholen. Ich habe mal ein paar mitprotokollierte Headerbytes als Textdatei angehängt. Zufällig sind die sicher nicht, ob die zur Manchester-Codierung beitragen weiss ich noch nicht. Bis jetzt habe ich noch keine Decodierung gefunden, die mir bei der Decodierung des gesamten Datenpakets einen sauberen Identifier liefert und die bekannten Nutzdaten enthält.
Du könntest mit einem Logicanalyzer die Signale am Interface Chip (BIC) mitschneiden. So viel macht das Teil nicht, damit sollte man genau sehen wie die Daten auf der Seite des Mikrocontrollers und auf dem DSC Bus aussehen. Und für die Details der Daten des Mikrocontrollers gibt es die Firmware.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.