Ath10k Issues - Shifting "max_magnitude" Range, Mesh Current Channel Scan, Caching

Ednessto dania6789 at gmail.com
Tue May 23 10:39:16 PDT 2023


Hello!

I have been using the ath10k driver over the past few months to
implement a spectral scanner on a Compute Module 4. The interface used
to perform the scan is a mesh-type interface. The spectral scan is
performed as per the steps documented on the ath10k wiki page. There
are a few behaviors I've observed that I could not seem to resolve and
suspect they may be bugs. I would greatly appreciate your input or
suggestions!

Issue 1: Varying “max_magnitude” range of values for 5 GHz Channels
Note: This issue concerns the range of max_magnitude values for
channels in the 5 GHz band only, this issue is not seen for the 2.4GHz
channels.
When running the spectral scanner, if the iw scan command, iw dev
{interface} scan freq {freq}, is executed by passing to it a list of
2.4 and 5 GHz bands, then the average value of the "max_magnitude" for
the 5GHz channels is around 800. If the spectral scanner is run with a
subset of frequencies, for instance by passing some 2.4 frequencies
and then 5GHz channels, or only passing frequencies from the 2.4 band,
then the range of max_magnitude values is ~ 50.

Tests performed passing the following frequencies to the scan command:
- All 2.4 GHz and all 5 GHz → average max mag 800
- All 5 GHz and all 2.4GHz → scanner scans 2.4 band then 5 regardless, avg 800
- Subset of 2.4GHz and all 5GHz → avg 800
- All 2.4 GHz and subset of 5GHz → avg 800
- Subset of 2.4GHz and subset of 5GHz (passed few of each/ one of
each) → avg 800
- (!) All or subset of 5 GHz → avg 40
- Do not pass any frequency, let scan perform default scan → avg 800

What is the expected "max_magnitude" value range/ which of the 40 or
800 values is what is expected to see? Why is it that when passing
just the 5GHz channels the average "max_magnitude" values drop to 40?
Any suggestions/workarounds on what to do?

----------------------------------------------
Issue 2: Cannot scan current channel mesh is parked
A low latency spectral scan cannot be performed on the channel that a
mesh interface is parked on, i.e., trying to scan the current channel
of the mesh returns nothing.
Note: this issue is not seen in a non-mesh environment such as using
type AP interface with the ath10k driver.

For the mesh type interface, I tested performing a spectral scan by
setting the {freq} parameter in the iw scan command to the frequency
the mesh is parked at, the spectral scan then returns no output on all
subsequent scans. Similarly, if we pass all 2.4GHz and 5GHz bands, if
the mesh is set to channel 36 frequency 5180, it will scan all the
available channels to scan, identified using iwlist {interface}
channel, except for channel 36, the channel the mesh is on.

Is there anything I'm missing with regard to this? And what can be
done about this issue?

----------------------------------------------
Issue 3: Caching
When conducting a spectral scan, there are a few cases where the
spectral scanner returns two scan outputs, e.g scan results for 2.4
GHz channels, 5, 2.4, and 5, even though only one two bands were
passed (2.4GHz and 5GHz).
This happens mostly upon first running the spectral scanner or if the
scanner fails:
resource is busy if the scan interface is in use or one of the fft
spectral_* files (mostly spectral_scan_ctl) fails returning:
error: /bin/sh: line 1: echo: write error: No such device
error: /bin/sh: line 1: echo: write error: Invalid argument)

I'm assuming this may be a caching issue? I have tried adding the
"flush" parameter to the scan command, however, it did not help.

Any input on this behavior, and also on the two errors often returned
when running the spectral scan?

Let me know if you would like me to clarify anything.

Regards,
Dan



More information about the ath10k mailing list