site_archiver(a)lists.apple.com
Delivered-To: bluetooth-dev(a)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(a)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(a)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(a)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(a)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(a)lists.apple.com)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>> https://lists.apple.com/mailman/options/bluetooth-dev/matthias%40bluekitche…
>>>>>
>>>>> This email sent to matthias(a)bluekitchen-gmbh.com
>>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com
site_archiver(a)lists.apple.com
Delivered-To: bluetooth-dev(a)lists.apple.com
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(a)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(a)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(a)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(a)lists.apple.com)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> https://lists.apple.com/mailman/options/bluetooth-dev/matthias%40bluekitche…
>>>>
>>>> This email sent to matthias(a)bluekitchen-gmbh.com
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com
site_archiver(a)lists.apple.com
Delivered-To: bluetooth-dev(a)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=qLiY4v1Pe3QN3LJDLMtRtZomP9OyxI1ghSd3TZ2FWac=; b=WjXQpH9S8W9rnu03Od8fNk5Vq/ XR7tct5Drm24zPdSK3bXL6ZB0wHkViSpJbr6SO1qprvhxgYMZk9cWYSdFyEH0W1kX19MQQNKkLRNW jqf1q2q7q8tEHdZuAgMIfxGg0ppZ/JZoRWfEcX1MgeOMoGpEqGnJVEkYOwkWPJUX87ZdZ7tEOIDET bOyQe7mNk5DdYikdznlCzPKWEtVMLKRCRLhvgVbmBY8ckUJc3jS4QUzjfajzQVPLFeQ0SKa+Kp/au BhgfTM7+xiAHXBRlM3Kr8i5ClZU6td2D2An2hyDsD+lksSRNfI47o8XS++4lnDsjkAJoOWksEBG1g PI4ZP/pg==;
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(a)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(a)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(a)lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/bluetooth-dev/matthias%40bluekitche…
>>>
>>> This email sent to matthias(a)bluekitchen-gmbh.com
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (Bluetooth-dev(a)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(a)lists.apple.com