Return to KLUBNL.PL main page

[Top] [All Lists]

Re: LF: WSPR T/A hole discussion

To: <[email protected]>
Subject: Re: LF: WSPR T/A hole discussion
From: "James Moritz" <[email protected]>
Date: Sun, 7 Nov 2010 11:41:26 -0000
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1289130088; bh=7jXnCTjiBatj4gUcCuOwKMPMafVQvP8dCsunq9KMSx4=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:From:To:References:In-Reply-To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE; b=jELzjH25SWvslgkK3nOkzWozdDJU4+fDmISiGCWMI55ut6f5wVLWLmWYG8eNMxjayHDBfAvMyOba8QTixbkCZFJNyJOQL7fcg6TAxNqhWArngXkLB03fKv86vf87Ly2NrEx7r920Tzgxo0qbkU7ligFHeK7AbeD4Z03Vv0Sqktg=
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024;; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:From:To:References:In-Reply-To:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE; b=o/s/vHZgohOIIA26ToHYzXTdamrFddLezsRXRzkdM4PDJ9kgCchghZnlg2Av8JUJn2XLqhD3H67FQ3Hj9yZJlJ6Jvz9U/e6Qq5HruuUaynM9Jy24Cl/j3FpkcGa97It6+6Y/dbh4rdyeVd5S9KJ+AzkDc7gZ23PNJm9QYBuZPfE= ;
Domainkey-status: good (testing)
In-reply-to: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>
Reply-to: [email protected]
Sender: [email protected]
Dear John, Roelof, LF Group,

I think this problem and the discussion just reflects the fact that receivers are not really designed for use with digital modes, particularly ones that are very narrow-band compared to the traditional phone/CW modes. There does not seem to be a fundamental reason why WSPR signals of greatly differing strength should not be successfully simultaneously decoded, provided the transmitted signals are "clean", and the receive stages up to and including the DSP processing have good linearity and low phase noise, etc.
There has been an obsession in the amateur world for receivers with enormous
dynamic range, but this is only normally applied to the RX front end, up to
the point where the final IF bandwidth is achieved - the designers assume
that the IF bandwidth is similar to the wanted signal bandwidth, and
filtering represents all that can be done to remove unwanted signals. It is
assumed that all unwanted signals that it is possible to remove have been
eliminated after this stage. The post-filter stages only need to be linear
enough not to significantly impair the wanted signal, and there has to be a
trade-off with other inherently non-linear functions too, such as AGC.
But for many modern "digital" modes, this is no longer the case - normally,
several signals will be present in the RX IF and audio channel
simultaneously. In the case where spread-spectrum or CDMA techniques are
used, multiple signals inherently use the same bandwidth. Linearity must be
maintained throughout the receiver. So RX design lags behind the
requirements for modern transmission modes. I think in the long term this
means seperating the audible reception channel from the data reception
channel, with A/D conversion immediately after a "roofing" filter for data
signals, and AGC, etc. confined to the "analogue" channel. For current
receivers this can't easily be done, and the best practical thing to do in
my experience seems to be to ensure the AGC has been disabled, and that the
RF/IF gain is operated at a much lower level than would normally be used for
audible reception. This applies to QRSS, etc as well as WSPR. I have found
that with careful gain adjustment, a lot of the problems due to strong local
signals can be eliminated.
In the case of WSPR, the other practical thing that can be done is to reduce
the TX duty cycle - so if a 20% duty cycle is used, 80% of time slots will
be unnaffected by a local ground-wave-blasting station; if there are two
such stations, 64% of slots remain unaffected, and even for three, 51% are
Cheers, Jim Moritz
73 de M0BMU

<Prev in Thread] Current Thread [Next in Thread>