On 8/8/21 13:20, H.Shrikumar KA6Q wrote:
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?
I haven't looked at the time synch code, but it looks that way. The WSPR
transmission is 162 symbols at a symbol rate of 12000/8192 Hz, so the
entire transmission is 110.592 seconds long. The input file is 114
seconds. So if the transmission starts more than 3.408 seconds late, the
tail will be chopped off.
This doesn't mean you'd *necessarily* lose the message. Provided the
time synch search code allowed it to start that late, you could still
decode a truncated message thanks to the interleaving and FEC. But it
would necessarily degrade the SNR performance; it would be as if the
signal faded out entirely during the missing tail.
The FFT used to downsample the input file is actually 46080 * 32 =
1,474,560 points long, while 114 seconds @ 12 kHz is only 1,368,000
samples. I.e., the FFT input buffer is 46080 * 32/12000 = 122.88
seconds. The tail of the buffer (8.88 seconds) is zeroed before the FFT:
for (i=0; i<npoints; i++) {
realin[i]=buf2[i]/32768.0;
}
for (i=npoints; i<(size_t)nfft1; i++) {
realin[i]=0.0;
}
free(buf2);
fftwf_execute(PLAN1);
fftwf_free(realin);
This would make it relatively easy to let the transmission start as much
as 122.88 - 110.592 = 12.288 seconds late without chopping off the tail
provided the time synch search code looked that far. But this would
eliminate whatever benefit the zero-padding provides to mitigating the
effect of the rectangular frequency-domain window in the decimation to
375 Hz.
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?
This I'm sure of. From wsprd.c:
if( ntrmin == 2 ) {
nfft1=nfft2*32; //need to downsample by a factor of 32
df=12000.0/nfft1;
i0=1500.0/df+0.5;
npoints=114*12000;
} else if ( ntrmin == 15 ) {
......
nr=fread(buf2,2,npoints,fp); //Read raw data
fclose(fp);
So 'npoints' of 2-byte (16-bit integer) input samples are read from the
input file, and 'npoints' is equal to 114 (seconds) times 12000
samples/sec. I.e., wsprd reads 114 seconds from the input file.
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.
Right. 3.408 seconds. If I were writing a wspr decoder from scratch I'd
operate in a continuous stream mode that completely ignored timing,
i.e., it would accept a message that started at any time, without need
for an accurate clock. This *would* take (much) more CPU effort, and I
don't know if that would be acceptable without actually trying it.
My intuition (strongly emphasize "intuition") tells me that many of the
JT modes spend too much channel capacity on synchronization. With
sufficiently strong error detection, and with unlimited CPU for
decoding, you actually don't need synchronization at all. You just try a
decode at every possible frequency and time and see what comes out.
Synchronization just tells you the time & frequency combinations that
are most likely to succeed, so it spends precious channel capacity to
save increasingly cheap CPU cycles at the receiver.
I did this in the telemetry format I designed for ARISSat-1 (which flew
from the ISS in 2010-2011) and it worked. I had a 128-way convolutional
interleaver, and instead of inserting a synch sequence to indicate the
right interleaver phase I just constructed 128 parallel de-interleavers
and Viterbi decoders and ran all of them in parallel. As soon as an HDLC
frame came out with the right CRC, I stopped the other 127 and kept the
one that worked. What surprised me is that even the 128
de-interleaver/Viterbi decoders running together took less total CPU
than the PSK demod, because the demod operated at the receiver sample
rate while the de-interleaver/Viterbi decoders operated at the lower
symbol rate.
I did extend the HDLC CRC from 16 to 32 bits to reduce the chances of a
false decode. And I used a simple noncoherent DBPSK demodulator that
only required the frequency to be approximately correct; it didn't need
to acquire carrier phase. But the JT modes are also designed for fading
channels with relatively short coherence times.
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.
I've noticed the c2 file stuff, and yes I will probably use it. My SDR
can easily generate an IQ signal 375 Hz wide and centered on the 200 Hz
wide WSPR segment (e.g., 14097.1 kHz, not 14095.6). It looks like a c2
file is expected to be the full 120 seconds long: 45000 complex 32-bit
floating samples at 375 Hz = 120 sec.
-- 73 de ka6q Shri
When I first came to San Diego, I discovered that a local had that call.
I wondered who got it after him, and here you are!
73, Phil, KA9Q
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
