Beiträge von Abi99

    Als Stack kommt nach obigen Link "BlueSpace Version 2.2" mit. Sagt mir nix, nehme eh den Apple Mac OS X stack.


    Ja Design ist Geschmacksache, aber das Teil ist der Kleinste, den ich kenne und farblich passt er irgendwie am Besten zu Apple Rechnern - gerade zu den weissen iBook/iMac Gehäusen.


    Ein paar Bilder...

    Das war wohl von einem geschrieben worden, der immer noch glaubt SIM-Lock sei ein Feature...


    Sowohl meine Hong Kong GSM SIMs als auch die Singapur SIMs gehen hier in allen meinen Geräten. Ach ja die Teile sind komplett standardisiert. Es kann aber sein, dass gewisse Modelle nicht mit den neusten Größen (64kb) und den niedrigen Volt Zahlen (3V) kennen und entsprechend Probleme machen...bei Nokia kennen wir ja solche Geschichten.

    Re: mit GSM Remote Adressen ausgetauscht


    Zitat

    Original geschrieben von MacMJ
    Weiß jemand da vielleicht noch Rat?

    Was hast Du bei meiner Erklärung nicht verstanden. Ich weiß gerade nicht, wo unser Missverständnis liegt. Genauer als ich können das vielleicht gerade mal eine Handvoll Menschen auf dieser Welt erklären, also frag hier bitte, was Du nicht verstanden hast.


    Es geht nicht über IrDA am Mac!

    Mac baut IrDA Verbindung mit T300 auf geht
    (GSM Remote, SIM express, Apple Remote Access, etc.)


    T300 baut IrDA Verbindung mit dem Mac auf geht
    (es gibt aber kein Programm dafür!)


    Das Problem ist, dass man bei Ericsson nicht auf den internen Speicher zugreifen kann. Das T300 kann nur über IrOBEX PUT seine Bilder an Computer senden. Dafür müsste aber eine Applikation am Mac laufen und die Anfrage abfangen. Leider ist die Programmierung von IrDA OBEX über IrTiny-TP unter Mac OS X aufgrund fehlender Programmier Schittstellen unmöglich und unter Mac OS 8 und 9 extrem schwierig.


    Unglaube beseitigt...

    Ich poste die Antwort auf die PN hier, da die SMS Rohdaten keine persönlichen Informationen erhalten - ausser irgendwas ist im Bild, was ich nicht "per Hand" dekodiert habe.


    0051FF00800000A79E84
    080400C70201
    167C0000B1
    8D1400012E000400061414AAAAAA0603060384E6AE6AE60C0A82AFBE060583ABDF7D060681FA060982EFBE060683E7DF7D061E82FBEF0E2D0C1E263C16158369A69A06030C0606038318618606038518619A18660C090C060806816810098319A6861E1E8368619A101E1209141E8219A1143C8218660C6908
    C8309BFD0E01


    Das erste fette ist die Länge eines so genannten "User Data Header", dass sind Hintergrundinformationen in der SMS, die nach dem SMS Standard keinen Platz mehr im eigentlichen SMS Header (alles in der ersten Reihe) finden.
    Die nächste Zeile ist ein User Data Header Element, welches eine verkette SMS signalisiert, allerdings mit einer 16 Bit langen ID - das muss auch so laut SMS Standard Kapitel 9.2.3.24.10.1.13ff Extended Object sein.
    Die nächte Zeile ist ein Element, welches ein sogenanntes Compression Control (Kapitel 9.2.3.24.10.1.15) ist. Hierbei handelt es sich um eine LZSS Komprimierung, welche eines oder mehrere Extended Objects beinhaltet. Die eigentlich Daten beginnen in der nächsten Zeile, alles andere sind nur Kopfinformationen über die beinhaltete Objektgröße.
    Die letzte Zeile ist dann der eigentliche Text von Dir: Hallo!
    Ein SMS Parser weiss aufgrund der ersten fetten Lägenangabe, wann Textinformationen anfangen. Die fetten Dinge sind Längenangaben in Hexadezimal (Grundzahl 16, anstatt 10).


    In der zweiten SMS dieser Verkettung geht das ganze Spiel einfach weiter:


    0051FF00800000A74B40
    080400C70202
    1638
    0C8369A1860A0C83BEFBEF08788C19A69A6BEFBEFBEE79E7EE790627060C83E79E7E060306038269AE081506030C0612180E09181B82EE7900


    Hier hat dann der Copression Corntrol Element kein eigene Kopfinformationen mehr - wäre ja auch doppelt gemoppelt.


    Der EMS Parser muss dann "nur" noch das Extended Object mit LZSS dekomprimieren. Die Betonung liegt auf nur. Von LZSS habe ich noch nix gehört, und müsste mich da jetzt noch einarbeiten, ob wirklich ein EMS "sauberes" frabiges Bild darin abgelegt ist - ich denke aber schon.


    Es handelt sich folglich um neuste EMS Technologie in Deinem Sagem - wäre fast alleine ein Kaufgrund für mich - gute Arbeite Sagem bzw. gut eingekauft. ;)


    So und nun zu der Frage, warum es andere EMS Klienten nicht können, bzw. wo der Datenmüll bleibt.


    Jeder SMS Parser, der User Data Header kennt, weiss ob es ein darin enthaltenes Element kennt oder nicht. Es weiss also was es nicht weiss. Alles unbekannte wird einfach verworfen und es wird beim nächten Header Element weiter gemacht. Die Informationen werden daher gar nicht bearbeitet und angezeigt. Nur ganz alte SMS Parser würden Datenmüll anzeigen, dass sind alle, die keine User Data Header kennen - was nichts mit EMS selbst zu tun hat. Beispiel wäre hier ein Sony Z5. Fast alle gängigen Geräte auf dem Markt kennen User Data Header und verwerfen die Infos folglich.


    Wenn ein anderer EMS Klient das "Extended Object" nicht kennt, dann kennt es auch keine "Compression Control" (laut Kapitel 9.2.3.24.10.1.15 Satz 4). Jeder EMS Klient, der nicht Version 5 kompatibel ist, kann auch kein "Extended Object".


    Ein EMS 5er müsste es eigentlich können - es gibt nur keines, oder? Alle andere verwerfen die Daten - finde ich auch sinnvoll, oder willst Du Datenmüll?


    Nochmal dank an PDUSpy, der einiges geholfen hat - bin doch nicht mehr so gut beim per-Hand-dekodieren - aber mit dem Compession Control Element konnte es auch nix anfangen. Nobbi...

    Zitat

    Original geschrieben von Blarney
    Ich wollte damit nur sagen, dass ein zusaetzliches Shareware Programm Bloedsinn ist , wenn iSync das dann ohnehin irgendwann kann.

    :eek:
    Tja, ab wann geht iSync nochmal? Abgesehen davon ist Apple zur Zeit noch zu blöd...