Ich versuche, einen Kennwert in kurzer Zeit wiederholt zu schreiben. Verschiedene Quellen sagen, dass Raten zwischen 200 und 305 kbit/s möglich sein sollen. Allerdings erreiche ich nur ~36 kbit/s .
Ich verwende ein iPhone 4S, um die Charakteristik wiederholt zu schreiben. Ein Entwicklungsboard mit einem CSR1000 BLE-Chip dient als Peripherie, die die Schreibvorgänge akzeptiert. Ich verwende Schreibvorgänge ohne Antwort, um Bestätigungen auf der Attributebene zu vermeiden. Siehe meine Frage zu Stackoverflow für weitere Details.
Ein Schreiben auf den 20 Byte langen Kennwert erfolgt jede Millisekunde. Daher sende ich 160 kbit/s . Tatsächlich werden nur ~36 kbit/s empfangen. Das Seltsame daran ist, dass zu Beginn der Sitzung für den Bruchteil einer Sekunde alles funktioniert. Dann beginnen Pakete zu fallen. Meistens funktionieren jedoch Pakete mit vier kontinuierlichen Schreibanforderungen gut, bevor eine unterschiedliche Anzahl von Paketen wieder verworfen wird.
Ich habe eine signifikante Korrelation zwischen dem Durchsatz und dem Wert von Conn_Interval gefunden. Das iPhone 4S akzeptiert jedoch keine niedrigeren Conn_Interval-Werte als 0x0f. Dies ist bereits niedriger als das, was Apple in seinen Hardwarerichtlinien vorschlägt. Wenn ich mich an ihre Werte halte und ein Intervallminimum von 20ms und ein Intervallmaximum von 40ms verwende, sinkt der Durchsatz auf ~15 kbit/s.
Conn_Interval = 0x000f = 18.75 ms
Conn_Latency = 0x0000
Supervision_Timeout = 0x00fc
Das Papier „Modeling the Maximum Throughput of Bluetooth Low Energy in an Error-Prone Link“ von Gomez et al. beschreibt den Einfluss von Conn_Interval und Bitfehlern auf den Durchsatz. Ihrer Analyse zufolge gäbe es jedoch relativ viele Bitfehler, wenn dies die begrenzende Problemquelle wäre. Das Entwicklungsboard liegt in unmittelbarer Nähe zum iPhone 4S. Daher vermute ich, dass es andere limitierende Faktoren gibt.
Sind Sie sicher, dass all diese Pakete tatsächlich das iPhone verlassen? Vielleicht erlegt Apple Bandbreitenbeschränkungen für Apps auf, wie ich Ihnen auf Stackoverflow sagte, Sie sollten diese Frage wirklich in der Apple Bluetooth-Mailingliste stellen, wo es mehrere hilfreiche Apple-Ingenieure gibt, die Ihnen möglicherweise helfen könnten.
Andernfalls müssen Sie wirklich angeben, welche Chipsätze Sie verwenden, wenn Sie etwas aus diesen Fragen herausholen möchten.
BEARBEITEN: Ok, Sie verwenden den CSR-Chipsatz, dann schlage ich vor, sich direkt an CSR zu wenden und Ihre Frage hier zu posten:
https://lists.apple.com/mailman/listinfo/bluetooth-dev
EDIT2: Ein Sniffer könnte Ihnen sicherlich helfen zu sehen, ob diese Pakete tatsächlich vom iPhone gesendet und nicht vom CSR-Chipsatz empfangen werden, oder es ist nur so, dass das iPhone sie nie wirklich über die Luft sendet
Könnte eine Antwort von Apple bekommen, indem man eine TSI brennt und einen Monat wartet.
Grundsätzlich sagen sie, dass das Verhalten in iOS 5.1 beabsichtigt ist. Es macht irgendwie Sinn, weil sie nicht wollen, dass die Leistung Ihrer App davon abhängt, ob eine andere App Bluetooth oder WiFi verwendet.
Laut den Kommentaren der Ingenieure - Unter iOS 5.1 sollte es während eines Verbindungsintervalls 6 Benachrichtigungspaare geben, was 6*packetSize*1000/interval bedeutet. Dies sollte maximal ~55 kbps bedeuten (Mindestintervall ist 20 ms, Paketgröße ist 23 Bytes). Wir haben die Entscheidung getroffen, die Anzahl der Paare pro Intervall zu begrenzen und ein Mindestintervall zu haben, da sowohl das iPhone als auch das iPad eine gemeinsame Antenne zwischen BT Classic, BT LE und WiFi haben.
iOS LE ist als Low-Power-Transport konzipiert. Für einen höheren Durchsatz ist BT classic die bessere Transportmethode.
Zurück zu mir - Basierend auf den obigen Kommentaren der Ingenieure ist Classic Bluetooth die Antwort, wenn der Wunsch besteht, einen Durchsatz von 200 kbs zu erreichen. Wenn jedoch der Wunsch besteht, mit einer Anwendung auf dem iPhone zu arbeiten, kann ich verstehen, dass dies keine einfache Änderung ist - Classic BT erfordert eine MFI-Lizenzierung.
Welches Entwicklungsboard verwendest du? Es gab einige Probleme mit Bluegiga und dem BLE-112A. Die ursprünglichen Spezifikationen, die sie aufführten, waren in Bezug auf Speicherkapazität und verfügbare Firmware-Profiloptionen nicht ganz korrekt. Soweit ich weiß, sollten sie ihre Softwarespezifikationen basierend auf dem erhaltenen Feedback aktualisieren.
Abhängig davon, was Sie versuchen zu tun, kann eine andere Option im Tod Smart Beacon vorhanden sein. Weitere Informationen finden Sie unter todhq.com
Was Sie sehen, wenn Pakete verworfen werden, ist auf einen Pufferüberlauf entweder auf der iPhone-Seite (höchstwahrscheinlich denke ich) oder auf der Host-Seite zurückzuführen. Ab iOS 11.2 bietet Apple einen Mechanismus, mit dem Sie prüfen können, ob der Puffer bereit ist, bevor Sie das nächste Paket schreiben. canSendWriteWithoutResponse:
Wenn Sie warten, bis canSendWriteWithoutResponse wahr ist, bevor Sie ein Paket schreiben, wird garantiert, dass die Lieferung in den Empfangspuffer gestellt wurde, aber nicht garantiert, dass sie verarbeitet (unbestätigt) wurde. Die andere Sache, die helfen könnte, ist das Aushandeln einer MTU-Größe von mehr als 20. Apple unterstützt MTU bei 185B und bis zu 251 (erweiterte Datenlänge, auch bekannt als EDL). Indem Sie Ihre Datenpakete in MTU-3-Größen aufteilen, ist Ihr Paket ==(MTU-3) x 1 pro Verbindungsintervall. @ 185B MTU, 24 ms Verbindungsintervall Ich habe einen Durchsatz von etwa 48 kbps ohne verlorene Pakete. Wenn Daten vom Gerät an das iPhone gesendet werden, benötigt das SDK an diesem Ende das Äquivalent zu „canSendWriteWithoutResponse“, das in meinem Fall mit SiLabs-Hardware/SDK z
```
do {
result = gecko_cmd_gatt_server_send_characteristic_notification(
0xFF,
evt->data.evt_gatt_server_attribute_value.attribute,
chunk.length,
[chunk bytes])->result;
} while(result == bg_err_out_of_memory);
//retry until buffer is empty and ready for more
//then update the offset
offset += thisChunkSize;
```
Hier ist ein Video und eine PDF-Datei von Apple, die die verschiedenen BLE-Techniken und die erwarteten Geschwindigkeiten erklären. MTU + Verbindungsintervall ist das, was Sie verwenden, um den maximalen Durchsatz zu bestimmen. 48kps sollten problemlos erreichbar sein, 96kbps und vielleicht etwas mehr sind möglich.
Was ist neu in Core Bluetooth
video: https://devstreaming-cdn.apple.com/videos/wwdc/2017/712jqzhsxoww3zn/712/712_hd_whats_new_in_core_bluetooth.mp4?dl=1
pdf: https://devstreaming-cdn.apple.com/videos/wwdc/2017/712jqzhsxoww3zn/712/712_whats_new_in_core_bluetooth.pdf