Hi,
I want to monitor what BT devices come into range of mt BT stick for
automation. For this I'm currently just using 'hcitool scan' in a
loop. Sometimes the scan is pretty quick, 2-3 seconds, but most of the
time the scan takes about 13 seconds, which is too long for my
purposes. Can I influence these scan times somehow, possibly even with
a setting on the palm/phone itself? Why do the scan times vary so
much?
Thanks,
Emiliano
-------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Emiliano,
> I want to monitor what BT devices come into range of mt BT stick for
> automation. For this I'm currently just using 'hcitool scan' in a
> loop. Sometimes the scan is pretty quick, 2-3 seconds, but most of the
> time the scan takes about 13 seconds, which is too long for my
> purposes. Can I influence these scan times somehow, possibly even with
> a setting on the palm/phone itself? Why do the scan times vary so
> much?
look at the periodic inquiry stuff of the HCI.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Fri, 18 Feb 2005 23:45:35 +0100, Marco Trudel <[email protected]> wrote:
> > OK, thanks. This could actually work to my benefit if I disable the
> > hcitool cache --
>
> you're welcome...
>
> > the device could take the time the user takes from
> > walking into range to being at the device for detecting,
>
> I don't know what you mean with this...
>
> > if you walk
> > out of range before that you were only passing the device. Good. Now I
> > only have to look at average office walking speeds to see how great I
> > want this radius to be :)
>
> I don't understand that as well, but it sounds very interesting. Can you
> explain what you're doing? Just curious...
We have a kiosk where you have to select your name from a list before
you can do anything useful. You pick your name from a scrollist. What
I want to try is to install a bluetooth adapter on the device, allow
people to register their BT toys (phone, palm, whatever), and have the
device scan for BT devices in the vicinity. If it recognizes a
registered device, it could pre-select your name from the list, for
convenience.
If BT scan was super-fast, anyone standing at the device would be
bothered by anyone else passing by with a BT gadget active. With a 13
sec discovery time, and given the right range, passers-by would be
out of range before actually being picked up. And if the range is just
wide enough, the scan would start at the edge of that range, and would
finish some seconds after you're standing at the device. It'd take
some tweaking, but since people usually slow their pace before
stopping, it could work.
> by the way: do you know that a device does not have to answer to an
> inquiry? if a device is busy or just decides to not answer to an inquiry,
> that's ok (defined in bluetooth specification, my experience showed this as
> well)...
If we'll be using this (it's just a friday afternoon experiment at
this point) it's just an add-on for convenience. There will actually
only be a minority of our users that will be carrying active BT
gadgets.
Emiliano
-------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Emiliano Heyns wrote:
> On Fri, 18 Feb 2005 19:49:32 +0100, Marco Trudel <[email protected]> wrote:
>
>>hello emiliano
>>
>>read the bluetooth specification.
>>you've to allow remote devices ~10.5 seconds to answer... so 13 seconds
>>makes sense...
>>that it is so fast from time to time is, because a cached result is
>>returned. look at the source of hcitool for more information...
>
>
> OK, thanks. This could actually work to my benefit if I disable the
> hcitool cache --
you're welcome...
> the device could take the time the user takes from
> walking into range to being at the device for detecting,
I don't know what you mean with this...
> if you walk
> out of range before that you were only passing the device. Good. Now I
> only have to look at average office walking speeds to see how great I
> want this radius to be :)
I don't understand that as well, but it sounds very interesting. Can you
explain what you're doing? Just curious...
by the way: do you know that a device does not have to answer to an
inquiry? if a device is busy or just decides to not answer to an inquiry,
that's ok (defined in bluetooth specification, my experience showed this as
well)...
regards
Marco
-------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Fri, 18 Feb 2005 19:49:32 +0100, Marco Trudel <[email protected]> wrote:
> hello emiliano
>
> read the bluetooth specification.
> you've to allow remote devices ~10.5 seconds to answer... so 13 seconds
> makes sense...
> that it is so fast from time to time is, because a cached result is
> returned. look at the source of hcitool for more information...
OK, thanks. This could actually work to my benefit if I disable the
hcitool cache -- the device could take the time the user takes from
walking into range to being at the device for detecting, if you walk
out of range before that you were only passing the device. Good. Now I
only have to look at average office walking speeds to see how great I
want this radius to be :)
-------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
hello emiliano
read the bluetooth specification.
you've to allow remote devices ~10.5 seconds to answer... so 13 seconds
makes sense...
that it is so fast from time to time is, because a cached result is
returned. look at the source of hcitool for more information...
regards
Marco
Emiliano Heyns wrote:
> Hi,
>
> I want to monitor what BT devices come into range of mt BT stick for
> automation. For this I'm currently just using 'hcitool scan' in a
> loop. Sometimes the scan is pretty quick, 2-3 seconds, but most of the
> time the scan takes about 13 seconds, which is too long for my
> purposes. Can I influence these scan times somehow, possibly even with
> a setting on the palm/phone itself? Why do the scan times vary so
> much?
>
> Thanks,
> Emiliano
>
>
> -------------------------------------------------------
> 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-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
>
-------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users