From: Catalin Drula <catalin@cs.toronto.edu>
To: steven.singer@csr.com
Cc: bluez-devel@lists.sourceforge.net
Subject: [Bluez-devel] Re: Lower granularity for INQUIRY interval
Date: Thu, 10 Feb 2005 17:42:25 -0500 (EST) [thread overview]
Message-ID: <Pine.GSO.4.58.0502101727190.7559@qew.cs> (raw)
Stever Singer wrote:
> Catalin Drula wrote:
> > Is there a way to perform INQUIRY for intervals with
> > a lower granularity than 1.28 seconds? I know the Bluetooth
> > specification says no.
> To inquire for less than 10.24 seconds is a bad idea. Unless you
> inquire for a single contiguous block lasting 10.24 seconds you do not
> have a good probability of picking up all devices.
>
> Note that, for example, 8 consecutive 1.28 second inquiries is not
> guaranteed to work.
Not necessarily a bad idea. In my case, I need to do symmetric Bluetooth
discovery. There are no predefined roles (master-slave, server-client) for
the devices which must continually scan their surroundings in order to
discover other devices. Hence, each device must continously switch between
the INQUIRY and INQUIRY SCAN states. Since in my setup, the devices will
be in range for 20-30 seconds (i.e. humans walking past each other), to
remain for 10.24 seconds in INQUIRY mode might just me too much. Imagine
that the "phases" of the devices are almost synchronized, then they will
both be in INQUIRY mode at the same time, then in INQUIRY SCAN mode at the
same time, and so on, and none of them will discover the other one.
The problem has been studied both theoretically and experimentally (for
example, see:
http://web.informatik.uni-bonn.de/IV/Mitarbeiter/scholz/10_Bohman.pdf
The conclusion of the authors of this study was that each a device should
stay in each of the two states for a random amount of time with a mean
around 2 to 3 seconds (more details, are in the above paper). Doing this
yields and average neighbor discovery delay of about 8 seconds.
Now obviously if we can only stay in INQUIRY state mode, for multiples of
1.28 seconds, the above scenario will not work. So there are _legitimate_
uses (i.e. it is not necessarily a bad idea) for my request.
For your information, I did some experiments with the above algorithm and
four Bluetooth devices. Without having precise figures, I can tell you,
that two of the devices were discovered about 50% of the time during the
first time in INQUIRY state (3-4 seconds) and about 80% time the first or
second time (8-9 seconds). The third device which is the builtin Bluetooth
card in an iPaq h5550, was discovered far less often (30 seconds). I don't
know why but I am guessing this has to do with the hardware
implementation. An USB dongle (I forget the manufacturer) was the most
"discoverable" device.
But, to put a conclusion to this, I agree with you that this has to be
done at the HCI level, and that is what my implementation does.
Catalin
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next reply other threads:[~2005-02-10 22:42 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-10 22:42 Catalin Drula [this message]
2005-02-11 0:16 ` [Bluez-devel] Re: Lower granularity for INQUIRY interval Marcel Holtmann
2005-02-11 15:03 ` Steven Singer
-- strict thread matches above, loose matches on Subject: below --
2005-02-11 17:48 Jean Tourrilhes
2005-02-11 19:01 ` Steven Singer
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=Pine.GSO.4.58.0502101727190.7559@qew.cs \
--to=catalin@cs.toronto.edu \
--cc=bluez-devel@lists.sourceforge.net \
--cc=steven.singer@csr.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox