Dear all,
I am looking for information about the compliancy of the ath9k driver
to the EN 300 328 ETSI regulation.
Would someone know if ath9k has already been tested for this regulation?
Is it needed to enable any specific flag in ath9k to guarantee
compliancy to the adaptivity tests described in EN 300 328?
I already tried by applying the patches “ath9k: Fix regulatory
compliance” (http://www.spinics.net/lists/linux-wireless/msg115798.html)
and “ath9k: Fix ETSI compliance for AR9462 2.0”
(http://www.spinics.net/lists/linux-wireless/msg118665.html) but this
does not seem to be sufficient.
Many thanks in advance for any help
Best regards
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
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
<[email protected]> 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
As written before, you need to look at DFS and adaptivity as two independent
mechanisms.
You can disable support for DFS channels in the driver anytime by not setting the
required configuration options. As a result, you won't be able to operate actively
on a DFS channel (monitor mode should still work).
Adaptivity you could start playing without DFS (it is anyway not limited to DFS
channels). At a later stage a working adaptivity module might provide
meta-information helpful to improve DFS processing / management (like: ah, there
is a master already using DFS channel X - assuming that one did a CAC already,
there should be no radar device around). The certification requirements leave
enough room for interpreting those supplemental results in one way or another.
Cheers,
Zefir
On 10/27/2014 07:23 PM, Adrien Decostre wrote:
> 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
> <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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?
What about the CONFIG_ATH9K_DFS_CERTIFIED build options? Do we need it
to enable the detection of 0.5usec. pulses?
Thanks in advance for your answer.
Best regards
Adrien
On Mon, Oct 27, 2014 at 11:43 AM, Zefir Kurtisi
<[email protected]> wrote:
> On 10/24/2014 05:23 PM, Adrien Decostre wrote:
>>
>> I am looking for information about the compliancy of the ath9k driver
>> to the EN 300 328 ETSI regulation.
>>
>> Would someone know if ath9k has already been tested for this regulation?
>>
>> Is it needed to enable any specific flag in ath9k to guarantee
>> compliancy to the adaptivity tests described in EN 300 328?
>>
>>
> The pattern detector currently used in ath was initially developed for ath9k when
> EN 300.328 v1.5.1 was released. It passed the ETSI certification in a German lab
> and the source code (besides moving it up in the tree to be also available for
> 10k) was basically not touched ever since.
>
> I did not track all the DFS requirement changes up to the latest v1.9.1 draft, but
> afaik the sole difference relevant for the detector is the reduction of the
> shortest pulses width in the test pattern specification from 0.7 to 0.5us. With
> that, the chance of the current implementation to pass a v1.8 certification
> depends on ath9k's ability to detect the shorter pulses. I did some initial
> measurements years ago to get a rough picture, which showed that the ath9k is
> losing like 30% of the 0.5us pulses (as compared to .7us).
>
> With the patches you referred, YMMV - you would need to perform thorough
> statistical analyses to get an estimate on whether it would pass.
>
> As for the adaptivity tests, they are not part of DFS (see note in 4.9.1) and
> maybe would best fit within the ACS module
> (http://wireless.kernel.org/en/users/Documentation/acs). The current DFS support
> available in ath9k is limited to bare radar detection, which is enabled through
> CONFIG_CFG80211_CERTIFICATION_ONUS.
>
>
> Cheers,
> Zefir
On 10/24/2014 05:23 PM, Adrien Decostre wrote:
>
> I am looking for information about the compliancy of the ath9k driver
> to the EN 300 328 ETSI regulation.
>
> Would someone know if ath9k has already been tested for this regulation?
>
> Is it needed to enable any specific flag in ath9k to guarantee
> compliancy to the adaptivity tests described in EN 300 328?
>
>
The pattern detector currently used in ath was initially developed for ath9k when
EN 300.328 v1.5.1 was released. It passed the ETSI certification in a German lab
and the source code (besides moving it up in the tree to be also available for
10k) was basically not touched ever since.
I did not track all the DFS requirement changes up to the latest v1.9.1 draft, but
afaik the sole difference relevant for the detector is the reduction of the
shortest pulses width in the test pattern specification from 0.7 to 0.5us. With
that, the chance of the current implementation to pass a v1.8 certification
depends on ath9k's ability to detect the shorter pulses. I did some initial
measurements years ago to get a rough picture, which showed that the ath9k is
losing like 30% of the 0.5us pulses (as compared to .7us).
With the patches you referred, YMMV - you would need to perform thorough
statistical analyses to get an estimate on whether it would pass.
As for the adaptivity tests, they are not part of DFS (see note in 4.9.1) and
maybe would best fit within the ACS module
(http://wireless.kernel.org/en/users/Documentation/acs). The current DFS support
available in ath9k is limited to bare radar detection, which is enabled through
CONFIG_CFG80211_CERTIFICATION_ONUS.
Cheers,
Zefir
Hello Cedric,
As Zefir pointed out the DFS engine is not responsible for the
compatibility with EN 300 328 v1.8.1. To my understanding, this is the
role of the CCA engine.
I think that the key patch is the one provided by Sujith Manoharan at
http://www.spinics.net/lists/linux-wireless/msg118665.html. This patch
is valid for modules using the AR9462. If your module uses another
chipset, you will probably need to apply this patch on the relevant
header file among the series of arxxxx_xpx_initvals.h header files.
To know which header is used by your module, I suppose you need to
check the "hw_version.macVersion" and "hw_version.macRev" read from
the module EEPROM and check the macros defined in
drivers/net/wireless/ath/ath9k/reg.h.
Hope this may help
Adrien
On Wed, Nov 5, 2014 at 9:33 AM, voncken <[email protected]> wrote:
> 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 : [email protected] [mailto:linux-wireless-
>> [email protected]] De la part de Adrien Decostre
>> Envoyé : lundi 27 octobre 2014 19:24
>> À : Zefir Kurtisi
>> Cc : [email protected]; [email protected]
>> 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 <[email protected]>
>> 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 [email protected] More majordomo info at
>> http://vger.kernel.org/majordomo-info.html
>
Hello Zefir,
Thanks a lot for this last precision.
It is now clear to me that the adaptivity mechanism required by EN 300
328 v1.8.1 is handled by the CCA algorithm.
Best regards
Adrien
On Thu, Oct 30, 2014 at 1:55 PM, Zefir Kurtisi
<[email protected]> wrote:
> As written before, you need to look at DFS and adaptivity as two independent
> mechanisms.
>
> You can disable support for DFS channels in the driver anytime by not setting the
> required configuration options. As a result, you won't be able to operate actively
> on a DFS channel (monitor mode should still work).
>
> Adaptivity you could start playing without DFS (it is anyway not limited to DFS
> channels). At a later stage a working adaptivity module might provide
> meta-information helpful to improve DFS processing / management (like: ah, there
> is a master already using DFS channel X - assuming that one did a CAC already,
> there should be no radar device around). The certification requirements leave
> enough room for interpreting those supplemental results in one way or another.
>
>
> Cheers,
> Zefir
>
> On 10/27/2014 07:23 PM, Adrien Decostre wrote:
>> 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
>> <[email protected]> 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 [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
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 : [email protected] [mailto:linux-wireless-
> [email protected]] De la part de Adrien Decostre
> Envoyé : lundi 27 octobre 2014 19:24
> À : Zefir Kurtisi
> Cc : [email protected]; [email protected]
> 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 <[email protected]>
> 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 [email protected] More majordomo info at
> http://vger.kernel.org/majordomo-info.html