LE/BR/EDR interleaved scanning

3 messages, 2 authors, 2012-03-19 · open the first message on its own page

LE/BR/EDR interleaved scanning

From: Ganir, Chen <hidden>
Date: 2012-03-19 12:55:19

Hi.

The current implementation of the Bluetooth-next interleaved scan will currently do LE scan , and then BR/EDR scan, although the specs clearly defines that BR/EDR device search should be performed first, and only when done, LE device scan should start. Is there a specific reason why the spec was not followed here ?

Thanks,


Chen Ganir
Texas Instruments

Re: LE/BR/EDR interleaved scanning

From: Andre Guedes <hidden>
Date: 2012-03-19 13:54:36

Hi Chen Ganir,

On Mon, Mar 19, 2012 at 9:55 AM, Ganir, Chen [off-list ref] wrote:
Hi.

The current implementation of the Bluetooth-next interleaved scan will currently do LE scan , and then BR/EDR scan, although the specs clearly defines that BR/EDR device search should be performed first, and only when done, LE device scan should start. Is there a specific reason why the spec was not followed here ?
Implementing LE scan first had some advantages:
1. From the implementation point of view, we don't need to change
anything in BR/EDR discovery neither name resolution code. All logic
in inquiry_complete_event keeps the same.
2. Doing BR/EDR + LE + name resolution we have a 5.12 sec gap between
finding BR/EDR devices and resolving its names. During LE discovery,
BR/EDR devices may be out of range and we'll waste time trying to
resolve its names. By doing LE scan first, we don't have this problem.

Besides, we didn't find any constrain in GAP TS spec about that. Also,
the Core spec clearly says performing BR/EDR + LE is just a
recommendation about how to implement interleaving (see Vol 3, page
386).

BR,

Andre

RE: LE/BR/EDR interleaved scanning

From: Ganir, Chen <hidden>
Date: 2012-03-19 13:58:10

Andre,
-----Original Message-----
From: Andre Guedes [mailto:andre.guedes@openbossa.org]
Sent: Monday, March 19, 2012 3:55 PM
To: Ganir, Chen
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: LE/BR/EDR interleaved scanning

Hi Chen Ganir,

On Mon, Mar 19, 2012 at 9:55 AM, Ganir, Chen [off-list ref] wrote:
quoted
Hi.

The current implementation of the Bluetooth-next interleaved scan
will currently do LE scan , and then BR/EDR scan, although the specs
clearly defines that BR/EDR device search should be performed first,
and only when done, LE device scan should start. Is there a specific
reason why the spec was not followed here ?

Implementing LE scan first had some advantages:
1. From the implementation point of view, we don't need to change
anything in BR/EDR discovery neither name resolution code. All logic
in inquiry_complete_event keeps the same.
2. Doing BR/EDR + LE + name resolution we have a 5.12 sec gap between
finding BR/EDR devices and resolving its names. During LE discovery,
BR/EDR devices may be out of range and we'll waste time trying to
resolve its names. By doing LE scan first, we don't have this problem.

Besides, we didn't find any constrain in GAP TS spec about that. Also,
the Core spec clearly says performing BR/EDR + LE is just a
recommendation about how to implement interleaving (see Vol 3, page
386).
Thanks for clearing that out.
BR,

Andre
Chen Ganir
Texas Instruments.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help