Hi Johannes,
We are working on adding indoor location support to the wil6210 11ad driver. This includes fine timing measurement (FTM) as well as something we call angle of arrival (AOA) which measures azimuth and elevation.
Initially we implemented it internally using vendor commands but we would like to upstream it using standard nl80211 API.
I noticed a patch you sent some time ago (https://patchwork.kernel.org/patch/7790701/) for adding fine timing measurement support to nl80211, it looks like a good baseline though we do have few issues with it... However I did not see any comments or response on this patch. Can you please update if you plan on eventually submitting this patch?
Thanks,
Lior
On Mon, 2016-09-19 at 20:42 +0200, Arend Van Spriel wrote:
>
> On 19-9-2016 19:31, Lior David wrote:
> >
> > Hi Johannes,
> >
> > We are working on adding indoor location support to the wil6210
> > 11ad driver. This includes fine timing measurement (FTM) as well as
> > something we call angle of arrival (AOA) which measures azimuth and
> > elevation.
> > Initially we implemented it internally using vendor commands but we
> > would like to upstream it using standard nl80211 API.
> > I noticed a patch you sent some time ago (https://patchwork.kernel.
> > org/patch/7790701/) for adding fine timing measurement support to
> > nl80211, it looks like a good baseline though we do have few issues
> > with it... However I did not see any comments or response on this
> > patch. Can you please update if you plan on eventually submitting
> > this patch?
>
> You can find several FTM related patches in backport-iwlwifi repo on
> kernel.org. See link to git log of nl80211.h there [1].
We have a full FTM implementation in our internal tree (which is
published in the URL Arend provided) and we are currently working on
cleaning it up for upstream submission. You should see patches from us
this week.
--
Cheers,
Luca.
> > However I did not see any comments or response on this
> > patch. Can you please update if you plan on eventually submitting
> > this patch?
>
> You can find several FTM related patches in backport-iwlwifi repo on
> kernel.org. See link to git log of nl80211.h there [1].
>
You can find things there, but they might not be the most organized
always :)
Anyway, I think after Luca is handling the current round of NaN
submission he'll have the cycles to deal with FTM - I'll let him
comment. For all I care, they can also run in parallel, but that might
be more difficult for him.
johannes
On 19-9-2016 19:31, Lior David wrote:
> Hi Johannes,
>
> We are working on adding indoor location support to the wil6210 11ad driver. This includes fine timing measurement (FTM) as well as something we call angle of arrival (AOA) which measures azimuth and elevation.
> Initially we implemented it internally using vendor commands but we would like to upstream it using standard nl80211 API.
> I noticed a patch you sent some time ago (https://patchwork.kernel.org/patch/7790701/) for adding fine timing measurement support to nl80211, it looks like a good baseline though we do have few issues with it... However I did not see any comments or response on this patch. Can you please update if you plan on eventually submitting this patch?
You can find several FTM related patches in backport-iwlwifi repo on
kernel.org. See link to git log of nl80211.h there [1].
Regards,
Arend
[1]
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/backport-iwlwifi.git/log/include/uapi/linux/nl80211.h
On 9/20/2016 9:39 AM, Luca Coelho wrote:
> On Mon, 2016-09-19 at 20:42 +0200, Arend Van Spriel wrote:
>>
>> On 19-9-2016 19:31, Lior David wrote:
>>>
>>> Hi Johannes,
>>>
>>> We are working on adding indoor location support to the wil6210
>>> 11ad driver. This includes fine timing measurement (FTM) as well as
>>> something we call angle of arrival (AOA) which measures azimuth and
>>> elevation.
>>> Initially we implemented it internally using vendor commands but we
>>> would like to upstream it using standard nl80211 API.
>>> I noticed a patch you sent some time ago (https://patchwork.kernel.
>>> org/patch/7790701/) for adding fine timing measurement support to
>>> nl80211, it looks like a good baseline though we do have few issues
>>> with it... However I did not see any comments or response on this
>>> patch. Can you please update if you plan on eventually submitting
>>> this patch?
>>
>> You can find several FTM related patches in backport-iwlwifi repo on
>> kernel.org. See link to git log of nl80211.h there [1].
>
> We have a full FTM implementation in our internal tree (which is
> published in the URL Arend provided) and we are currently working on
> cleaning it up for upstream submission. You should see patches from us
> this week.
>
That's great to hear, thanks :-)
I reviewed your FTM nl80211 API and have some comments. I can send these
comments once you send the cleaned up patch (most are small issues), but there
is one issue I would like to raise in advance:
In the measurement response you report the final calculated RTT (is this
for each burst or calculated from all bursts?). Our implementation
reports the raw measurement results (t1, t2, t3, t4 for each measurement
as well as TOD and TOA errors at responder and initiator as defined in IEEE
P802.11-REVmc/D7.0, 9.6.8.33). Reporting the final RTT does have benefits, so I
checked with our location framework developers. The general consensus is they
prefer to get the raw results, mainly because there are some useful analysis
algorithms they can run, and in addition the firmware may not be strong enough
to perform the calculations for deriving the final RTT (it could be done in the
driver but I don't think this is a proper place for it). Maybe we should
provide option for reporting both raw and RTT results where drivers can
support either or both?
For reference, we have also implemented FTM internally using vendor
commands. The vendor commands API that we defined can be seen at [1],
the actual implementation is still under internal review so not yet
published.
Thanks,
Lior
[1] http://w1.fi/cgit/hostap/commit/?id=fcd85d9a3f2d9d63d0fa57e93446ad467db75b23
> --
> Cheers,
> Luca.
>
On 20-09-16 22:57, Lior David wrote:
> On 9/20/2016 9:39 AM, Luca Coelho wrote:
>> On Mon, 2016-09-19 at 20:42 +0200, Arend Van Spriel wrote:
>>>
>>> On 19-9-2016 19:31, Lior David wrote:
>>>>
>>>> Hi Johannes,
>>>>
>>>> We are working on adding indoor location support to the wil6210
>>>> 11ad driver. This includes fine timing measurement (FTM) as well as
>>>> something we call angle of arrival (AOA) which measures azimuth and
>>>> elevation.
>>>> Initially we implemented it internally using vendor commands but we
>>>> would like to upstream it using standard nl80211 API.
>>>> I noticed a patch you sent some time ago (https://patchwork.kernel.
>>>> org/patch/7790701/) for adding fine timing measurement support to
>>>> nl80211, it looks like a good baseline though we do have few issues
>>>> with it... However I did not see any comments or response on this
>>>> patch. Can you please update if you plan on eventually submitting
>>>> this patch?
>>>
>>> You can find several FTM related patches in backport-iwlwifi repo on
>>> kernel.org. See link to git log of nl80211.h there [1].
>>
>> We have a full FTM implementation in our internal tree (which is
>> published in the URL Arend provided) and we are currently working on
>> cleaning it up for upstream submission. You should see patches from us
>> this week.
>>
> That's great to hear, thanks :-)
> I reviewed your FTM nl80211 API and have some comments. I can send these
> comments once you send the cleaned up patch (most are small issues), but there
> is one issue I would like to raise in advance:
> In the measurement response you report the final calculated RTT (is this
> for each burst or calculated from all bursts?). Our implementation
> reports the raw measurement results (t1, t2, t3, t4 for each measurement
> as well as TOD and TOA errors at responder and initiator as defined in IEEE
> P802.11-REVmc/D7.0, 9.6.8.33). Reporting the final RTT does have benefits, so I
> checked with our location framework developers. The general consensus is they
> prefer to get the raw results, mainly because there are some useful analysis
> algorithms they can run, and in addition the firmware may not be strong enough
> to perform the calculations for deriving the final RTT (it could be done in the
> driver but I don't think this is a proper place for it). Maybe we should
> provide option for reporting both raw and RTT results where drivers can
> support either or both?
If raw results are mainly used for analysis algorithms how about
providing raw measurement data through debugfs. May even consider adding
rtt calculation in cfg80211/mac80211 for drivers that choose to provide
raw measurement data and still only report final RTT in nl80211 api.
Regards,
Arend
> For reference, we have also implemented FTM internally using vendor
> commands. The vendor commands API that we defined can be seen at [1],
> the actual implementation is still under internal review so not yet
> published.
>
> Thanks,
> Lior
>
> [1] http://w1.fi/cgit/hostap/commit/?id=fcd85d9a3f2d9d63d0fa57e93446ad467db75b23
>
>
>> --
>> Cheers,
>> Luca.
>>
> If raw results are mainly used for analysis algorithms how about
> providing raw measurement data through debugfs. May even consider
> adding rtt calculation in cfg80211/mac80211 for drivers that choose
> to provide raw measurement data and still only report final RTT in
> nl80211 api.
>
I think the "analysis algorithms" in this case are what actually gives
you the distance value.
However, I don't think we should accept that everybody wants to run
their proprietary algorithms on top and expose only the values needed
for those. That makes the drivers only usable with additional
proprietary software, which may even be incompatible with the GPL.
If the algorithms are in the device, then we can expose the final
results, and that's most useful for applications in the API.
If they're not, then we need to expose something that can be used
without additional proprietary and device-specific algorithms.
If those algorithms cannot be run in the device, then we should put
them into the driver instead.
johannes
On 10/4/2016 12:25 PM, Johannes Berg wrote:
>
>> If raw results are mainly used for analysis algorithms how about
>> providing raw measurement data through debugfs. May even consider
>> adding rtt calculation in cfg80211/mac80211 for drivers that choose
>> to provide raw measurement data and still only report final RTT in
>> nl80211 api.
>>
>
> I think the "analysis algorithms" in this case are what actually gives
> you the distance value.
>
> However, I don't think we should accept that everybody wants to run
> their proprietary algorithms on top and expose only the values needed
> for those. That makes the drivers only usable with additional
> proprietary software, which may even be incompatible with the GPL.
>
> If the algorithms are in the device, then we can expose the final
> results, and that's most useful for applications in the API.
>
> If they're not, then we need to expose something that can be used
> without additional proprietary and device-specific algorithms.
>
> If those algorithms cannot be run in the device, then we should put
> them into the driver instead.
>
After further internal discussion, we will be ok with reporting only the final
RTT. In our current internal implementation, the location framework in user
space gets the raw results (t1,t2,t3,t4) and does an algorithm which includes
drift compensation in order to derive the final RTT. We will need to move this
down to the driver, not trivial but can be done.
However I think there might be platforms where you might need a more complicated
algorithm which will need to run in user space so for the long term we may want
to consider an option to report the raw results. The raw results are definitely
important for debugging but Using debugfs is problematic because it is difficult
to synchronize with the measurement session, especially if you have multiple
bursts. It is probably best to report is as part of the session, together/in
place of the RTT for each burst.
Thanks,
Lior
> johannes
>