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
next prev 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).