... did the original mail from me _make_ it to the ath9k list?
Adrian
On 17 December 2012 05:22, Simon Wunderlich
<simon.wunderlich@xxxxxxxxxxxxxxxxxxxx> wrote:
> Hello Adrian,
>
> thank you for posting this and the explanation!
>
> On Sat, Dec 15, 2012 at 08:06:47PM -0800, Adrian Chadd wrote:
>> The formats are as follows. Please note that if a pulse terminates
>> during an FFT, the final entry may be truncated. So yes, you may not
>> always get an integer multiple of the relevant frame length.
>
> OK - my data is mostly in the range of 55-58 bytes (see below), sometimes
> I got some longer packets, but I'm currently dropping them.
> The variation still puzzles me though.
>
>>
>> Note that you shift each of the readings by max_exp to get a total
>> reading. max_index and max_magnitude I think are just derived from the
>> existing dataset; they're just a shortcut for software so it doesn't
>> have to parse the whole frame looking for the peak.
>
> Ah ok, that makes sense. Thanks for the clarification. :)
>>
>> Static 20 mode:
>>
>> 0 bin -28 magnitude[7:0] = (|i| + |q|) >> max_exp
>> 1 bin -27 magnitude[7:0] = (|i| + |q|) >> max_exp
>> 2 - 53 …
>> 54 bin 26 magnitude[7:0] = (|i| + |q|) >> max_exp
>> 55 bin 27 magnitude[7:0] = (|i| + |q|) >> max_exp
>
> I've checked my data again: On my AR9280 in 2.4GHz, I get 55 or 57 bytes plus
> 7 "special bytes" (4 bytes meta info plus 3 bytes "radar trailer?"). In 5 GHz
> and on my AR9380 in both bands, it is always either 56 or 58 bytes. The number
> of bytes comes from rs_datalen from the rx_status struct as found in the patch
> sent earlier.
>
> So to summarise, what I currently get:
> * 55-58 bytes of "data"
> * 4 bytes of meta-information (as you provided)
> * 3 bytes of "radar trailer" (bwinfo and such)
>
> The variation in the data puzzles me, I've already checked bit 4 in bwinfo
> as Felix suggested. Is there any other "header" to the DFS data? Or should I
> just skip the first few bytes and always use the last 55 bytes? At least from the
> distribution, all of these numbers look like normal data and not a bitfield.
> Ideas welcome. :)
>
> I've also noticed that the middle of the data (like data[28]) is usually higher
> than the rest - this might be the carrier, or something alike?
>
>> 56 [7:0]: all bins {max_magnitude[1:0], bitmap_weight[5:0]}
>> 57 [7:0]: all bins max_magnitude[9:2]
>> 58 [7:0]: all bins {max_index[5:0], max_magnitude[11:10]}
>> 59 [3:0]: max_exp (shift amount to size max bin to 8-bit unsigned)
>>
>> Dynamic 20/40 mode:
>>
>> 0 bin -64 magnitude[7:0] = (|i| + |q|) >> max_exp or power (in dBm)
>> 1 bin -63 magnitude[7:0] = (|i| + |q|) >> max_exp or power (in dBm)
>> 2 - 125 …
>> 126 bin 62 magnitude[7:0] = (|i| + |q|) >> max_exp or power (in dBm)
>> 127 bin 63 magnitude[7:0] = (|i| + |q|) >> max_exp or power (in dBm)
>> 128 [7:0]: lower bins {max_magnitude[1:0], bitmap_weight[5:0]}
>> Baseband DFS 2 (Radar) Micro-Architecture
>> 129 [7:0]: lower bins max_magnitude[9:2]
>> 130 [7:0]: lower bins {max_index[5:0], max_magnitude[11:10]}
>> 131 [7:0]: upper bins {max_magnitude[1:0], bitmap_weight[5:0]}
>> 132 [7:0]: upper bins max_magnitude[9:2]
>> 133 [7:0]: upper bins {max_index[5:0], max_magnitude[11:10]}
>> 134 [3:0]: max_exp (shift amount to size max bin to 8-bit unsigned)
>
> Thanks again, also for posting the radar packet format! I'll play a little bit more
> with spectral for now ...
>
> Cheers,
> Simon
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlDPHJgACgkQrzg/fFk7axYhoQCgzBT/lTIObkmz7MoishNsDo5l
> yZ0AoIdp5kUjCglz32/HkyfeBmD49729
> =PXP+
> -----END PGP SIGNATURE-----
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
