* [PATCH 1/2] ath: define JP DFS patterns separated from FCC
@ 2015-03-31 18:16 ` Peter Oh
0 siblings, 0 replies; 7+ messages in thread
From: Peter Oh @ 2015-03-31 18:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
Separate Japan's DFS pattern from FCC to control PPB threshold.
Currently all the radar detectors use the same threshold rate at
50%, but it's not able to achieve if data traffic rate is higher
than 40% because WLAN baseband used by ath9k and ath10k often fails
detecting radar pulses, so that SW cannot get enough radar reports
to achieve the rate.
Since Japan's W53 band requires 50% data traffic during its DFS
test we need to apply different threshold rate than others on it.
Hence define its own pattern to give flexibility to threshold rate.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 27 ++++++++++++++++---------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
index b1de8c6..8d1e082 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -42,6 +42,7 @@ struct radar_types {
/* percentage on ppb threshold to trigger detection */
#define MIN_PPB_THRESH 50
#define PPB_THRESH(PPB) ((PPB * MIN_PPB_THRESH + 50) / 100)
+#define PPB_THRESH_JP(PPB, RATE) ((PPB * RATE + 100 - RATE) / 100)
#define PRF2PRI(PRF) ((1000000 + PRF / 2) / PRF)
/* percentage of pulse width tolerance */
#define WIDTH_TOLERANCE 5
@@ -96,17 +97,23 @@ static const struct radar_types fcc_radar_types = {
.radar_types = fcc_radar_ref_types,
};
-#define JP_PATTERN FCC_PATTERN
+#define JP_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB, RATE, CHIRP) \
+{ \
+ ID, WIDTH_LOWER(WMIN), WIDTH_UPPER(WMAX), \
+ PMIN - PRI_TOLERANCE, \
+ PMAX * PRF + PRI_TOLERANCE, PRF, PPB * PRF, \
+ PPB_THRESH_JP(PPB, RATE), PRI_TOLERANCE, CHIRP \
+}
static const struct radar_detector_specs jp_radar_ref_types[] = {
- JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, false),
- JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, false),
- JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, false),
- JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, false),
- JP_PATTERN(4, 0, 5, 150, 230, 1, 23, false),
- JP_PATTERN(5, 6, 10, 200, 500, 1, 16, false),
- JP_PATTERN(6, 11, 20, 200, 500, 1, 12, false),
- JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, false),
- JP_PATTERN(5, 0, 1, 333, 333, 1, 9, false),
+ JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, 50, false),
+ JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, 50, false),
+ JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, 50, false),
+ JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, 50, false),
+ JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false),
+ JP_PATTERN(5, 6, 10, 200, 500, 1, 16, 50, false),
+ JP_PATTERN(6, 11, 20, 200, 500, 1, 12, 50, false),
+ JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, 50, false),
+ JP_PATTERN(5, 0, 1, 333, 333, 1, 9, 50, false),
};
static const struct radar_types jp_radar_types = {
--
1.9.1
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH 2/2] ath: lower JP W53 band DFS detection threshold around 30%
2015-03-31 18:16 ` Peter Oh
@ 2015-03-31 18:16 ` Peter Oh
-1 siblings, 0 replies; 7+ messages in thread
From: Peter Oh @ 2015-03-31 18:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
Japan's W53 band requires 50% data traffic during its DFS test,
but WLAN baseband used by ath9k and ath10k is not able to achieve
current threshold rate, 50%, under the data traffic rate.
In other words, HW occasionally fails detecting radar pulses,
so that SW cannot get enough radar reports to achieve the rate.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
index 8d1e082..7ad1932 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -105,8 +105,8 @@ static const struct radar_types fcc_radar_types = {
PPB_THRESH_JP(PPB, RATE), PRI_TOLERANCE, CHIRP \
}
static const struct radar_detector_specs jp_radar_ref_types[] = {
- JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, 50, false),
- JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, 50, false),
+ JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, 29, false),
+ JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, 29, false),
JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, 50, false),
JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, 50, false),
JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false),
--
1.9.1
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH 2/2] ath: lower JP W53 band DFS detection threshold around 30%
@ 2015-03-31 18:16 ` Peter Oh
0 siblings, 0 replies; 7+ messages in thread
From: Peter Oh @ 2015-03-31 18:16 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
Japan's W53 band requires 50% data traffic during its DFS test,
but WLAN baseband used by ath9k and ath10k is not able to achieve
current threshold rate, 50%, under the data traffic rate.
In other words, HW occasionally fails detecting radar pulses,
so that SW cannot get enough radar reports to achieve the rate.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
---
drivers/net/wireless/ath/dfs_pattern_detector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
index 8d1e082..7ad1932 100644
--- a/drivers/net/wireless/ath/dfs_pattern_detector.c
+++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
@@ -105,8 +105,8 @@ static const struct radar_types fcc_radar_types = {
PPB_THRESH_JP(PPB, RATE), PRI_TOLERANCE, CHIRP \
}
static const struct radar_detector_specs jp_radar_ref_types[] = {
- JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, 50, false),
- JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, 50, false),
+ JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, 29, false),
+ JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, 29, false),
JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, 50, false),
JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, 50, false),
JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false),
--
1.9.1
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH 1/2] ath: define JP DFS patterns separated from FCC
2015-03-31 18:16 ` Peter Oh
@ 2015-03-31 23:17 ` Julian Calaby
-1 siblings, 0 replies; 7+ messages in thread
From: Julian Calaby @ 2015-03-31 23:17 UTC (permalink / raw)
To: Peter Oh; +Cc: ath10k, linux-wireless
Hi Peter,
Two very minor points:
On Wed, Apr 1, 2015 at 5:16 AM, Peter Oh <poh@qca.qualcomm.com> wrote:
> Separate Japan's DFS pattern from FCC to control PPB threshold.
>
> Currently all the radar detectors use the same threshold rate at
> 50%, but it's not able to achieve if data traffic rate is higher
> than 40% because WLAN baseband used by ath9k and ath10k often fails
> detecting radar pulses, so that SW cannot get enough radar reports
> to achieve the rate.
>
> Since Japan's W53 band requires 50% data traffic during its DFS
> test we need to apply different threshold rate than others on it.
> Hence define its own pattern to give flexibility to threshold rate.
>
> Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
> ---
> drivers/net/wireless/ath/dfs_pattern_detector.c | 27 ++++++++++++++++---------
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
> index b1de8c6..8d1e082 100644
> --- a/drivers/net/wireless/ath/dfs_pattern_detector.c
> +++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
> @@ -42,6 +42,7 @@ struct radar_types {
> /* percentage on ppb threshold to trigger detection */
> #define MIN_PPB_THRESH 50
> #define PPB_THRESH(PPB) ((PPB * MIN_PPB_THRESH + 50) / 100)
> +#define PPB_THRESH_JP(PPB, RATE) ((PPB * RATE + 100 - RATE) / 100)
These two PPB_THRESH defines are essentially doing the same math.
Would it make sense to define them as:
#define MIN_PPB_THRESH 50
#define PPB_THRESH_RATE(PPB, RATE) ((PPB * RATE + 100 - RATE) / 100)
#define PPB_THRESH(PPB) PPB_THRESH_RATE(PPB, MIN_PPB_THRESH)
In case some other country defines a specific rate for their DFS patterns?
> #define PRF2PRI(PRF) ((1000000 + PRF / 2) / PRF)
> /* percentage of pulse width tolerance */
> #define WIDTH_TOLERANCE 5
> @@ -96,17 +97,23 @@ static const struct radar_types fcc_radar_types = {
> .radar_types = fcc_radar_ref_types,
> };
>
> -#define JP_PATTERN FCC_PATTERN
> +#define JP_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB, RATE, CHIRP) \
> +{ \
> + ID, WIDTH_LOWER(WMIN), WIDTH_UPPER(WMAX), \
> + PMIN - PRI_TOLERANCE, \
> + PMAX * PRF + PRI_TOLERANCE, PRF, PPB * PRF, \
> + PPB_THRESH_JP(PPB, RATE), PRI_TOLERANCE, CHIRP \
> +}
> static const struct radar_detector_specs jp_radar_ref_types[] = {
> - JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, false),
> - JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, false),
> - JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, false),
> - JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, false),
> - JP_PATTERN(4, 0, 5, 150, 230, 1, 23, false),
> - JP_PATTERN(5, 6, 10, 200, 500, 1, 16, false),
> - JP_PATTERN(6, 11, 20, 200, 500, 1, 12, false),
> - JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, false),
> - JP_PATTERN(5, 0, 1, 333, 333, 1, 9, false),
> + JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, 50, false),
> + JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, 50, false),
> + JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, 50, false),
> + JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, 50, false),
> + JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false),
> + JP_PATTERN(5, 6, 10, 200, 500, 1, 16, 50, false),
> + JP_PATTERN(6, 11, 20, 200, 500, 1, 12, 50, false),
> + JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, 50, false),
> + JP_PATTERN(5, 0, 1, 333, 333, 1, 9, 50, false),
If no JP patterns will have CHIRP set, would it make sense to embed
that parameter into the define?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 1/2] ath: define JP DFS patterns separated from FCC
@ 2015-03-31 23:17 ` Julian Calaby
0 siblings, 0 replies; 7+ messages in thread
From: Julian Calaby @ 2015-03-31 23:17 UTC (permalink / raw)
To: Peter Oh; +Cc: linux-wireless, ath10k
Hi Peter,
Two very minor points:
On Wed, Apr 1, 2015 at 5:16 AM, Peter Oh <poh@qca.qualcomm.com> wrote:
> Separate Japan's DFS pattern from FCC to control PPB threshold.
>
> Currently all the radar detectors use the same threshold rate at
> 50%, but it's not able to achieve if data traffic rate is higher
> than 40% because WLAN baseband used by ath9k and ath10k often fails
> detecting radar pulses, so that SW cannot get enough radar reports
> to achieve the rate.
>
> Since Japan's W53 band requires 50% data traffic during its DFS
> test we need to apply different threshold rate than others on it.
> Hence define its own pattern to give flexibility to threshold rate.
>
> Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
> ---
> drivers/net/wireless/ath/dfs_pattern_detector.c | 27 ++++++++++++++++---------
> 1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
> index b1de8c6..8d1e082 100644
> --- a/drivers/net/wireless/ath/dfs_pattern_detector.c
> +++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
> @@ -42,6 +42,7 @@ struct radar_types {
> /* percentage on ppb threshold to trigger detection */
> #define MIN_PPB_THRESH 50
> #define PPB_THRESH(PPB) ((PPB * MIN_PPB_THRESH + 50) / 100)
> +#define PPB_THRESH_JP(PPB, RATE) ((PPB * RATE + 100 - RATE) / 100)
These two PPB_THRESH defines are essentially doing the same math.
Would it make sense to define them as:
#define MIN_PPB_THRESH 50
#define PPB_THRESH_RATE(PPB, RATE) ((PPB * RATE + 100 - RATE) / 100)
#define PPB_THRESH(PPB) PPB_THRESH_RATE(PPB, MIN_PPB_THRESH)
In case some other country defines a specific rate for their DFS patterns?
> #define PRF2PRI(PRF) ((1000000 + PRF / 2) / PRF)
> /* percentage of pulse width tolerance */
> #define WIDTH_TOLERANCE 5
> @@ -96,17 +97,23 @@ static const struct radar_types fcc_radar_types = {
> .radar_types = fcc_radar_ref_types,
> };
>
> -#define JP_PATTERN FCC_PATTERN
> +#define JP_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB, RATE, CHIRP) \
> +{ \
> + ID, WIDTH_LOWER(WMIN), WIDTH_UPPER(WMAX), \
> + PMIN - PRI_TOLERANCE, \
> + PMAX * PRF + PRI_TOLERANCE, PRF, PPB * PRF, \
> + PPB_THRESH_JP(PPB, RATE), PRI_TOLERANCE, CHIRP \
> +}
> static const struct radar_detector_specs jp_radar_ref_types[] = {
> - JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, false),
> - JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, false),
> - JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, false),
> - JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, false),
> - JP_PATTERN(4, 0, 5, 150, 230, 1, 23, false),
> - JP_PATTERN(5, 6, 10, 200, 500, 1, 16, false),
> - JP_PATTERN(6, 11, 20, 200, 500, 1, 12, false),
> - JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, false),
> - JP_PATTERN(5, 0, 1, 333, 333, 1, 9, false),
> + JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, 50, false),
> + JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, 50, false),
> + JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, 50, false),
> + JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, 50, false),
> + JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false),
> + JP_PATTERN(5, 6, 10, 200, 500, 1, 16, 50, false),
> + JP_PATTERN(6, 11, 20, 200, 500, 1, 12, 50, false),
> + JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, 50, false),
> + JP_PATTERN(5, 0, 1, 333, 333, 1, 9, 50, false),
If no JP patterns will have CHIRP set, would it make sense to embed
that parameter into the define?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 1/2] ath: define JP DFS patterns separated from FCC
2015-03-31 23:17 ` Julian Calaby
(?)
@ 2015-03-31 23:31 ` Peter Oh
-1 siblings, 0 replies; 7+ messages in thread
From: Peter Oh @ 2015-03-31 23:31 UTC (permalink / raw)
To: ath10k
On 03/31/2015 04:17 PM, Julian Calaby wrote:
> Hi Peter,
>
> Two very minor points:
>
> On Wed, Apr 1, 2015 at 5:16 AM, Peter Oh <poh@qca.qualcomm.com> wrote:
>> Separate Japan's DFS pattern from FCC to control PPB threshold.
>>
>> Currently all the radar detectors use the same threshold rate at
>> 50%, but it's not able to achieve if data traffic rate is higher
>> than 40% because WLAN baseband used by ath9k and ath10k often fails
>> detecting radar pulses, so that SW cannot get enough radar reports
>> to achieve the rate.
>>
>> Since Japan's W53 band requires 50% data traffic during its DFS
>> test we need to apply different threshold rate than others on it.
>> Hence define its own pattern to give flexibility to threshold rate.
>>
>> Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
>> ---
>> drivers/net/wireless/ath/dfs_pattern_detector.c | 27 ++++++++++++++++---------
>> 1 file changed, 17 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c
>> index b1de8c6..8d1e082 100644
>> --- a/drivers/net/wireless/ath/dfs_pattern_detector.c
>> +++ b/drivers/net/wireless/ath/dfs_pattern_detector.c
>> @@ -42,6 +42,7 @@ struct radar_types {
>> /* percentage on ppb threshold to trigger detection */
>> #define MIN_PPB_THRESH 50
>> #define PPB_THRESH(PPB) ((PPB * MIN_PPB_THRESH + 50) / 100)
>> +#define PPB_THRESH_JP(PPB, RATE) ((PPB * RATE + 100 - RATE) / 100)
> These two PPB_THRESH defines are essentially doing the same math.
>
> Would it make sense to define them as:
>
> #define MIN_PPB_THRESH 50
> #define PPB_THRESH_RATE(PPB, RATE) ((PPB * RATE + 100 - RATE) / 100)
> #define PPB_THRESH(PPB) PPB_THRESH_RATE(PPB, MIN_PPB_THRESH)
>
> In case some other country defines a specific rate for their DFS patterns?
Thank you for the suggestion. I'll update it.
>
>> #define PRF2PRI(PRF) ((1000000 + PRF / 2) / PRF)
>> /* percentage of pulse width tolerance */
>> #define WIDTH_TOLERANCE 5
>> @@ -96,17 +97,23 @@ static const struct radar_types fcc_radar_types = {
>> .radar_types = fcc_radar_ref_types,
>> };
>>
>> -#define JP_PATTERN FCC_PATTERN
>> +#define JP_PATTERN(ID, WMIN, WMAX, PMIN, PMAX, PRF, PPB, RATE, CHIRP) \
>> +{ \
>> + ID, WIDTH_LOWER(WMIN), WIDTH_UPPER(WMAX), \
>> + PMIN - PRI_TOLERANCE, \
>> + PMAX * PRF + PRI_TOLERANCE, PRF, PPB * PRF, \
>> + PPB_THRESH_JP(PPB, RATE), PRI_TOLERANCE, CHIRP \
>> +}
>> static const struct radar_detector_specs jp_radar_ref_types[] = {
>> - JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, false),
>> - JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, false),
>> - JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, false),
>> - JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, false),
>> - JP_PATTERN(4, 0, 5, 150, 230, 1, 23, false),
>> - JP_PATTERN(5, 6, 10, 200, 500, 1, 16, false),
>> - JP_PATTERN(6, 11, 20, 200, 500, 1, 12, false),
>> - JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, false),
>> - JP_PATTERN(5, 0, 1, 333, 333, 1, 9, false),
>> + JP_PATTERN(0, 0, 1, 1428, 1428, 1, 18, 50, false),
>> + JP_PATTERN(1, 2, 3, 3846, 3846, 1, 18, 50, false),
>> + JP_PATTERN(2, 0, 1, 1388, 1388, 1, 18, 50, false),
>> + JP_PATTERN(3, 1, 2, 4000, 4000, 1, 18, 50, false),
>> + JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false),
>> + JP_PATTERN(5, 6, 10, 200, 500, 1, 16, 50, false),
>> + JP_PATTERN(6, 11, 20, 200, 500, 1, 12, 50, false),
>> + JP_PATTERN(7, 50, 100, 1000, 2000, 1, 20, 50, false),
>> + JP_PATTERN(5, 0, 1, 333, 333, 1, 9, 50, false),
> If no JP patterns will have CHIRP set, would it make sense to embed
> that parameter into the define?
In fact I have a patch to JP type 7 which is Chirp radar.
Current parameters with JP type 7 radar won't detect radar at all.
I'll send the patch separately.
> Thanks,
>
Regards,
Peter
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 7+ messages in thread