Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: Introducing Jason

To: [email protected]
Subject: Re: LF: Introducing Jason
From: "James Moritz" <[email protected]>
Date: Tue, 15 Jan 2002 16:13:09 +0000
In-reply-to: <[email protected]>
Reply-to: [email protected]
Sender: <[email protected]>
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




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