Hi Marcel,
> > 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
>
> I still don"t get why switching inquiry scan on and off should help in
> any case. Since inquiry scan defines the discoverable mode and so you
> switch devices to unvisible when they inquiry and back to visible when
> they don"t.
I never switch inquiry scan off (the scan mode always stays PSCAN and
ISCAN). But when an inquiry is initiated, the device switches into INQUIRY
mode (or substate) from stops scanning (moves out of the INQUIRY SCAN
substate for the duration of the inquiry). That is to say, during an
inquiry a device is not discoverable (or visible). That is what I meant by
switching between the two states.
Catalin
Hi Marcel,
On Fri, 11 Feb 2005, Marcel Holtmann wrote:
> > > I still don"t get why switching inquiry scan on and off should help in
> > > any case. Since inquiry scan defines the discoverable mode and so you
> > > switch devices to unvisible when they inquiry and back to visible when
> > > they don"t.
> >
> > I never switch inquiry scan off (the scan mode always stays PSCAN and
> > ISCAN). But when an inquiry is initiated, the device switches into INQUIRY
> > mode (or substate) from stops scanning (moves out of the INQUIRY SCAN
> > substate for the duration of the inquiry). That is to say, during an
> > inquiry a device is not discoverable (or visible). That is what I meant by
> > switching between the two states.
>
> in the code you sent me, you did exactly this. So what are we talking
> about?
You're right, I did do that, but then I realized it was unnecessary (as
you yourself pointed out). However, the first issue I raised (that of
being able to inquire with a finer granularity) remains, but as you said
the solution is to go to the HCI level and stop the ongoing inquiry with
INQUIRY CANCEL.
One behaviour that I noticed (just empirically) and that is worth
mentioning is that sometimes it appears that a few shorter inquiries (1-2
seconds long) separated by pauses (of the same length) yield up more
discovered devices than one long inquiry (of say 10.28 seconds). I do not
know enough about the baseband layer to explain this and please notice I
said "sometimes" and "empirically". So this is definitely not always the
case, and it might not be the case at all since it's just based on my
empirical observations (no data, statistics to support this).
Catalin
Hi Catalin,
> > > 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
> >
> > I still don"t get why switching inquiry scan on and off should help in
> > any case. Since inquiry scan defines the discoverable mode and so you
> > switch devices to unvisible when they inquiry and back to visible when
> > they don"t.
>
> I never switch inquiry scan off (the scan mode always stays PSCAN and
> ISCAN). But when an inquiry is initiated, the device switches into INQUIRY
> mode (or substate) from stops scanning (moves out of the INQUIRY SCAN
> substate for the duration of the inquiry). That is to say, during an
> inquiry a device is not discoverable (or visible). That is what I meant by
> switching between the two states.
in the code you sent me, you did exactly this. So what are we talking
about?
Regards
Marcel
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel