Message-ID: <3C44631A.942D751C@usa.net>
Date: Tue, 15 Jan 2002 18:12:58 +0100
From: "Alberto di Bene" <dibene@usa.net>
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
Subject: Re: LF: Introducing Jason
References: <5.1.0.14.0.20020115133352.00a65df8@gemini.herts.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org
Sender: <majordom@post.thorcom.com>

James Moritz wrote:

> Dear Alberto, Steve, Dave, LF group,
>
> 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.
>

Hi Jim and the group,
  probably 300 MHz will not be enough... at least until the slowed down
version is ready.

> 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?

If you use a fixed "carrier" tone, you have to alternate it with the tones sent.
Don't forget that at any one time, a single tone is transmitted.
So, you transmit the carrier, then a tone. Their difference conveys information,
but when you retransmit again the carrier, this time no information is sent...

> 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.
>

This would gain one bit each nibble, increasing the alphabet from 64 to 256
symbols. For keyboard-to-keyboard communication, I think 64 symbols
are enough.

> 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.

Hmmm, suppose I have just sent tone 13. Next, I have to send a delta
of 16 (the deltas range from 1 to 16). 13 + 16 mod 16 = 13, so I would
end up sending the same tone, with a delta of 0.  Or maybe I misunderstood
what you said ?

> 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...
>

No, sending would be at the same speed. Each tone sent is acting as a
reference for the next one, already in the present scheme.

>
> Cheers, Jim Moritz
> 73 de M0BMU

Thanks for your remarks Jim

73  Alberto  I2PHD