MacOS writeWithoutResponse #1589
-
|
I am working on this issue: intercreate/smpclient#30 Initiallly I suspected an issue wherein this send method: async def send(self, data: bytes) -> None:
for offset in range(0, len(data), self.mtu):
await self._client.write_gatt_char(
self._smp_characteristic, data[offset : offset + self.mtu], response=False
)was overwhelming the peripheral with the manual fragmentation getting sent as fast as possible at MTU. After some experimentation I cannot reproduce the issue on the M3 that I'm borrowing, but obviously another user is able to reproduce reliably. However, if that were the case, it appears that this callback should be called: https://developer.apple.com/documentation/corebluetooth/cbperipheraldelegate/peripheralisready(tosendwritewithoutresponse:) So I added it to the PeripheralDelegate class: def peripheralIsReady_toSendWriteWithoutResponse_(self, peripheral: CBPeripheral, characteristic: CBCharacteristic) -> None:
logger.error("Called!")But it is never called. I have also modified the Client class here: async def write_gatt_char(
self,
characteristic: BleakGATTCharacteristic,
data: Buffer,
response: bool,
) -> None:
value = NSData.alloc().initWithBytes_length_(data, len(data))
await self._delegate.write_characteristic(
characteristic.obj,
value,
(
CBCharacteristicWriteWithResponse
if response
else CBCharacteristicWriteWithoutResponse
),
)
while self._peripheral.canSendWriteWithoutResponse() != True:
logger.error("Not ready to send!")
await asyncio.sleep(0.010)
logger.debug(f"Write Characteristic {characteristic.uuid} : {data}")That's using this API: https://developer.apple.com/documentation/corebluetooth/cbperipheral/cansendwritewithoutresponse And interestingly I do see that the canSendWriteWithoutResponse flag is false for the first ~5 iterations after each write_gatt_char (~50ms). I think it doesn't matter though because I suspect that the OS has some buffer and doesn't care that the write isn't going to be transmitted right away. This would be more of an issue if you cared about some time sensitive write (in which case don't use a desktop OS and BLE). Any help would be appreciated, thanks! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 5 replies
-
|
As the name implies, when you write without a response, there is no way to get backpressure from the peripheral to know if it is keeping up with the incoming messages. So you can either do write with response and have it be slower or have some kind of occasional notification from the peripheral to indicate that it is ready for more data. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it seems there is no error from MacOS or Bleak here. No error is raised to Bleak and all of the transmissions work for me. Primarily we've been testing Windows and Linux and hadn't sighted the problem before. I suspect it may be that MacOS is "too good" at putting these fragmented packets "in the air". @bjandre I noticed that your system was reporting an upload speed of ~24 KB/s which is way faster than mine was going at about ~13 KB/s. Maybe that's why I'm not able to reliably reproduce. Then again, I've seen Windows push 25 KB/s without issues. At any rate, I find it curious that Zephyr isn't enabling write with response for this characteristic, given that it's for critical stuff like FW updates! I haven't done much BLE work with Zephyr, but I think I have it correct that this source code is setting WRITE_WITHOUT_RESP and not WRITE_WITH_RESP: https://github.com/zephyrproject-rtos/zephyr/blob/main/subsys/mgmt/mcumgr/transport/src/smp_bt.c#L356-L368 May be interesting to open a PR at Zephyr and add a Kconfig option that would enable Afterall, the client doesn't HAVE to use it, so I'm not sure of the downsides. I think we have some good paths forward here! |
Beta Was this translation helpful? Give feedback.
-
|
Opened a discussion over at Zephyr: zephyrproject-rtos/zephyr#73623 |
Beta Was this translation helpful? Give feedback.
-
Yeah, pretty sure we've seen users with something like this at Pybricks.
The data rate would be painfully slow for something like transferring a large firmware file. |
Beta Was this translation helpful? Give feedback.
-
How slow? A "large" FW file may be about 500K. In this protocol, every "request" receives a "response" (notify). A lack of response, at least in this case, seems to indicate that MacOS overwhelmed the peripheral; the peripheral was not able to construct a complete request from the fragmented writes. Typically the 2,475B "request" is fragmented across MTUs - ideally 5 495B MTUs. Of course we can add retries to this specific routine - if a request times out we simply resend the entire request. But it almost sounds like this particular issue could be prevented by only sending requests that fit in the MTU. If a timeout did occur, MTU bytes would be retried rather than 2,475B. May slow down the transfer somewhat, but so would retries. It looks like Nordic's own iOS implementation uses a blocking delay on FYI @bjandre - if Nordic's own implementation does this it may be worth looking into. When I tried this it slowed the upload from ~13KB/s to ~5KB/s. We can work with Core Bluetooth without upstream changes to Bleak simply by accessing Core Bluetooth backend that Bleak provides. |
Beta Was this translation helpful? Give feedback.
-
You would have to measure it to see. It depends on a lot of factors.
Interesting. I would be interested to see Bluetooth packet captures comparing with this and without this. Also, I wonder if we could use an observer to monitor the canSendWriteWithoutResponse |
Beta Was this translation helpful? Give feedback.
As the name implies, when you write without a response, there is no way to get backpressure from the peripheral to know if it is keeping up with the incoming messages. So you can either do write with response and have it be slower or have some kind of occasional notification from the peripheral to indicate that it is ready for more data.