Content-Transfer-Encoding: 8bit
Message-ID: <5.1.0.14.0.20020115133352.00a65df8@gemini.herts.ac.uk>
Date: Tue, 15 Jan 2002 16:13:09 +0000
To: rsgb_lf_group@blacksheep.org
From: "James Moritz" <j.r.moritz@herts.ac.uk>
Subject: Re: LF: Introducing Jason
In-reply-to: <3C4301BD.878E49BF@usa.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

Dear Alberto, Steve, Dave, LF group,

Thanks for producing this new mode - should be interesting to see what 
happens. A few thoughts cross my mind:

The fastest computer I have is 300MHz, so whether this is adequate remains 
to be seen. So I would certainly be interested in some tests from G3YXM 
this evening.

As for generating the signal, the interfacing options in "Jason" give 
plenty of possibilities - Since I don't currently have a suitable SSB 
exciter or DDS, I am thinking of using a VCXO, or even a VCO in a similar 
scheme to that I am using for 7FSK; the frequency stability requirement is 
relaxed, but since there are many more tones, greater tuning range and 
linearity is required - something like 1% linearity would seem necessary. 
So a bit of experimentation will be needed.

Perhaps silly questions, but why 2 different tone frequencies for each 
symbol? Would it not be possible to have 16 different tones with 1 fixed 
"carrier" tone, to generate the same 16 difference frequencies and roughly 
halve the BW? Also, is it necessary to have different symbols for the first 
and second 3 bits of each carrier? I realize this removes the ambiguity, 
but since a particular tone is either the beginning or the end, there are 
only 2 possible decodes, one of which will be garbage - both decodes could 
be displayed side by side, and it could be left to the operator to decide 
which was correct.

Another thought is a differential encoding scheme - suppose you have 16 
tones and 16 symbols, then the next tone would be the modulo 16 sum of the 
current tone frequency and the next symbol. For example, if tone 9 is 
currently being transmitted, and the next symbol is 5, the next tone will 
be 14. If the next symbol after that is 8, the next tone will be 6 (+16), 
and so on. The receiving software would still be looking for the difference 
frequency between successive tones - however, sending would be twice as 
fast because only 1 tone would be sent for each symbol, with the previous 
tone acting as the reference. I think I'm missing something, but I can't 
think what at the moment...

Cheers, Jim Moritz
73 de M0BMU