LE New PHYs implementation

LE New PHYs implementation

[Jaganath K]

Hi,

Are there any plans to implement LE new PHYs defined in 5.0?

I think the first step would be to define the kernel API for setting new PHY

How abt implementing mgmt command or l2cap socket option for "Set PHY"
and mgmt event for "PHY Update".

I suppose socket option for "Set PHY" would be more convenient for
applications especially for L2CAP CoC usecases like OTS.

If multiple fds (apps) sets different PHYs then priority should be in
the order of Coded, 2M, 1M since long range would not break 2M use
cases (data rate will be affected) where as other way around might not
work as expected.

Any leads would be appreciated.

Thanks,
Jaganath

Re: LE New PHYs implementation

[Emil Lenngren]

There should be options when scanning devices as well to scan on the
LE Coded PHY. However when scanning you specify as a bitmask which
PHYs you want to scan on so there it's easier if there are multiple
apps that want to scan on different PHYs.

2017-09-01 9:09 GMT+02:00 Jaganath K <jaganath.k.os@gmail.com>:
> Hi,
>
> Are there any plans to implement LE new PHYs defined in 5.0?
>
> I think the first step would be to define the kernel API for setting new PHY
>
> How abt implementing mgmt command or l2cap socket option for "Set PHY"
> and mgmt event for "PHY Update".
>
> I suppose socket option for "Set PHY" would be more convenient for
> applications especially for L2CAP CoC usecases like OTS.
>
> If multiple fds (apps) sets different PHYs then priority should be in
> the order of Coded, 2M, 1M since long range would not break 2M use
> cases (data rate will be affected) where as other way around might not
> work as expected.
>
> Any leads would be appreciated.
>
> Thanks,
> Jaganath
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: LE New PHYs implementation

[Marcel Holtmann]

Hi Jaganath,

> Are there any plans to implement LE new PHYs defined in 5.0?
> 
> I think the first step would be to define the kernel API for setting new PHY
> 
> How abt implementing mgmt command or l2cap socket option for "Set PHY"
> and mgmt event for "PHY Update".
> 
> I suppose socket option for "Set PHY" would be more convenient for
> applications especially for L2CAP CoC usecases like OTS.
> 
> If multiple fds (apps) sets different PHYs then priority should be in
> the order of Coded, 2M, 1M since long range would not break 2M use
> cases (data rate will be affected) where as other way around might not
> work as expected.
> 
> Any leads would be appreciated.

I was thinking about using bdaddr_type for it or introducing a phy_type. This is not yet fully thought through. It needs a bit of figuring out what would work best. In addition we also need proper reporting in scan reports via mgmt. There either bdaddr_type or maybe an extra flags field to indicate LE coded.

Regards

Marcel

Re: LE New PHYs implementation

[Jaganath K]

Hi Marcel,

On Fri, Sep 1, 2017 at 6:02 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Jaganath,
>
>> Are there any plans to implement LE new PHYs defined in 5.0?
>>
>> I think the first step would be to define the kernel API for setting new PHY
>>
>> How abt implementing mgmt command or l2cap socket option for "Set PHY"
>> and mgmt event for "PHY Update".
>>
>> I suppose socket option for "Set PHY" would be more convenient for
>> applications especially for L2CAP CoC usecases like OTS.
>>
>> If multiple fds (apps) sets different PHYs then priority should be in
>> the order of Coded, 2M, 1M since long range would not break 2M use
>> cases (data rate will be affected) where as other way around might not
>> work as expected.
>>
>> Any leads would be appreciated.
>
> I was thinking about using bdaddr_type for it or introducing a phy_type. This is not yet fully thought through. It needs a bit of figuring out what would work best.

If we use bdaddr_type, i think we would need combinations to use it
with PUBLIC and RANDOM. So i think introducing phy_type is better.
Can we add phy_type in struct mgmt_addr_info as a bit field?
It can be used in Socket Connect for phy preference and
mgmt_device_connected event to inform user abt the connected phy.

>In addition we also need proper reporting in scan reports via mgmt. There either bdaddr_type or maybe an extra flags field to indicate LE coded.

I suppose adding extra flags is better. We can have new DEV_FOUND
flags to inform abt primary and secondary phys of the scan report
Also Is it Ok to always scan on LE coded  as well, if the controller supports?

Thanks,
Jaganath