Re: Queued Writes vs. MTU
Re: Queued Writes vs. MTU
- Subject: Re: Queued Writes vs. MTU
- From: Matthias Ringwald via Bluetooth-dev <email@hidden>
- Date: Thu, 3 Nov 2022 17:29:48 +0100
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 <email@hidden> 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
>>> <email@hidden> 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 (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden