[PATCH] ath: support new FCC DFS Radar Type 1

[Peter Oh]

On 03/02/2015 05:29 PM, Peter Oh wrote:
>
> On 02/27/2015 02:45 AM, Zefir Kurtisi wrote:
>> On 02/25/2015 11:17 PM, Peter Oh wrote:
>>> Add support for new FCC DFS rules released on August 14, 2014.
>>> FCC has added a new radar type named Radar Type 1 and original
>>> Radar Type 1 is renamed to Radar Type 0 in consequence.
>>> In fact, the type ID does nothing to functionalities.
>>> In other words, even if we re-order the IDs, DFS detection will
>>> work as well, but we give the ID with matching to FCC doc.
>>>
>>> By adding this support, the drivers using this DFS function are
>>> able to support both of old and new FCC DFS rules simultaneously
>>> without any other changes.
>>>
>>> [...]
>> Peter,
>>
>> while trying to solve detection of the special FCC type 1 radar pattern
>> with the
>> pri_detector at hand is a valid approach, it is neither suitable nor
>> effective.
>>
>> It is not suitable because in the way you do, it will not reach the
>> required
>> detection probability required to pass certification. This is because 
>> you
>> take the
>> very first pri to configure its detector specs, which is way too
>> optimistic. You
>> have to consider that the detector must be able to detect properly with
>> only 50%
>> of the pulses seen. In this particular case, you would ignore a lot of
>> type 1
>> patterns, since the resulting visibility gap causes temporary false PRIs
>> that
>> won't be considered. You might want to have a look on my slides 15ff in
>> [1] for an
>> idea what needs to be handled.
>>
>> Generally, to reach the detection probability requirements, the 
>> design of
>> the
>> PRI-detector at hand follows a full-coverage search with fast 
>> cancellation
>> approach. For that, it allows collecting potential pattern candidates 
>> and
>> a
>> posteriori correction of initial assumptions. It is specifically 
>> targeting
>> at
>> radar patterns defined through PRI-ranges, where constant PRI-ranges are
>> supported
>> as special cases by setting the same values for pri_min and pri_max 
>> (as is
>> done
>> for pattern 0). With support for PRI-ranges and unique PRIs, everything
>> needed to
>> detect pattern 1 is there, but defining it as a PRI-range over all the
>> unique 23
>> PRIs is the wrong way.
>>
>> The correct approach is more simple, robust, and efficient: define all
>> those 23
>> unique PRIs as sub-patterns for type 1 with individual specs. Would look
>> like:
>>
>> #define TYPE1_PPB(X) ((19 * 100000) / (36 * X))
>> static const struct radar_detector_specs fcc_radar_ref_types[] = {
>>     FCC_PATTERN(0, 0, 1, 1428, 1428, 1, 18, false),
>>     FCC_PATTERN(101, 0, 1, 518, 518, 1, TYPE1_PPB(518), false),
>>     FCC_PATTERN(102, 0, 1, ..., ..., 1, ..., false),
>>     [...],
>>     FCC_PATTERN(123, 0, 1, 3066, 3066, 1, TYPE1_PPB(3066), false),
>>     FCC_PATTERN(2, 0, 5, 150, 230, 1, 23, false),
>>     FCC_PATTERN(3, 6, 10, 200, 500, 1, 16, false),
>>     FCC_PATTERN(4, 11, 20, 200, 500, 1, 12, false),
>>     FCC_PATTERN(5, 50, 100, 1000, 2000, 1, 1, true),
>>     FCC_PATTERN(6, 0, 1, 333, 333, 1, 9, false),
>> };
>>
I just remembered why I choose dynamic settings of PRI and PPB instead 
of the simple macro definition.
It's because of Test B requirement on Type 1 radar.
Test B: 15 unique PRI values randomly selected within the range of 
518-3066 usec, with a minimum increment of 1 usec, excluding PRI values 
selected in Test A.
Minimum number of trials on type 1 radar is 30 and 15 trials are 
supposed to use Test B which selects any numbers between 518~3066 except 
used at Test A stage.
There will be 84 PPBs within the PRI range and I thought defining all 
these numbers are not preferable.
So I'd like to hear your feedback on this.
>>
>> Hope it helps, and sorry I didn't do myself, but so far we are only
>> working in
>> ETSI domains and ignored FCC completely.
> Thank you Zefir for the advice and I'll review and update the code 
> based on your comment.
>>
>> Cheers,
>> Zefir
>>
>> [1]
>> http://linuxwireless.sipsolutions.net/attachments/en/developers/DFS/Vancou 
>>
>> ver2011-Slides-DFS.pdf
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
> Thanks,
> Peter
>
> _______________________________________________
> ath10k mailing list
> ath10k at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
Regards,
Peter