site_archiver@lists.apple.com Delivered-To: bluetooth-dev@lists.apple.com Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluekitchen-gmbh.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description; bh=60PEe24cEK7vHLB0qg2bOGVmbFKim2Au+JR+AuK6j54=; b=tm3McPgnUqBZsBprY92wLybtup EqST15laXHg8MRLDpvsux5efFGlRLgMmMawiBQiuG9s9cjrp718WoJyreR5zFEvR6JnuLJlGpQHR/ yzdadNvRAHsG8UPJF2Jni6BKkkQkVb+2jAhXrbN09RtBo6sBg+q+wR87100YVQSQpex46vy3GUyUh piERYk32a3JTPsxuiZu1sTT42II/hAxGo3piHNVU0vVeni4No9v+dQf+WGQ91QasMx7mf7jDkEr3h osWS9sfEjJ+sis3v3n9LhjkRYx1sEn2JYTdrSaDE2hJ1TGm1UM8zJyj3vbIw/CaWuIXHEZwq485lt +zMiU4Ag==; Hi Mickey As for the maximal length, that's a good question. In the Bluetooth Spec, I can find. ATT, 3.29. Long Attributes: "... It is not possible to determine if an attribute value is longer than (ATT_MTU-3) octets using this protocol. A higher layer specification will state that a given attribute can have a maximum length larger than (ATT_MTU-3) octets. The maximum length of an attribute value shall be 512 octets...." So, there's no way in ATT to query an attribute length. On the other hand, it might work if the peripheral supports Queued Writes. I would agree that the documentation could be improved to explain that the value for WriteWithoutResponse returns a best effort by the OS, but that it might not work. :) Best Matthias

On 4 Nov 2022, at 13:32, Michael Lauer <mickey@vanille.de> wrote:

I see and will do that, thanks.

For the records though, do we agree that unconditionally returning 512 for WriteWithResponse is an iOS bug?

Best,

:M:

...

On 3. Nov 2022, at 17:29, Matthias Ringwald <matthias@bluekitchen-gmbh.com> wrote:

Hi Mikey

According to the log, the ATT MTU is 247, which you also get back from CBPeripheral: maximumWriteValueLength for Write Without Response. So, that's correct. It looks like CoreBluetooth sends data shorter then the ATT MTU as write without response (write command), and uses prepared writes for longer ones.

I guess if you chunk your data based on the maximumWriteValueLength for write without response, you should be good.

Best Matthias

...

On 2 Nov 2022, at 14:34, Dr. Michael 'Mickey' Lauer <mickey@vanille.de> wrote:

Hi Matthias,

...

Is there are reason for write commands longer than 247 bytes? The over-the-air packets cannot be bigger anyway, so there's not much throughput improvement.

I see. Well, I just want to maximize bandwidth. The commands I’m sending to the device are max. 8K and I though the less fragmentation on the transport layer the better.

...

Could you post a PacketLogger trace to check the ATT PDUs?

Please find the trace attached. Note that the problematic device is 48:23:35:00:B5:A4 and from the App-perspective I’m sending my first long command (512 bytes of data) @ Oct 25, 15:26:11.676 ­when the transfer suddenly stalls.

...

How did you get the max write size? CBPeripheral:maximumWriteValueLength with both write types?

Correct.

Best regards,

Mickey.

<obdlink-cx-512-loss.pklg>

...

...

On 28 Oct 2022, at 15:42, Dr. Michael 'Mickey' Lauer via Bluetooth-dev <bluetooth-dev@lists.apple.com> wrote:

I have a problem with a BLE peripheral and iOS. It’s unclear who is to blame, but one (or both) are doing something bogus.

Let’s assume I only want to do WriteWithResponse in order to have better diagnostics (delegate being called after transmit).

When I ask iOS for the WriteWithResponse MTU, it returns 512. Sending packets up to 247 data bytes works fine (which, by the way, is what iOS reports for WriteWithoutResponse), but once I exceed this, iOS sends a PREPARE WRITE to my peripheral, which ­– due to that peripheral not implementing queued writes ­– is not answered and the whole transfer stalls.

Unfortunately it is an off-the-shelf BLE device (OBDLink CX OBD2 adapter), where I don’t have any control over the stack it’s using.

Could anyone share some light on this? Let’s start by the question why iOS claims 512 to be an OK MTU for that peripheral?

Best regards,

Mickey. _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/matthias%40bluekitchen...

This email sent to matthias@bluekitchen-gmbh.com

_______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.... This email sent to site_archiver@lists.apple.com