Content-Transfer-Encoding: 8bit
Message-ID: <5.1.0.14.0.20030110164545.02cc2b58@gemini.herts.ac.uk>
Date: Fri, 10 Jan 2003 17:47:13 +0000
To: rsgb_lf_group@blacksheep.org
From: "James Moritz" <j.r.moritz@herts.ac.uk>
In-reply-to: <27.36199209.2b504eb7@aol.com>
MIME-Version: 1.0
Subject: Re: LF: Jason Beacon signals
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: <owner-rsgb_lf_group@blacksheep.org>
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org

At 11:28 10/01/2003 -0500, you wrote:
>Dear Jim and group,
>
>no criticism intended, but in my opinion machine-decoded modes like Jason 
>or WOLF have one disadvantage for long-haul propagation experiments: They 
>are exclusive, in the sense that potential receivers on the far side can 
>only see one signal at a time, whereas visual modes like QRSS or DFCW 
>allow several stations transmitting side by side.
>
>73 es best of luck
>Markus, DF6NM

Dear Markus, LF group,

This is certainly a drawback of current digital modes - but not necessarily 
so with a "slow" mode like Jason, where the operator can read the received 
information at a much faster rate than the data is transmitted. In 
principle at least , you could do this: Digitise a relatively large 
bandwidth as a .wav file or similar, and store , for the sake of argument, 
30 minutes worth of data in memory. Then generate a waterfall display from 
this data , so that the operator could see the signals present. Then the 
operator could specify the frequency of a signal of interest, and the 
demodulation/ decoding DSP algorithm could decode the signal, again using 
the same data in memory. Having done that, the operator could repeat the 
procedure with another signal, and so on.  Since Jason et al transmit data 
slowly, and DSP algorithms can run quite fast, it should be possible to 
receive, store and process several signals simultaneously, and display them 
sequentially.

Maybe that is a job for some future piece of software - but if you have a 
few PCs lying around in the shack, there is nothing to stop you doing it 
now - connect them all to the RX audio output , set one up with a waterfall 
display to identify signals of interest, then set up the rest running Jason 
decoders (or other modes, for that matter), so that as soon as a signal is 
identified, one of the other  PCs can be assigned to decode that signal . 
At the moment, since there is no more than 1 Jason signal most of the time, 
this would only require 2 PCs, one to monitor the Jason frequency, and one 
to monitor the QRSS frequencies. The problem would be that the RX bandwidth 
would have to be wide enough to include 135.9xx kHz, as well as 137.5kHz., 
so the RX would probably be overloaded if anyone local was QRV in the CW 
band segment . But that might not be a problem in the USA. An easy solution 
would be If I  transmitted the Jason beacon closer to the "transatlantic" 
segment, so that all the signals would fit through a CW filter. If anyone 
would care to try this, and would care to nominate a suitable frequency 
near 135.9kHz, I could do that now.....

Cheers, Jim Moritz
73 de M0BMU