Core Bluetooth: Lesen von langer Characteristic mit Offset

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Core Bluetooth: Lesen von langer Characteristic mit Offset

    Hallo zusammen,

    ich habe ein Problem bei dem ich echt nicht mehr weiter weis. Und zwar folgendes:

    Ich habe ein Bluetooth 4.0 Peripheral mit mehreren selbst definierten Characteristics in einem Service.
    Diese Chars kann ich lesen, schreiben, notify, klappt alles.
    Ein Char allerdings ist so konzipiert, dass es einen 512 Byte großen Zufalls-Hex-String erzeugt und den in jeweils 22 Byte stückelt verschickt.
    Zusätzlich wird ein Offset vorgestellt, welches sich mit jedem Fragment erhöht, bis alle Daten übertragen worden sind.

    Mit der Mac-App LightBlue ist das empfangen kein Problem, Core Bluetooth allerdings verweigert die Annahme ;(
    Ich habe da so eine Befürchtung, dass das eine interne Limitierung von iOS ist, denn die LightBlue-App auf dem Mac bedient sich (nach meinem Wissen) dem LightBlue-Framework, geschrieben in Python, während die LightBlue-App für iOS Core Bluetooth nutzt.
    LightBlue Mac

    LightBlue iOS.

    Hoffentlich kennt sich jemand von euch damit aus und hilft mir, dieses Problem zu lösen ^^
    Loves Metal :evil:

  • Nein, LightBlue (die App) nutzt auch CoreBluetooth (sowohl unter iOS als auch unter OSX), nicht LightBlue (das Framework). Die beiden haben nur den Namen gemeinsam, sonst nicht viel - das Framework ist für Bluetooth Classic, nicht für LE. CB ist auf beiden Plattformen die einzige offizielle Userland-API zu BLE.

    CB ist unter OSX und iOS sehr ähnlich, aber im Verhalten nicht identisch. Du stückelst die Characteristics von Hand? Falls ja, würde ich mal kleinere Einheiten versuchen. Die MTU wird beim Verbindungsaufbau zwischen den Geräten verhandelt, da kann es Unterschiede geben. Wenn die Begrenzung nicht eingehalten wird gibt's natürlich Probleme. 18 Bytes Payload sollten eigentlich immer gehen.

    Aber GATT unterstützt auch lange Characteristics (read/write long/reliable), das wird dann protokollintern zerstückelt und wieder zusammengesetzt. Ich hab's noch nicht ausprobiert, aber eigentlich sollte das CB-seitig transparent implementiert sein. Kommt drauf an, ob das dein Raspi-Stack auch macht.
    Multigrad - 360°-Produktfotografie für den Mac

  • Vielen Dank für deine Antwort.
    Ich habe jetzt verschiedene Byte-Längen auf dem Raspberry ausprobiert, aber selbst mit 5 Byte klappt es nicht.
    Das komische ist ja, dass es auf der Mac LightBlue-App tadellos funktioniert, nur eben unter iOS nicht, da kann es selbst die LightBlue-App nicht.

    EDIT:
    Das Raspberry legt mir immer die ersten 22Byte von den 512 (hab auch kleinere Werte probiert, klappt auch nicht) auf das Char zum lesen. Wenn die gelesen worden sind, dann werden die nächsten 22 geschrieben, und so weiter, bis alle gelesen worden sind.
    Dafür soll (theoretisch) iOS immer das nächst höhere Offset vorstellen, dafür habe ich aber keine Möglichkeit.
    Loves Metal :evil:

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Telecaster95 ()