dump1090 testfiles incorrect samplerate

[vmw]

When using dump1090 to decode the included testfile in attempting to decode the included modes1.bin testfile, the current revision does not seem to correctly decode the file.

In particular, prior to commit 8f82e61, the testfile was sampled at 2MSPS, but, since then, it's' moved to a 2.4MSPS demodulator. If nothing else, this should be documented - there are a lot of references that use this, and the test file itself should be brought up-to-date.

./dump1090 --ifile testfiles/modes1.bin  --stats

results in stats showing 194 total usable messages (see observations). After this commit, things seem to get funny; immediately after this commit, it shows 256 usable messages. Then, somewhere near acd3870, it shows 283 total usable messages, but the number of unrecognized ICAO addresses has gone up. After the removal of the 2MHz in 8f82e61, even if I resample the testfile/modes1.bin, using 6/5, I don't see nearly as many valid options, and those I do see suggest an increase in "unrecognized ICAO address".

It would be really useful if the testfile/modes1.bin could be updated - having a known good datafile also allows for better regression testing. It might also be useful if the documentation indicated the preferred sample rate to be used when specifying the --ifile option, as it doesn't seem to be clear.

[vmw]

It turns out that the original test files are in a different data format then expected. Using gnuradio, and the attached flowgraph, I was able to resample the files, and confirm operation, at least for sc16 use.

[mutability]

Yeah, there is a lot of old debug cruft that is out of date.

If you're willing to update it for the current code (and/or remove whatever's not relevant) I'm more than happy to take a PR for that.

Note that, in general, resampling an existing file is going to produce poorer results than taking a new capture directly at the correct rate.