[Bluez-users] Inquiry in Bluetooth 1.2

[Bluez-users] Inquiry in Bluetooth 1.2

[Simon Siemens]

The Bluetooth 1.2 specification has to major improvements to reduce the
inquiry time: Enhanced Inquiry Scan and Interlaced Inquiry Scan
(http://wireless.sys-con.com/read/43887.htm). The article states, that
enhanced inquiry scan reduces the maximum inquiry time from 10 to 5
seconds and improves the reliability. Interlaced inquiry scan should
halve the inquiry time further.

As far as I understood things both mechanisms act on the side of the
listener, not the discoverer. I can also find both names in the feature
section of the Bluetooth 1.2 specification (section 3.2 on page 203).
The interlaced inquiry scan is described in section 8.4.1 "Inquiry scan
substate" (on page 144) as a method, where the scanning device checks
not only one but two frequencies in both trains at once. This halves the
maximum inquiry time.

However I could not find anything further about enhanced inquiry scan.
And tests with two Bluetooth v2.0 +EDR devices did not reduce the
maximum inquiry time (without interlaced inquiry) below 10 seconds.

So what is this enhanced inquiry scan? How is it compared to the old
v1.1 inquiry scan? How can I activate it? (Currently one device is a
Nokia N70 and the other is a Linux computer with a MSI 3X BToes dongle.)

Thanks a lot,

Simon



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Inquiry in Bluetooth 1.2

[Mahtab Hossain]

[-- Attachment #1.1: Type: text/plain, Size: 3161 bytes --]

Hi,

As far as I know about bluetooth's inquiry (no idea about Interlaced scan though), it is suggested to take 10.24 sec to complete. I will try to explain a bit what I had read in Bluetooth spec. 1.2:

It uses 32 dedicated freq. (16 in one train and 16 in another) - one train is 10 ms long with 16 transmit slots (each 312.5 micro-sec long) and 16 corresponding receive slots which make the time period for one train 10 ms  long (16*312.5*2 = 10 ms). Now one train is suggested to repeat at least 256 times before switching to another train and the whole process repeats itself. There are 3 such switches. So the total time becomes = 256 * 10 * 4 = 10.24 sec. But there is no hard-bound limit on this time-period according to specification.

How did you measure the time taken for your inquiry taking 10 sec? Are you using "hcitool inq" command or anything else? I also plan to vary the inquiry time period to see the effects. Any idea how can I achieve this - I mean how to vary the default 10 sec period of inquiry time to make a bit shorter or larger? Or is it absolutely chip-dependent and can't be altered using the BlueZ stack? Any help on this would be appreciated!

Thanks in Advance
Mahtab

Simon Siemens <Simon.Siemens@arcor.de> wrote: The Bluetooth 1.2 specification has to major improvements to reduce the
inquiry time: Enhanced Inquiry Scan and Interlaced Inquiry Scan
(http://wireless.sys-con.com/read/43887.htm). The article states, that
enhanced inquiry scan reduces the maximum inquiry time from 10 to 5
seconds and improves the reliability. Interlaced inquiry scan should
halve the inquiry time further.

As far as I understood things both mechanisms act on the side of the
listener, not the discoverer. I can also find both names in the feature
section of the Bluetooth 1.2 specification (section 3.2 on page 203).
The interlaced inquiry scan is described in section 8.4.1 "Inquiry scan
substate" (on page 144) as a method, where the scanning device checks
not only one but two frequencies in both trains at once. This halves the
maximum inquiry time.

However I could not find anything further about enhanced inquiry scan.
And tests with two Bluetooth v2.0 +EDR devices did not reduce the
maximum inquiry time (without interlaced inquiry) below 10 seconds.

So what is this enhanced inquiry scan? How is it compared to the old
v1.1 inquiry scan? How can I activate it? (Currently one device is a
Nokia N70 and the other is a Linux computer with a MSI 3X BToes dongle.)

Thanks a lot,

Simon



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users


 		
---------------------------------
Do you Yahoo!?
 Everyone is raving about the  all-new Yahoo! Mail.

[-- Attachment #1.2: Type: text/html, Size: 3556 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Inquiry in Bluetooth 1.2

[Simon Siemens]

Hi Mahtab,

thanks for your explanation of the discovery process. I only knew the
10.24 seconds, but not exactly, how it is calculated.

Now some hints to your questions: The complete inquiry process remains
unchanged from the discoverer's point of view. I think they did this for
compatibility reasons. Both, enhanced inquiry scan and interlaced
inquiry scan, should be modifications on the listening (scanning) side
(the one who wants to be discovered). Therefore a Bluetooth v1.2 still
takes 10.24 seconds for a complete inquiry, but v1.2 device around it
should be found faster.

For interlaced inquiry this is definitely the case: The listening device
scans in both trains at once, halving the time to _be_ discovered. This
is obvious from your description.

For enhanced inquiry scan I cannot speak, because I don't really know
what it is. But - as the name says - it should be on the scanning
(listening) side. I will do some further investigations on this.

So if the complete inquiry still takes 10.24 seconds, how does it help
then. It only helps, if you don't need all devices, but only a certain
one. E.g. you could offer the user each device at the point in time it
is found. Then he can immediately react, as soon as he sees the desired
device.

Another example: I need this for some kind of mesh networking. For me,
the first device I find is sufficient. If the maximum time for a BT v1.2
device to be discovered is indeed 5 seconds (or 2.5 seconds with
interlaced inquiry), then it is obvious, that I finished my inquiry
within those 5 seconds.

You can test this behaviour with

    hcitool inq --flush --numrsp=1

You can then see, that it always takes a different time to discover the
first device. It is between about 1 and 11 seconds. (You can find more
options for inq with hcitool inq --help). I'm currently writing a small
piece of Java software, which should perform many inquiries and do some
statistics on it. If there is no device it scans between 10.26 and 10.31
seconds. The difference to the 10.24 seconds might be processing time
before and after the inquiry.

Best regards,

Simon



Mahtab Hossain schrieb:
> Hi,
>
> As far as I know about bluetooth's inquiry (no idea about Interlaced
> scan though), it is suggested to take 10.24 sec to complete. I will
> try to explain a bit what I had read in Bluetooth spec. 1.2:
>
> It uses 32 dedicated freq. (16 in one train and 16 in another) - one
> train is 10 ms long with 16 transmit slots (each 312.5 micro-sec long)
> and 16 corresponding receive slots which make the time period for one
> train 10 ms  long (16*312.5*2 = 10 ms). Now one train is suggested to
> repeat at least 256 times before switching to another train and the
> whole process repeats itself. There are 3 such switches. So the total
> time becomes = 256 * 10 * 4 = 10.24 sec. But there is no hard-bound
> limit on this time-period according to specification.
>
> How did you measure the time taken for your inquiry taking 10 sec? Are
> you using "hcitool inq" command or anything else? I also plan to vary
> the inquiry time period to see the effects. Any idea how can I achieve
> this - I mean how to vary the default 10 sec period of inquiry time to
> make a bit shorter or larger? Or is it absolutely chip-dependent and
> can't be altered using the BlueZ stack? Any help on this would be
> appreciated!
>
> Thanks in Advance
> Mahtab
>
> */Simon Siemens <Simon.Siemens@arcor.de>/* wrote:
>
>     The Bluetooth 1.2 specification has to major improvements to
>     reduce the
>     inquiry time: Enhanced Inquiry Scan and Interlaced Inquiry Scan
>     (http://wireless.sys-con.com/read/43887.htm). The article states, that
>     enhanced inquiry scan reduces the maximum inquiry time from 10 to 5
>     seconds and improves the reliability. Interlaced inquiry scan should
>     halve the inquiry time further.
>
>     As far as I understood things both mechanisms act on the side of the
>     listener, not the discoverer. I can also find both names in the
>     feature
>     section of the Bluetooth 1.2 specification (section 3.2 on page 203).
>     The interlaced inquiry scan is described in section 8.4.1 "Inquiry
>     scan
>     substate" (on page 144) as a method, where the scanning device checks
>     not only one but two frequencies in both trains at once. This
>     halves the
>     maximum inquiry time.
>
>     However I could not find anything further about enhanced inquiry scan.
>     And tests with two Bluetooth v2.0 +EDR devices did not reduce the
>     maximum inquiry time (without interlaced inquiry) below 10 seconds.
>
>     So what is this enhanced inquiry scan? How is it compared to the old
>     v1.1 inquiry scan? How can I activate it? (Currently one device is a
>     Nokia N70 and the other is a Linux computer with a MSI 3X BToes
>     dongle.)
>
>     Thanks a lot,
>
>     Simon
>
>
>
>     -------------------------------------------------------------------------
>     Using Tomcat but need to do more? Need to support web services,
>     security?
>     Get stuff done quickly with pre-integrated technology to make your
>     job easier
>     Download IBM WebSphere Application Server v.1.0.1 based on Apache
>     Geronimo
>     http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>     _______________________________________________
>     Bluez-users mailing list
>     Bluez-users@lists.sourceforge.net
>     https://lists.sourceforge.net/lists/listinfo/bluez-users
>
>
> ------------------------------------------------------------------------
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail.
> <http://us.rd.yahoo.com/evt=42297/*http://advision.webevents.yahoo.com/mailbeta>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> ------------------------------------------------------------------------
>
> _______________________________________________
> Bluez-users mailing list
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>   

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Inquiry in Bluetooth 1.2

[Steven Singer]

Simon Siemens wrote:
> So what is this enhanced inquiry scan? How is it compared to the old
> v1.1 inquiry scan? How can I activate it?

Here's an answer I wrote to someone else who asked me this question
today.

I've not checked all the details and I may have simplified in places, but
it should be close enough for you to understand the difference.

-------------------------------------------------------------------------
Enhanced inquiry scan is a mandatory feature in 1.2 and is not a feature
that can be turned on and off. All 1.2 devices do enhanced inquiry scan
all the time.

Enhanced inquiry scan is entirely backwards compatible with the inquiry
procedure in 1.1 and earlier (in fact, the inquiry procedure was not
changed between 1.1 and 1.2).

The enhancement is just a minor change to the inquiry scan timing. In
BT 1.1 the inquiry scan procedure is:

    1) Go into scan for the time specified by the inquiry scan window.
    2a) If you don't receive an ID packet before the end of the window:
       + wait until the next inquiry scan interval
       + go to stage 1
    2b) if you receive an ID packet before the end of the window:
       + back off for 0..1023 slots
       + go into inquiry scan again for 128 slots.
       + if you receive an ID packet before the end of the 128 slots:
         * send an FHS packet
         * go to stage 1
       + If you don't receive an ID packet before the end of the 128
         slots:
         * go to stage 1

In 1.2, the procedure is simplified to:

    1) Go into scan for the time specified by the inquiry scan window.
    2a) If you don't receive an ID packet before the end of the window:
       + wait until the next inquiry scan interval
       + go to stage 1
    2b) if you receive an ID packet before the end of the window:
       + send an FHS packet
       + back off for 0..1023 slots
       + go to stage 1

The big difference is that in 1.1 you a device backs off before it
responds and then must be hit in a window after the backoff, whereas,
in 1.2 a device responds in its normal window before it backs off.

This means that 1.2 devices respond sooner than 1.1 devices. This
means that responses can be collected faster.

Also, with the 1.1 procedure, there was a chance that even with perfect
radio conditions, it was possible to have a timing such that not all
devices could respond. In 1.2, that pathology has been removed so that
all devices should be detected (assuming there are no collisions).
-------------------------------------------------------------------------

The timing pathology I refer to is when a 1.1 device receives the initial
ID packet just before the inquirer changes trains (which someone's
already explained in this thread). In that case, after the backoff, the
scanner is listening while the inquirer is on the other train. By the
time the inquirer has returned to this train, the 128 slot timeout has
expired and the scanner needs to be hit twice to respond.

I hope this helps.

	- Steven
-- 


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Inquiry in Bluetooth 1.2

[Marcel Holtmann]

Hi Steven,

> Here's an answer I wrote to someone else who asked me this question
> today.

I think it is time for a "Steven Singer FAQ for Bluetooth" ;)

Thanks for all your detailed answers. They are really appreciated.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] Inquiry in Bluetooth 1.2

[Simon Siemens]

Thanks a lot for the good explanation, Steven. I am currently doing some
empirical tests to see what this means with real devices. Maybe I can
post some results next week.

Interesting is also, that a Nokia N70 claims to be a Bluetooth v2.0
device, but does not advertise the enhanced inquiry feature, which is
mandatory.

$ sudo hcitool info 00:17:4B:14:F2:A8
Requesting information ...
BD Address: 00:17:4B:14:F2:A8
Device Name: Nokia N70
LMP Version: 2.0 (0x3) LMP Subversion: 0x6cc
Manufacturer: Cambridge Silicon Radio (10)
Features: 0xbf 0xee 0x0f 0x46 0x98 0x19 0x00 0x00
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <sniff mode> <RSSI>
<channel quality> <SCO link> <HV3 packets> <u-law log>
<A-law log> <CVSD> <paging scheme> <power control>
<transparent SCO> <EDR ACL 2 Mbps> <EDR ACL 3 Mbps>
<inquiry with RSSI> <AFH cap. slave> <AFH class. slave>
<3-slot EDR ACL> <5-slot EDR ACL> <AFH cap. master>
<AFH class. master>

But I think (hope :-)) there will be more and more mobile phones with
enhanced and interlaced inquiry in the future.

Thanks again, Simon


Steven Singer schrieb:
> Simon Siemens wrote:
>   
>> So what is this enhanced inquiry scan? How is it compared to the old
>> v1.1 inquiry scan? How can I activate it?
>>     
>
> Here's an answer I wrote to someone else who asked me this question
> today.
>
> I've not checked all the details and I may have simplified in places, but
> it should be close enough for you to understand the difference.
>
> -------------------------------------------------------------------------
> Enhanced inquiry scan is a mandatory feature in 1.2 and is not a feature
> that can be turned on and off. All 1.2 devices do enhanced inquiry scan
> all the time.
>
> Enhanced inquiry scan is entirely backwards compatible with the inquiry
> procedure in 1.1 and earlier (in fact, the inquiry procedure was not
> changed between 1.1 and 1.2).
>
> The enhancement is just a minor change to the inquiry scan timing. In
> BT 1.1 the inquiry scan procedure is:
>
>     1) Go into scan for the time specified by the inquiry scan window.
>     2a) If you don't receive an ID packet before the end of the window:
>        + wait until the next inquiry scan interval
>        + go to stage 1
>     2b) if you receive an ID packet before the end of the window:
>        + back off for 0..1023 slots
>        + go into inquiry scan again for 128 slots.
>        + if you receive an ID packet before the end of the 128 slots:
>          * send an FHS packet
>          * go to stage 1
>        + If you don't receive an ID packet before the end of the 128
>          slots:
>          * go to stage 1
>
> In 1.2, the procedure is simplified to:
>
>     1) Go into scan for the time specified by the inquiry scan window.
>     2a) If you don't receive an ID packet before the end of the window:
>        + wait until the next inquiry scan interval
>        + go to stage 1
>     2b) if you receive an ID packet before the end of the window:
>        + send an FHS packet
>        + back off for 0..1023 slots
>        + go to stage 1
>
> The big difference is that in 1.1 you a device backs off before it
> responds and then must be hit in a window after the backoff, whereas,
> in 1.2 a device responds in its normal window before it backs off.
>
> This means that 1.2 devices respond sooner than 1.1 devices. This
> means that responses can be collected faster.
>
> Also, with the 1.1 procedure, there was a chance that even with perfect
> radio conditions, it was possible to have a timing such that not all
> devices could respond. In 1.2, that pathology has been removed so that
> all devices should be detected (assuming there are no collisions).
> -------------------------------------------------------------------------
>
> The timing pathology I refer to is when a 1.1 device receives the initial
> ID packet just before the inquirer changes trains (which someone's
> already explained in this thread). In that case, after the backoff, the
> scanner is listening while the inquirer is on the other train. By the
> time the inquirer has returned to this train, the 128 slot timeout has
> expired and the scanner needs to be hit twice to respond.
>
> I hope this helps.
>
> 	- Steven
>   

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users