Motorola 2700 International Internas gesucht

[Guido W. (engiadina)]

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

[Rüdiger B. (rbruns)]

Das Teil hat bis zu 8 Watt Ausgangsleistung, auf meinem abgelegenem 
Campingplatz bin ich der einzige mit Handyempfang. Also behalten.

[Guido W. (engiadina)]

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.

[Andreas M. (elektronenbremser)]

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.
?

[Rüdiger B. (rbruns)]

Das liegt am GSM Protokoll, es wird die Leistungsangabe mitgesendet und 
die Basisstation erhöht daraufhin die Leistung.

[Lotta . (mercedes)]

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

[Guido W. (engiadina)]

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?

[Stefan (stfallet)]

@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

[Guido W. (engiadina)]

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.

[Guido W. (engiadina)]

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.

[Soul E. (soul_eye)]

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.

[Stefan (stfallet)]

@Guido.

bist Du weitergekommen? Würde mich freuen zu erfahren wie Du 
zurechtkommst.

Danke

Stefan

[Alexander (alecxs)]

Hast Du es mal über Fahrzeug Dokumentation versucht?

[Guido W. (engiadina)]

@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

[Alexander (alecxs)]

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.