Message-ID: <3D3EC275.5261F1A1@usa.net>
Date: Wed, 24 Jul 2002 17:06:29 +0200
From: "Alberto di Bene" <dibene@usa.net>
MIME-Version: 1.0
To: rsgb_lf_group@blacksheep.org
Subject: LF: Re: Jason code on DDS Module
References: <7D653C9C42F5D411A27C00508BF8803DCB9B3D@mail.dstl.gov.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>

Talbot Andrew wrote:

> Don't see the advantage of GPS timing this mode, the timing is generated by
> the Jason driver software.  In fact, it may be necessary to ensure a
> constant delay through the controller so the updates are consistant, but I
> guess a few 100us uncertainty per tone won't matter

Correct, as a matter of fact the tolerance is much higher than that.
My decoder computes a running statistic of the frequency peaks encountered,
and uses this to declare that a new baud is incoming, so the timing requirements
are rather relaxed. The only true requirement is to obey to the time/frequency
duality, which imposes a baud duration at least equal to the inverse of the
FFT bin,  0.084114.... Hz.
GPS could be of advantage should Jason use coherent decoding, which in its
present form it doesn't.

73  Alberto  I2PHD