linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "voncken" <cedric.voncken@acksys.fr>
To: "'Adrien Decostre'" <ad.decostre@gmail.com>,
	"'Zefir Kurtisi'" <zefir.kurtisi@neratec.com>
Cc: <linux-wireless@vger.kernel.org>, <ath9k-devel@lists.ath9k.org>
Subject: RE: Questions regarding ath9k and new EN 300 328 regulation
Date: Wed, 5 Nov 2014 09:33:45 +0100	[thread overview]
Message-ID: <03fc01cff8d3$38bdbb60$aa393220$@acksys.fr> (raw)
In-Reply-To: <CAOtFK_VG0Z3EkAfYNjiQGdcUp03Pa2SMP+-6cfdJMMT8Rg4Y6A@mail.gmail.com>

	Hi Adrien, 

	In the file driver/net/wireless/ath/dfs_pattern_detector.c a comment specify the dfs detector is compliant with EN300 328 1.5.1.
	Is it also compatible with E300 328 v1.8.1 ?

	Thanks for your reply.

	Cedric voncken.

> -----Message d'origine-----
> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] De la part de Adrien Decostre
> Envoyé : lundi 27 octobre 2014 19:24
> À : Zefir Kurtisi
> Cc : linux-wireless@vger.kernel.org; ath9k-devel@lists.ath9k.org
> Objet : Re: Questions regarding ath9k and new EN 300 328 regulation
> 
> Dear Zefir,
> 
> Thanks a lot for these precisions, This makes thing more clear.
> 
> There is still one thing unclear to me. If we do not consider working on the
> DFS channels and that we only want to operate on channels 36, 40, 44 and 48
> in EU. Do we still need to enable DFS flags in ath9k to comply with EN 300
> 328 v1.8.1. I mean, is the same pulse detector algorithm used for DFS and for
> the adaptivity tests on channels 36 to 48?
> 
> Many thanks in advance for your answer.
> 
> Best regards
> 
> Adrien
> 
> 
> On Mon, Oct 27, 2014 at 3:50 PM, Zefir Kurtisi <zefir.kurtisi@neratec.com>
> wrote:
> > On 10/27/2014 03:18 PM, Adrien Decostre wrote:
> >> Hello Zefir,
> >>
> >> Thanks a lot for your answer. This helps me a lot.
> >> If I correctly understand, the ability of ath9k to detect all pulses
> >> may also depend of the platform performances. So on an embedded
> >> platform with limited performances, we may observe more pulses losses
> >> than on a more powerful platform. Is this a right statement?
> >>
> > No, there is no bottleneck in the platform performance. Presumed radar
> > pulses are reported as RX_ERROR descriptors and even lower end
> > embedded systems are able to handle the load. What makes the
> > difference with the minimum pulse width is the chip DFS engine's
> > ability to isolate and identify very short spikes as potential radar
> pulses.
> >
> > This goes very deeply into material I had available under NDA while
> > implementing the DFS support for ath9k. If you intend to work on that
> > topic, I encourage you to contact the folks at QCA and join their 'NDA
> > for Developers' program. The document you want to read is 'Baseband DFS 2
> (Radar) Micro-Architecture'.
> >
> >> What about the CONFIG_ATH9K_DFS_CERTIFIED build options? Do we need
> >> it to enable the detection of 0.5usec. pulses?
> >>
> > Yes, this driver specific flag (also available for 10k) you need to
> > set to get the DFS detector built (not related to pulse width). It
> > essentially shifts the responsibility of the product working in restricted
> bands to you / the manufacturer.
> >
> >
> >> Thanks in advance for your answer.
> >>
> >> Best regards
> >>
> >> Adrien
> >>
> >
> > Good Luck,
> > Zefir
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html


  parent reply	other threads:[~2014-11-05  8:34 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-24 15:23 Questions regarding ath9k and new EN 300 328 regulation Adrien Decostre
2014-10-27 10:43 ` Zefir Kurtisi
2014-10-27 14:18   ` Adrien Decostre
2014-10-27 14:50     ` Zefir Kurtisi
2014-10-27 18:23       ` Adrien Decostre
2014-10-30 12:55         ` Zefir Kurtisi
2014-11-05  9:07           ` Adrien Decostre
2014-11-05  8:33         ` voncken [this message]
2014-11-05  9:35           ` Adrien Decostre

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='03fc01cff8d3$38bdbb60$aa393220$@acksys.fr' \
    --to=cedric.voncken@acksys.fr \
    --cc=ad.decostre@gmail.com \
    --cc=ath9k-devel@lists.ath9k.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=zefir.kurtisi@neratec.com \
    /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).