IRQs and the like
True , with no extended path between the RX
and PC , time is time , IRQ was a simplification
,
but when the Rx is not at the PC , things
like net congestion , provide time shifts, which move block's
in time as can be observed using web-sdr's to
monitor data transmissions, especially those at the leading
edge , where time is important , if the arrival
times are not as expected , thing's go wrong , ,
usually manifesting as loss of lock or failing to
reach min -s/n expectations , odfm system , where pilot
carriers are interspaced with data , seem to transit
the web quite well as the decode is instantaneous,
but at the expense of s/n
G,
Sent: Saturday, October 22, 2016 6:08 PM
Subject: Re: LF: Simultaneous decoding of WSPR on
LF
WSPR, as in all the WSJT modes captures the signal synchronously;
an entire block at soundcard sample rate, so isn't affected by IRQs and
the like. In effect, all decoding is done off line, in teh few seconds
after teh transmission ends..
Decode failures are most serious when due to sampling rate errors. which is
nowadays not much of a problem with WSJT-X adopting the standard 48kHz Fs.
But was a problem with the old WSJT trying to get to 11025 with modern sound
cards.
The block decoding uses the sampling rate to define symbol timing, so at
the end of a 48 second block, even 0.5% error in sampling rate leads to symbol
misalignment at the end.
The other error mechanism, is just timing itself. The block capture
should start on the minute interval, as should teh transmission. The
decoder can handle slippages here of a few seconds either way, but not more than
about 3 or 4s IIRC.
Andy 'jnt
|