Hey Adrian, On Sun, Dec 30, 2012 at 09:33:06PM -0800, Adrian Chadd wrote: > Hi, > > I'm just going through and hacking on this now for FreeBSD (and > userland decoding, rather than kernel side decoding.) Cool! > > 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 > > I'm just writing a userland library now to start parsing and > correcting these. It's likely that I can use your logic for the short > spectral reports, but I won't be able to use them for the longer > aggregate reports. We'll need to find some other way to determine that > they've been corrupted and just toss/correct as appropriate. > > Thanks for digging into this! 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. If you have some code handling and/or correct these long dataframes, I'd be happy to integrate it if possible. Thanks! Simon
Attachment:
signature.asc
Description: Digital signature
