linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lior David <liord@codeaurora.org>
To: Johannes Berg <johannes@sipsolutions.net>,
	Arend van Spriel <arend.vanspriel@broadcom.com>,
	Luca Coelho <luca@coelho.fi>
Cc: Maya Erez <merez@codeaurora.org>,
	Jouni Malinen <jouni@qca.qualcomm.com>,
	linux-wireless@vger.kernel.org
Subject: Re: nl80211 fine timing measurement support
Date: Thu, 6 Oct 2016 11:41:03 +0300	[thread overview]
Message-ID: <4cf8fdf3-0947-e626-681b-27e2c82cfa9d@codeaurora.org> (raw)
In-Reply-To: <1475573142.5324.41.camel@sipsolutions.net>

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
> 

      reply	other threads:[~2016-10-06  8:41 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-19 17:31 nl80211 fine timing measurement support Lior David
2016-09-19 18:42 ` Arend Van Spriel
2016-09-19 19:41   ` Johannes Berg
2016-09-20  6:39   ` Luca Coelho
2016-09-20 20:57     ` Lior David
2016-10-01  9:56       ` Arend van Spriel
2016-10-04  9:25         ` Johannes Berg
2016-10-06  8:41           ` Lior David [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4cf8fdf3-0947-e626-681b-27e2c82cfa9d@codeaurora.org \
    --to=liord@codeaurora.org \
    --cc=arend.vanspriel@broadcom.com \
    --cc=johannes@sipsolutions.net \
    --cc=jouni@qca.qualcomm.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=luca@coelho.fi \
    --cc=merez@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).