Slow CW Vs. BPSK

[Andre' Kesteloot]

John Davis wrote:

>    Les Rayburn writes:
> >The most obvious "pro" for Slow CW to me would seem to be that both the
> >transmission and reception of these signals can be accomplished
> >without major changes to anyone's Lowfer set up.
> >
>
> Correct.  That is its major advantage.
>
> BPSK has certain advantages in difficult conditions due to its ability to
> make decisions based on accumulated data (frame grabbing), but this also
> means the message must be repetitive and its duration must be known in order
> to receive successfully under those conditions.  In addition, if the
> receiver isn't extemely close to the transmitted frequency, time and data
> can be wasted while the software acquires the signal.
>
> QRSS has the advantage of not requiring you to know the frequency to the
> nearest Hertz or wasting
> time continuously sending redundant information, though it may take longer
> to get the message in the first place under a given set of circumstances.
>
> >Also, would someone like to fill me in on the latest advances to
> >the Slow CW program? It seems to make it possible to send
> >a given amount of information in a shorter time frame. But it seems to
> >me that would ultimately hurt the S/N ratio, right?
>
> Not necessarily.  The dual frequency mode partially removes an inefficiency
> that is inherent in Morse code; namely, that the symbols transmitted consist
> of elements which are distinguished from each other by their durations,
> which are integer multiples of the dot length, and by whether carrier is on
> or off during those intervals.  The bandwidth of a Morse transmission is
> determined by the dot length, but the "bit rate" is a lot slower than the
> bandwidth would suggest because of this need to distinguish between
> elements.  That's a pretty wasteful encoding scheme, but was necessary to
> ensuring that the ear could discriminate between the elements of the symbols
> reliably.
>
> The original QRSS retained this limitation.  However, the dual frequency
> mode substitutes a second frequency for the extra time used in sending a
> dash.  (In real-world conditions, some people apparently had trouble
> distinguishing a string of dits or dahs from a single longer element, so
> Rick also included a one second break between elements to provide a sort of
> clock reference.  That's why I say it partially removes the inherent
> inefficiency.)
>
> For the default QRSS mode of three seconds per dot, one assumes a sub-Hertz
> bandwidth.  The frequency shift is typically 4 or 5Hz.  One might therefore
> suppose that the frequency shift imposes a substantial increase in
> bandwidth, and thereby a large decrease in S/N.  But this is not so.
>
> Bear in mind that the detection method is a visual display of a large number
> of immediately adjacent channels, each filtered to milliHertz bandwidths.
> The S/N ratio of each displayed spectrum line is independent of its
> neighbors and is a function of its own bandwidth.  So if you have enough
> computing power, you can resolve hundreds of Hertz of receiver output into
> several hundred of these skinny frequency slots with pretty amazing S/N.
> Now...the frequency differential QRSS mode doesn't require you to include
> the frequency slots between its high and low conditions (provided the
> transmitter and receiver are reasonably stable, hi).  It only requires you
> to be able to distinguish the on/off states of two of those slots.
>
> That _is_ equivalent to an S/N reduction of 3db because you may indeed have
> to decide which of the two lines you see on screen is valid at a given
> moment in time, rather than only determining the validity of one.  If you
> have to take into account the power present in two channels of equal width,
> that is a 3db difference.  However, by eliminating waste in the coding
> method, you have gained a nearly 5db increase in speed!  Not a bad tradeoff.
>
> You could, of course, slow down the transmission to achieve something near
> the original data throughput, and actually come out ahead on S/N due to the
> reduction of coding waste.
>
> >Since time is not that critical in a one way transmission, I would think
> >that slower was better. But perhaps a faster version would allow us
> >to take advantage of short term enhancements in propagation?
>
> Perhaps, but such enhancements are relatively rare at LF.  A whopping lot of
> slow transmissions can take place while a faster station is spinning its
> wheels waiting for propagation to cooperate...and with relatively low
> chances of anyone randomly monitoring at just the right time, the odds of
> the faster transmission ever being copied at all are pretty low.
>
> (That's based on random monitoring, as is applicable to conventional LowFER
> activity.  Coordinated monitoring, such as applies to the Transatlantic and
> Transpacific efforts, would be a slightly different matter.  I'd think one
> would want to cover all bases in those projects: slow, not so slow, CW,
> BPSK.)
>
> 73,
> John
>
> To unsubscribe, send to MAJORDOMO@qth.net "unsubscribe lowfer" (Do not
> send to list!!) Send on list submissions to lowfer@qth.net