Hi. I've gotten wsprd working with my own SDR. I wrapped a program around it that receives a RTP (Real Time Protocol) stream over the network from my SDR, creates a 2-minute long .wav file, and invokes wsprd on it. Works great once I realized that it ignores the .wav header and expects a mono file with a 12 kHz sample rate.
And NO soundcards and NO level-setting and NO audio patch cables, analog/real or virtual! (They've been a pet peeve of mine for a long time.) The input processing looks pretty straightforward. Suck in 114 seconds (for 2-minute WSPR) of real samples, shift down 1500 Hz to center at zero Hz complex and downsample to 375 Hz complex. So it should be fairly straightforward to handle other common .wav file sample rates and formats, e.g., 8/16/24/48 kHz or stereo with I/Q data. This could eliminate some duplicate work between wsprd and my SDR. If I do this, will you guys take back my code? I will of course not change the default behavior. Question: what is the reason for placing the 114 seconds of samples in a zero-padded FFT input buffer that's actually 122.88 seconds long @ 12 kHz? If I had to guess, this is to reduce the ringing effect of the rectangular (brick wall) filter response in the frequency domain when you select the 375 Hz you want and ignore the rest. In my SDR I window my decimation filters in the frequency domain with an adjustable Kaiser window. Maybe it doesn't matter here because 375 Hz is still much faster than the WSPR symbol rate of 12,000/8,192 Hz, there are 256 (output) samples in one WSPR symbol time, and the SNR is very low anyway. I'd also like to add locking to wsprd's output files. Right now there is no file locking, so if you run multiple copies of wsprd you have to ensure they operate in different directories. I would like to share WSPR_ALL.TXT, hashtable.txt and wspr_timer.out files, as well as a common system-wide FFTW "wisdom" file. That requires file locking. Not sure what to do with wspr_spots.txt, since it looks like it's meant to be read by other programs and then deleted; perhaps each could be given a unique name. Locking would be transparent except for the risk of one program blocking the others were it to hang for some reason while holding the lock. Phil _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
