Es ist ein Problem aufgetreten, bei dem die Zeit zwischen dem Schreiben eines Werts in ein Merkmal mit der Taste

[peripheral writeValue:dataPacket forCharacteristic:writeChar type:CBCharacteristicWithResponse]

und das iOS-Gerät, das das Bluetooth-Paket tatsächlich physisch sendet, nimmt immer mehr Zeit in Anspruch.

Dies kann in der folgenden Ausgabe des Debuggers veranschaulicht werden:

2013-10-23 14:12:17.510 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:17.595 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:17.598 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:17.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:17.656 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:17.657 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:22.601 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:23.123 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:23.125 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:27.601 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:28.111 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:28.113 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:32.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:34.595 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:34.597 Test App iOS[1561:60b] Packet response received


2013-10-23 14:12:37.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:39.582 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:39.585 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:42.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:44.570 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:44.573 Test App iOS[1561:60b] Packet response received

2013-10-23 14:12:47.611 Test App iOS[1561:60b] Packet sent
2013-10-23 14:12:49.558 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:12:49.560 Test App iOS[1561:60b] Packet response received

// Several packets omitted...

2013-10-23 14:13:07.610 Test App iOS[1561:60b] Packet sent
2013-10-23 14:13:09.508 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:13:09.511 Test App iOS[1561:60b] Packet response received

2013-10-23 14:13:12.610 Test App iOS[1561:60b] Packet sent
2013-10-23 14:13:14.496 Test App iOS[1561:60b] Packet sent confirmation, error = (null)
2013-10-23 14:13:14.498 Test App iOS[1561:60b] Packet response received

// Und so weiter...

Die vom Paket gesendete Nachricht wird in der Zeile unmittelbar nach dem Befehl writeValue ausgegeben, um das Datenpaket in das Merkmal zu schreiben.

Die gesendete Paketbestätigung wird in der ersten Zeile der didWriteValueForCharacteristic-Delegatmethode ausgegeben.

Die empfangene Paketantwortnachricht wird in der didUpdateValueForCharacteristic ausgegeben, die aufgerufen wird, wenn das BTLE-Gerät das Antwortpaket (über ein sekundäres Benachrichtigungsmerkmal) sendet, um den Empfang meines gesendeten Pakets zu bestätigen.

Wie anfänglich zu sehen ist, beträgt die Zeit zwischen dem Aufrufen der writeValue forCharacteristic-Methode und dem Rückruf zur Bestätigung, dass das Paket in didWriteValueForCharacteristic gesendet wurde, anfänglich 85 ms (was bereits langsam, aber erträglich ist). Ich sende diese Pakete ungefähr alle 5 Sekunden, und nach nur einer kleinen Anzahl von gesendeten Paketen erhöht sich dies auf ~ 2 Sekunden, wonach es bei 2 Sekunden fortlaufend statisch zu sein scheint. Das vom BTLE-Gerät zurückgesendete Antwortpaket ist immer ~ 2ms nach der Bestätigung des gesendeten Pakets.

Ich verstehe nicht, warum ich diese Verzögerung in den CoreBluetooth-Bibliotheken zwischen dem Aufruf von writeValue und dem Rückruf der Bestätigung didWriteValueForCharacteristic erhalte.

Im Übrigen funktioniert der Code einwandfrei (das BTLE-Gerät tut genau das, wozu es angewiesen wird, und keines der Pakete geht verloren).

Ich habe eine Beispiel-App, die vom Hersteller des BT4.0-Moduls bereitgestellt wird (einschließlich der Quelle), bei der diese zunehmende Verzögerung nicht auftritt. Leider ist die Beispiel-App so konzipiert, dass sie eine große Bandbreite an Implementierungen des Moduls bewältigt, nicht nur unsere spezifische Implementierung und so ist es enorm komplex und enthält viel Code, der für unsere Implementierung einfach nicht relevant ist. Ich habe in jeder Funktion im Beispiel Haltepunkte gesetzt und manuell durchgearbeitet, um genau zu bestimmen, welche Befehle sie ausgeben, und ich glaube, ich kopiere sie perfekt ( aber offensichtlich nicht).

Ich kann nichts sehen, was sie tun, was ich nicht tue und umgekehrt. Der einzige Unterschied, den ich zwischen den beiden Projekten feststellen kann, ist, dass meine ARC und deren manuelle Referenzzählung verwenden.

Ergänzende Informationen: Auf dem Hauptthread läuft alles (wie bei der Beispiel-App des Modulherstellers). Ich erstelle den Central Manager über die Hauptwarteschlange (ähnlich wie bei der Beispiel-App des Modulherstellers). Die CPU-Auslastung des iOS-Geräts beträgt nur 3% Meine App läuft und es scheint, als würde sich nichts aufgrund von CPU-Auslastung usw. verzögern.

Ich reiße mir damit die Haare aus und wenn jemand mögliche Ursachen oder Lösungen für dieses Problem vorschlagen kann, wäre ich auf ewig dankbar!

Danke, Rich