On 31 December 2012 00:46, Simon Wunderlich <simon.wunderlich@xxxxxxxxxxxxxxxxxxxx> wrote: >> Your frame length logic is OK for the short spectral scan reports, but >> not useful for the longer aggregate reports (short_rpt=0 IIRC.) > > Yeah, I've always used short_rpt=1 AFAIR. >> >> Here there's >1 FFT report in a frame, _and_ it could be corrupted, >> _and_ it could be short. > > That sounds like a lot of fun :P Yeah. Ew. > Before asking questions, I'll wait for your userland lib and see what > it does. I've seen some longer frames as well occasionally when starting > to play with spectral, but didn't care too much as I didn't know how to > handle it. Anyway, I prefer hiding the corrupt and messy part and only > pass "clean data" to userspace, at least with the Linux implementation. I'm taking the opposite approach - I'll pass the PHY error frames up to userland untouched (and with extra radiotap vendor info like per-chain RSSI/NF calibration values) and do the fixups in userland. The only fixups I'd do in kernel is stuff that requires register hackery to do. Otherwise I have to replace the driver each time I want to change/extend/fix something. I'm doing the same with radar pulse handling - it's exposed via bpf/radiotap the same way that any other frame is. Userland can then just see what kind of packet it is by inspecting the radiotap header and do what it needs to. > If you have some code handling and/or correct these long dataframes, I'd > be happy to integrate it if possible. Well right now I'm just trying to finish writing a thin layer to decode (and make sure I'm decoding the correct data!) before I worry about finding/fixing corrupted frames. I'll try to commit what I have thus far to FreeBSD today/tomorrow but I also have real work to get done. I've taken your code and broken it out a bit to support multiple data sources, rather than just a hard-coded single data source from a file. That way I can (in theory) just add a FreeBSD data source and represent data as you need. Also, yes - I'm using whatever your FFT_eval code in userland is. :-) Adrian -- 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
