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=V7NHUmEFD1nIiCRWovNbUCXs0xFwCM1xVlm9CwctIt0=; b=hCLWdfAo1KP7/5+o0Pi2v9LyfE /S1mVv2+ARQNucRrPf8LUacZ6I3cJnCKtt9aVkOoEVO2W6tWCwu6oPiv8VeFaKRd2MomikKnQsrKb Haw1FhPDhOp1VcmwX6XGnNsPyvbH3/BVhZEW4DZENjnVrBJ0m1ZedjWsFJQH3MJ7skrQJ8COYgdBz 5paMXVCv+5EEikRL751n363Wru4kqQI5grD0U7Hqb5cfGwSkhV82s3xegUNSNraUZoidNXNdOm7cj ewxQXUMZW6XaqUFg2rTYIy4YaZCdxJutkALY9e3Qc8C6B773pMuRZnf0K5AN1VoLa7nwt2A/6Bxtf VH5ccB7w==;
Hi Mickey
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.
Could you post a PacketLogger trace to check the ATT PDUs?
How did you get the max write size? CBPeripheral:maximumWriteValueLength with
both write types?
Best
Matthias
> 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 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/site_archiver%40lists…
This email sent to site_archiver(a)lists.apple.com