From: Florian Grandel <fgrandel@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Multi-Advertising: implementation options, timing questions
Date: Sat, 28 Mar 2015 14:32:44 +0100 [thread overview]
Message-ID: <5516AD7C.3040401@gmail.com> (raw)
In-Reply-To: <E29758F5-D9B1-49AE-A35E-FE06CDD7835F@holtmann.org>
>
> Whatever you read in the link layer section is something you can forget about right now. That is why the mgmt API actually does not mention advertising delay or internal or alike. It is a bit higher level API with the same affect. It is just less efficient to do that in kernel, then in the controller.
>
> So here is how it is suppose to be done. The duration parameter controls the length an advertising instance stays active. Let say you have two instances, both with 5 seconds each as duration parameter. All instances will be scheduled in round robin fashion.
>
> instance 1 -> 5 seconds, instance 2 -> 5 seconds, instance 1 -> 5 seconds and so on
>
> One thing we need to figure out if controllers let us change the advertising data and scan response data on the fly without disabling advertising or if we have to disable it first. Maybe this needs quirking if different controllers behave differently.
>
> This is as close as we get towards multi-advertising that we just emulate in the host. If there is a controller with offload capabilities, we can at some point just start using it. However that is not the main concern. It has to work on standard hardware as well. Even if it is less efficient.
>
Got it. Makes all sense to me.
I also found the documentation for the command in mgmt-api.txt in the
meantime.
I'll see how far I get from here then...
next prev parent reply other threads:[~2015-03-28 13:32 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-27 23:51 Nexus 4 in BLE peripheral role with bluez stack Florian Grandel
2015-03-28 0:01 ` Marcel Holtmann
2015-03-28 6:45 ` Multi-Advertising: implementation options, timing questions Florian Grandel
2015-03-28 6:57 ` Marcel Holtmann
2015-03-28 13:32 ` Florian Grandel [this message]
2015-03-28 20:18 ` Arman Uguray
2015-03-29 23:23 ` Florian Grandel
2015-03-30 0:48 ` Marcel Holtmann
2015-03-30 17:23 ` Jakub Pawlowski
2015-03-30 17:44 ` Arman Uguray
2015-03-30 18:04 ` Jakub Pawlowski
2015-03-30 21:57 ` Marcel Holtmann
2015-03-30 22:26 ` Jakub Pawlowski
2015-04-01 12:34 ` Florian Grandel
-- strict thread matches above, loose matches on Subject: below --
2015-03-30 22:37 Jakub Pawlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5516AD7C.3040401@gmail.com \
--to=fgrandel@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.