Hi,
We have come across a headset (HTC M200) that does not send out a
sniff mode request when in idle. Our Bluez based stack also does not
send a sniff mode request, so we sit in a higher power state that
necessary. (20mA instead of 1mA).
Some quick research suggests that we would need to send HCI Sniff Mode
Command (OCF 0x03) to initiate sniff mode, and that this is not yet
done in the Bluez code base. We do send the HCI Write Default Link
Policy Settings Command but, as I understand, this is only applied to
incoming sniff mode requests by the link manager and will not initiate
an LMP sniff request.
We compared to two non-bluez mobile stacks and found the other phones
did automatically initiate an LMP sniff mode request.
Is there a reason for Bluez not automatically sending HCI Sniff Mode
Command, or is it just a case of no-one getting around to hitting the
problem / implementing a fix? Or have I missed something simple?
Cheers,
Nick
On Mon, Feb 16, 2009 at 6:37 PM, Marcel Holtmann <[email protected]> wrote:
> Hi Nick,
>
>> We have come across a headset (HTC M200) that does not send out a
>> sniff mode request when in idle. Our Bluez based stack also does not
>> send a sniff mode request, so we sit in a higher power state that
>> necessary. (20mA instead of 1mA).
>>
>> Some quick research suggests that we would need to send HCI Sniff Mode
>> Command (OCF 0x03) to initiate sniff mode, and that this is not yet
>> done in the Bluez code base. We do send the HCI Write Default Link
>> Policy Settings Command but, as I understand, this is only applied to
>> incoming sniff mode requests by the link manager and will not initiate
>> an LMP sniff request.
>>
>> We compared to two non-bluez mobile stacks and found the other phones
>> did automatically initiate an LMP sniff mode request.
>>
>> Is there a reason for Bluez not automatically sending HCI Sniff Mode
>> Command, or is it just a case of no-one getting around to hitting the
>> problem / implementing a fix? Or have I missed something simple?
>
> actually BlueZ has automatically sniff mode since a long-long time ago.
> It also would do sniff-subrate in case of Bluetooth 2.1 modules. However
> you have to enable it since by default it is off.
>
> Check /sys/class/bluetooth/hci0 for idle_timeout, sniff_max_interval and
> sniff_min_interval. Use idle_timeout and the others to control the
> interval values.
>
Ah, thank you! I was looking on the userspace side.
Nick
Hi Nick,
> We have come across a headset (HTC M200) that does not send out a
> sniff mode request when in idle. Our Bluez based stack also does not
> send a sniff mode request, so we sit in a higher power state that
> necessary. (20mA instead of 1mA).
>
> Some quick research suggests that we would need to send HCI Sniff Mode
> Command (OCF 0x03) to initiate sniff mode, and that this is not yet
> done in the Bluez code base. We do send the HCI Write Default Link
> Policy Settings Command but, as I understand, this is only applied to
> incoming sniff mode requests by the link manager and will not initiate
> an LMP sniff request.
>
> We compared to two non-bluez mobile stacks and found the other phones
> did automatically initiate an LMP sniff mode request.
>
> Is there a reason for Bluez not automatically sending HCI Sniff Mode
> Command, or is it just a case of no-one getting around to hitting the
> problem / implementing a fix? Or have I missed something simple?
actually BlueZ has automatically sniff mode since a long-long time ago.
It also would do sniff-subrate in case of Bluetooth 2.1 modules. However
you have to enable it since by default it is off.
Check /sys/class/bluetooth/hci0 for idle_timeout, sniff_max_interval and
sniff_min_interval. Use idle_timeout and the others to control the
interval values.
Regards
Marcel