Thx for the hint.
I will check how to do this.
Does anyone know if bluez supports this "language code switching" ?
regards,
pet
> Hi Peter,
>
> > this question/problem is (maybe) not directly related with bluez .
> > i use bluez with a class 2 usb dongle together with a wireless lan
> > pcmcia card. bluez is used for a rfcomm connection to a bluetooth
> > input device and works really great! actually data is beeing
> > transmitted not very often and only a few bytes, but the rfcomm
> > connection has to be open all the time.
> >
> > i knew that bluetooth and wireless lan use the same frequenzy band
> > and that this may lead to problems but for me it's totally unuseable!
> >
> > as soosn as i move more than 10 feet away from the wlan accesspoint
> > i get a packetloss from more than 30 percent even if no data is
> > being transmitted via the rfcomm connection.
> >
> > i dont' understand why wlan transmission is affected even if no data
> > goes over the bluez rfcomm connection!?
>
> even if is there is no traffic on the RFCOMM connection doesn't mean
> that there is no traffic at all. Due the fast hopping frequency of
> Bluetooth it is more robust than WLAN and in general there is nothing
> you can do ;) You can use LAN access or PAN over Bluetooth.
>
> One thing you can try is that you switch your language code of your
> Bluetooth device to france and in this case it won't use all 79 channels
> anymore. Then you can put your WLAN card on a frequency which is no
> longer used by Bluetooth. Maybe this helps, but don't ask me how to do
> this in detail.
>
> Regards
>
> Marcel
>
>
--
NEU F?R ALLE - GMX MediaCenter - f?r Fotos, Musik, Dateien...
Fotoalbum, File Sharing, MMS, Multimedia-Gru?, GMX FotoService
Jetzt kostenlos anmelden unter http://www.gmx.net
+++ GMX - die erste Adresse f?r Mail, Message, More! +++
Marcel Holtmann wrote:
> It can be useful for all kind of devices where power consumption is
> essential. Even an iPAQ with a PAN connection can profit from it. The
> Microsoft HID devices make heavy use of sniff mode, before they
> disconnect the ACL link after 12 minutes of idle time. And everyone
> talks about the long battery life time of Bluetooth HID devices, so this
> looks like the right way to reduce power consumption.
I think, in the HID profile, it's the HID client device (the mouse or
whatever) that controls the sniff settings and chooses when to disconnect.
It's the client that has to keep power consumption extremely low to make
its battery last for months. It's the client that has the input from the
sensor (for example) to determine when would be a good time to bring the
link latency down. All the server has to do is enable sniff and let the
client sort it out.
If you're looking at BlueZ HID clients (say BlueZ on a palmtop which
can behave as a HID device for a desktop machine) then you will need
to look at controlling sniff.
However, as you say, for battery powered devices, sniff is generally
a good thing. In Bluetooth, active slaves are required to listen in
every slot. This burns power. Just switching into sniff with a short
interval (say 25 ms - same as the poll period) can have a significant
effect on power consumption. Of course, if you're on a mains powered
machine, or if the power consumption of your Bluetooth device is a
small fraction of your total power consumption, then this is not worth
bothering with. In fact, in these cases, you probably shouldn't do it
and you should let the device at the other end of the link decide what
settings are most profitable for it.
How much power you save depends on the host transport and the host
transport settings. Some scenarios allow us to save more power than
others. I've tried to simplify the description to try and keep it
general rather than too CSR specific but, because I know only the CSR
solution in detail, some of this might not apply to other chipsets.
For all scenarios, even short sniffs can be a significant improvement
over being an active slave. Just allowing the dongle to keep its radio
turned off most of the time could save maybe a factor of two in power
(depending on sniff settings).
For some scenarios, such as bus powered USB dongles and H4 UART dongles
with very high baud rates, this might be the best you can do.
Other scenarios may improve things dramatically, particularly at long
sniff intervals. If the Bluetooth dongle is a self powered USB device
and if you support remote wakeup then suspending it may help.
For UARTs, both with H4 and BCSP, using a lower baud rate might help the
power consumption even on short sniff intervals (of course it will hurt
the data rate)
Using a host transport that supports devices going to sleep - BCSP
is an example - really helps at long sniff intervals (say one second
or more).
The question is how much of a saving do you need? Even flat out,
any Bluetooth radio will be pushed to draw more than 60 mA. An
active, but idle, link will draw less than that. What's the total
power consupmtion of an iPAQ? Is 60 mA a significant fraction? At
what point do we stop caring?
Sometimes the critical factor is not the current consumption of the
Bluetooth dongle, but of the whole system. If you have a situation
where both ends of the link are free to go to sleep, such as with BCSP
or suspended self-powered USB devices, then being able to shut the host
down and wake it up when Bluetooth activity occurs could be a
significant long-term power saving.
Sometimes, what eats most current, on average, is time spent without a
link but being discoverable and/or connectable. Using BCSP will help
compared to H4. Suspending self-powered USB devices may help.
- Steven
--
**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material.
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
**********************************************************************
Hi Steven,
> > this idea is nice and it sounds like a useful feature. But it can't
> > depend on the RFCOMM traffic. It must depend on the ACL traffic and the
> > BlueZ core must handle it.
>
> Yes, sorry. Of course it must depend on ACL traffic not RFCOMM. I
> suspect the easiest way to do it is to advertise an ioctl for this
> feature. I'm not quite sure what the interface should be, but I'm sure
> you can think of something.
I think more of an on/off flag with some additional parameters. And it
maybe described the best with "Automatic Sniff Mode".
> We're getting ahead of ourselves though. We need confirmation from Peter
> that sniff helps the problem. If it doesn't we're wasting our time
> (unless you think the feature is useful for other applications).
It can be useful for all kind of devices where power consumption is
essential. Even an iPAQ with a PAN connection can profit from it. The
Microsoft HID devices make heavy use of sniff mode, before they
disconnect the ACL link after 12 minutes of idle time. And everyone
talks about the long battery life time of Bluetooth HID devices, so this
looks like the right way to reduce power consumption.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann wrote:
> Steven Singer wrote:
>>In theory it would be possible for BlueZ to detect that the rfcomm
>>link has gone quiet (a simple timer from the last packet sent or
>>received) and then automatically switch into sniff mode. [...]
>
> this idea is nice and it sounds like a useful feature. But it can't
> depend on the RFCOMM traffic. It must depend on the ACL traffic and the
> BlueZ core must handle it.
Yes, sorry. Of course it must depend on ACL traffic not RFCOMM. I
suspect the easiest way to do it is to advertise an ioctl for this
feature. I'm not quite sure what the interface should be, but I'm sure
you can think of something.
We're getting ahead of ourselves though. We need confirmation from Peter
that sniff helps the problem. If it doesn't we're wasting our time
(unless you think the feature is useful for other applications).
- Steven
--
**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material.
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
**********************************************************************
Hi Steven,
> A technique that might be useful for both BT 1.1 and 1.2 devices is
> to use sniff. If you chose a relatively long sniff interval (several
> hundred milliseconds) then when the link is idle the Bluetooth devices
> will communicate only once per interval (as opposed to the default of
> about once every 25 ms). If you also chose a fairly high timeout then
> once data starts flowing it should be able to stream smoothly. The
> only disadvantage of this technique is that when data flow stops you
> may get a delay of up to the sniff interval before it can restart.
>
> This should be relatively easy to test. Use the HCI command line tools
> to put the link in sniff mode. I suggest parameters of min_interval =
> 0x200, max_interval = 0x400, attempts = 4, timeout = 40.
>
> In theory it would be possible for BlueZ to detect that the rfcomm
> link has gone quiet (a simple timer from the last packet sent or
> received) and then automatically switch into sniff mode. An advantage
> of this technique is that BlueZ can gradually increase the sniff
> interval the longer the link's been idle. The longer the sniff
> interval, the longer the latency from when either host sends data
> till it can be sent over the air. This would mean that if the link
> was idle only briefly you'd get low latency but if you didn't use
> the link for a while then it'd take a while for data to flow.
this idea is nice and it sounds like a useful feature. But it can't
depend on the RFCOMM traffic. It must depend on the ACL traffic and the
BlueZ core must handle it.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann wrote:
>Peter Bergmann wrote:
>>Does anyone know if bluez supports this "language code switching" ?
> this is done by vendor HCI commands if it exists.
And all requirement for 23 hop sequences has been dropped from the BT
1.2 spec. It's been deprecated in 1.1 for some time.
BT 1.2 does, however, support adaptive frequency hopping (AFH). This
should allow a link between two BT 1.2 devices to detect an active
WLAN network and avoid the frequencies used by the WLAN. Unfortunately,
this doesn't help with BT 1.1 devices (BT 1.1 and 1.2 device will
interoperate, but 1.2 features can't be used on the link).
My suspicion is that if you're streaming data then the WLAN network
is using packets that are several milliseconds long. If they were
10 ms then about one in three packets would be transmitted at the
same time as a Bluetooth transmision (assuming an idle Bluetooth link
with a default poll interval of 25 ms). It may be that as you move
further away, the relative powers of the two devices is such that
you're getting what's called 'front-end overload'. This could happen
if you have a Bluetooth device phsycialy close to a WLAN device
particularly if both devices are communicating over a long distance.
When this happens, it might not matter which frequency the Bluetooth
transmission is on, it can still overload the WLAN receiver.
A technique that might be useful for both BT 1.1 and 1.2 devices is
to use sniff. If you chose a relatively long sniff interval (several
hundred milliseconds) then when the link is idle the Bluetooth devices
will communicate only once per interval (as opposed to the default of
about once every 25 ms). If you also chose a fairly high timeout then
once data starts flowing it should be able to stream smoothly. The
only disadvantage of this technique is that when data flow stops you
may get a delay of up to the sniff interval before it can restart.
This should be relatively easy to test. Use the HCI command line tools
to put the link in sniff mode. I suggest parameters of min_interval =
0x200, max_interval = 0x400, attempts = 4, timeout = 40.
In theory it would be possible for BlueZ to detect that the rfcomm
link has gone quiet (a simple timer from the last packet sent or
received) and then automatically switch into sniff mode. An advantage
of this technique is that BlueZ can gradually increase the sniff
interval the longer the link's been idle. The longer the sniff
interval, the longer the latency from when either host sends data
till it can be sent over the air. This would mean that if the link
was idle only briefly you'd get low latency but if you didn't use
the link for a while then it'd take a while for data to flow.
- Steven
--
**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential
and/or privileged material.
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by
persons or entities other than the intended recipient is
prohibited.
If you received this in error, please contact the sender and
delete the material from any computer.
**********************************************************************
Hi Peter,
> Does anyone know if bluez supports this "language code switching" ?
this is done by vendor HCI commands if it exists.
Regards
Marcel
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users