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. >>
