A side question related to wsprd which I've been meaning to ask for a while -- it is not clear from the documentation/examples that come with wsprd, how wsprd deals with time-sychronization.
Is it the case that wsprd expects the WSPR pkts to start within a second or two of the start of the wav file? Else they dont get picked up? Phil's note seems to imply that wsprd uses only 114 seconds of the wav file and ignores the rest of the file if it is longer. Is that the case? If that is the case, then it must also be the case that wsprd only looks for WSPR pkts that start close enough (114 - 110 = ~4 seconds) to the start of the file. Phil, have you tried playing with the c2 input instead of wav? You could feed it I-Q from your SDR signal chain, in that case. Would perform better, no? Its mentioned in the man page, but I havent tried it yet. -- 73 de ka6q Shri ---Original Message--- > From: Phil Karn via wsjt-devel <[email protected]> > Date: Sun, 8 Aug 2021 01:09:14 -0700 > To: WSJT software development <[email protected]> > Cc: Phil Karn <[email protected]> > Subject: [wsjt-devel] Anybody working on wsprd these days? > X-Headers-End: 1mCeMk-00Gcfw-V2 > Reply-To: WSJT software development <[email protected]> > > 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 > _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
