Beim S 65 fiel schon sehr bald die geringe Ãœbertragungsgeschwindigkeit via Bluetooth auf, während das Nokia 6230 bei der Ãœbertragung von Dateien vom Mobiltelefon auf den Desktop-Rechner knapp 70 KB pro Sekunde erreicht, sind es beim Siemens S 65 nur 7 KB pro Sekunde. Auf Nachfrage erklärte ein Mitarbeiter der technischen Hotline von Siemens, dies sei völlig normal. Eine Antwort weshalb das Endgerät auch bei optimalen Ãœbertragungsbedingungen nur ca. 1/13 der von Bluetooth zu erwartenden Geschwindigkeit erzielt werden, blieb Siemens schuldig – das Problem wurde bisher auch nicht mit einem Firmwareupdate behoben.

( Stand 03/2005 )

Datenübertragung Bluetooth Nokia 6230

Datenübertragung Bluetooth Siemens S65

Zu Beginn dieser Arbeit stürzte die Applikation sofort beim Zugriff auf die Bluetooth – API ab, die geworfene Exception mit „Error Code 4“ bezeichnete lediglich einen nicht näher bekannten Fehler. Erst durch das Update der Firmware des Endgeräts von Version 12 auf Version 25 wurde dieser Fehler behoben.

Allerdings ist die Implementierung der Bluetooth API mit der aktuellen Firmware sehr instabil und zeigt oft ohne erkennbaren Grund nach einiger Zeit einen „Internen Bluetooth-Fehler“ an, welcher die Bluetoothfunktionalität bis zu einem Neustart deaktiviert. ( Stand: 03/2005)

Mit der Firmwareversion 25 funktionierte der Verbindungsaufbau sowie das Versenden von Strings, beim Ãœbertragen des Fotos machte sich ein neues Problem bemerkbar. Entweder wurde eine Exception bei dem Versuch, die Daten in ein Image umzuwandeln, geworfen – oder das dargestellte Bild war sichtlich beschädigt.

Die Daten wurden mittels der Methode DataOutputStream.write() verschickt, welcher das byte[] mit den Bilddaten übergeben wurde. Über die Methode DataInputStream.read( b = new byte[orglength], 0, orglength) wurden die Daten empfangen, die Länge des Byte-Arrays wurde zuvor als String empfangen (orglength).

S65 mit offensichtlich korrupten Bilddaten

Zur weiteren Analyse des Fehlers wurden die Bilddaten direkt nach der Aufnahme über die interne Kamera ins Filesystem geschrieben, zum Vergleich wurden die über Bluetooth empfangenen Daten ebenso im Filesystem gespeichert. Eine Analyse mittels Hexeditor auf dem Desktoprechner zeigt folgende Darstellung:

 

Daten mit mehr als 500 – 800 byte Länge verursachten reproduzierbare Abbrüche während der Übertragung, es lies sich leider nicht feststellen ob dieses Problem vom sendenden oder vom empfangenden Gerät ausging.

Das zu übertragene ByteArray hatte eine Größe von 3,7 KB, die Verbindung brach jedoch nicht immer nach der gleichen Menge an Bytes ab, ein Muster konnte nicht erkannt werden. Es lässt sich mutmaßen dass eventuell die unter RFCOMM liegende L2CAP-Implementierung fehlerhaft ist, und Konflikte mit unterschiedlichen MTU-Größen vorliegen.

Zur weiteren Untersuchung dieses Fehlers wurde die Debugausgabe ins Filesystem umgeleitet, damit die Protokolldateien später am Rechner analysiert werden konnten.

Ausserdem wurde das byte[] in kleinere Blöcke zerteilt und verschickt, es wurden Blockgrößen von 1024, 512, 256 und 128 byte, sowie der Versand von einzelnen Bytes über die Methode writeByte() getestet.

Erst nach einem erneuten Firmwareupdate auf Version 36 liessen sich Dateien in kleinen Blöcken verschicken, die Ãœbertragung vom Client zum Server war ausreichend schnell, das Foto wurde korrekt angezeigt – jedoch wurden die Daten in die Gegenrichtung extrem langsam übertragen. Die Protokollierung der Datenübertragung in Millisekunden brachte folgende Debugausgaben:

Daten Senden:

…

BTSender:: daten geschrieben: 2300 bytes. Zeit: 3688 ms

BTSender:: daten geschrieben: 2400 bytes. Zeit: 3808 ms

BTSender:: daten geschrieben: 2500 bytes. Zeit: 3932 ms

BTSender:: daten geschrieben: 2600 bytes. Zeit: 4071 ms

BTSender:: daten geschrieben: 2700 bytes. Zeit: 4191 ms

BTSender:: daten geschrieben: 2800 bytes. Zeit: 4316 ms

Daten Empfangen:

…

BTReceiver:: daten empfangen: 3300 bytes. Zeit: 123646 ms

BTReceiver:: daten empfangen: 3400 bytes. Zeit: 127431 ms

BTReceiver:: daten empfangen: 3500 bytes. Zeit: 131105 ms

BTReceiver:: daten empfangen: 3600 bytes. Zeit: 134903 ms

BTReceiver:: daten empfangen: 3700 bytes. Zeit: 138563 ms

 

Reproduzierbar war, dass die Übertragung immer vom Client an den Server mit geringer, aber ausreichender Geschwindigkeit funktionierte ( ca. 640 byte/s ), in die Gegenrichtung wurden durchschnittlich jedoch nur 28 byte/s übertragen. Eine Übertragungsdauer für ein 3,7 KB großes Foto von mehr als zwei Minuten ist für eine reale Anwendung natürlich nicht akzeptabel.

Nach einem weiteren Firmware-Update auf Version 43 und einer Blockgröße von 100 byte war dieser Fehler behoben, die Daten lassen sich nun mit ca. 1 KB/s übertragen, was angesichts der maximal möglichen 96 KB/s recht dürftig ist, jedoch funktioniert die Übertragung relativ zuverlässig. Vereinzelte Verbindungsabbrüche und die Übertragung von korrupten Datenpaketen beim VoiceChat liessen sich im Rahmen dieser Diplomarbeit nicht vollständig ausmerzen. Ebensowenig ist es mit dieser Firmwareversion möglich, das Byte-Array als ganzes zu übertragen, die Übertragung muss in 100-byte Blöcken stattfinden, ansonsten bricht die Übertragung nach wie vor ab.

Prinzipiell würde das S65 mit den entsprechenden Anpassungen also als, wenn auch sehr instabile und proprietäre, Plattform für die Anwendung genügen. Jedoch machen zwei weitere Fehler in der Bluetooth-Implementierung die Funktion der Anwendung in der Realität derzeit noch unmöglich.

Beim Aufruf von Connector.open() wird mittels den Attributen “;authenticate=false”+”;authorize=false” hinter der Bluetooth UUID angegeben, dass die Verbindung nicht durch den Benutzer bestätigt werden, und auch keine Autorisierung des anderen Geräts ( Pairing ) durchgeführt werden muss. Leider ignoriert die Siemens-Implementierung diese Attribute und verlangt vor jeder Verbindung zwingend das Pairing der beiden Endgeräte, also das Austauschen eines beiden Benutzern bekannten PIN-Codes. Zusätzlich muss der Benutzer des Endgeräts, das bei der Verbindung als Server fungiert, die eingehende Verbindung mit OK bestätigen.

Natürlich ist es unzumutbar für den Benutzer, die Kommunikation mit jedwedem Gerät zu bestätigen, geschweige denn jedesmal ein Pairing durchzuführen, wenn passender Service auf einem anderen Gerät gefunden wurde. Da dieser Fehler schon früh aufgefallen war, wurde die Applikation dementsprechend konzipiert, dass das Profil bzw. Kennwort über die Service-Description abgefragt werden kann, und somit das Pairing bzw. Bestätigen der Verbindung nur im Falle einer einseitigen Übereinstimmung nötig ist und somit nur wirklich interessante Kommunikationspartner die Aufmerksamkeit des Benutzers erfordern.

Doch selbst diese konzeptionelle Anpassung an die Siemens-Telefone war mit wenig Erfolg beschehrt, da die Abfrage der Service-Description des Servers durch den Client auf den Endgeräten, anders als im WTK – Emulator, immer den Wert null zurückgab.

Vielleicht werden die Fehler im Laufe der Zeit von neueren Firmwareversionen behoben, jedoch liess der Abgabetermin dieser Diplomarbeit keine weiteren Versuche zu.

 

Ähnliche Artikel zu "J2ME Datenübertragung via Bluetooth":

Wenn Du noch Fragen zum Thema J2ME Datenübertragung via Bluetooth hast, dann schreib einfach einen Kommentar - oder schau dir meine Buchtipps an:

• Java ME - Anwendungsentwicklung für Handys, PDA und Co.
  
• Mobile Games - Spieleprogrammierung mit J2ME
  
• DAS Standardwerk: J2ME - Entwickung mobiler Anwendungen