rs1729
commented
5 years ago I thought so that it will run slow. In the first run, I just put all header detections from the dft-decoders together. For auto_rx the sonde types, that are not to be decoded, could be switched off/taken out. (Although only C34/C50 is not so interesting right know. iMet-1-AB maybe also not that important anymore. But LMS6 (403MHz) could be easily included in auto_rx I guess.)
And I don't know if it is what are asking for, but there is the -t \
And then the complex-FFT could be rewritten with real,imag float, because I think the complex.h is rather slow, though I don't know why it should be so much slower. Ok, I have another place in mind, that can speed up things. I did some FFT spectrum view for ncurses (just to have a simple control view), when reading for FFT to process in blocks, it is much better to read the incoming samples in fread-blocks. These are smaller changes, I will try to test this soon. (On the other handn in real-time the fm-samples are not coming so fast, if they come one by one. but csdr/sox output to stdout should have some buffering?)
darksidelemm
Raising an issue to keep track of testing of this.
I've switched the testing branch to using dft_detect. It definitely uses more CPU, to the point where it appears to be running slower than realtime on a Pi 2. If you run auto_rx with the -v (verbose) option, there's a debug line which shows how long the detection command ran for. Ideally (in the case of no sonde present) it should only run for whatever the detect_dwell_time configuration option is set to.
On my Pi 2, the detection command takes ~12 seconds - less than 50% realtime! (On my Macbook, it runs in 5.1 seconds).
Due to the way the decode chain works (passing samples along via stdout) running slower than realtime means that samples are buffered up at the input to dft_detect. We kill rtl_fm after seconds, and it takes dft_detect another 7 seconds to chew through the remaining samples. The end result is that scan times increase a bit on slower platforms.
However - dft_detect has significant advantages, in that it has better detection performance (up to 4 dB in some cases), doesn't have issues with mis-detection of RS41s and M10s, and can detect more sonde types. Good job to @rs1729 on this, it's a really good bit of code!
I think we can live with the slower scan times, though it would be good to get some further information on detect speed on other platforms (Pi Zero W, Pi 3, etc...).