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
>>> 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 .
> 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, 220.127.116.11). 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 ,
the actual implementation is still under internal review so not yet