On 03/28/2015 01:01 AM, Marcel Holtmann wrote:
the kernel side has currently only support for 1 advertising
instance. That needs to be fixed or you need to do the rotation in
the HAL and fake it that way. Ideally you do that in the kernel since
it has better control over the hardware than userspace ever will be.
However it would work by faking it in the HAL.
If I'm not mistaken then bluez kernel drivers rely exclusively on
standard HCI commands in communicating with bluetooth hardware.
Multi-advertising doesn't seem to be a standard HCI procedure, though.
It rather seems to be a (broadcom?) vendor-specific addition we cannot
rely on in general. I didn't find any good documentation on vendor
specific HCI command sets either. Do you have something there?
Please correct me if I'm on the wrong track, but doesn't that mean that
we have to emulate multi-advertising in any case, even if it was in the
kernel?
As the new advertising mgmt api already has been designed with multiple
advertising instances in mind it seems a natural choice to implement the
multi-advertising emulation in the mgmt layer. But as I'm a complete
bluetooth/bluez newbie, I might be completely mistaken here.
What I'm wondering about are the implementation options we have for the
emulation, especially when it comes to timing. How would we schedule
advertisement data updates wrt min/max advertising intervals?
If we maintain the current advertising instance data structure with
separate advertising interval settings per instance then I'd expect
advertisement events to interleave somehow like this:
advEvt1
|xxx|................|---|xxx|................|---|xxx|...
advInt1 advDelay
advEvt2
....|---|xxx|................|---|xxx|................|---
advInt2
advEvt3
............|---|xxx|....................................|---|xxx|..
advInt3
Advertisement intervals would have to be multiples of a common factor to
avoid event collisions. And the interval would have to be long enough to
fit all instances into one cycle.
Alternatively we could schedule adv evts with a common adv interval like
this:
advEvt1 advEvt2 advEvt3
|xxx|................|---|xxx|................|---|xxx|...
advInt advDelay
I'd be in favor of the first solution which more closely emulates the
existence of independent peripheral devices sharing a common physical
adv channel.
(compare BT Core Spec 4.x, Vol 6, Part B, 4.4.2.2)
What I really wonder about, though, is how we'd be able to implement
such a timing scheme with nothing but the standard HCI API. How quickly
and reliably does the hardware respond to a large number of HCI calls as
would be required here? Does it really make sense to implement such a
low-level aspect of the protocol in the mgmt api code? What other
options do we have? I'm probably making things too complicated...
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
