DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=Aau45R5ifYx5JggGkHk16BtswomlsA0BlVSEd1iqg8gj1g4yHwr+7ptgwl7iBFendF
         TfmZM3ifMt844AhXgCP4hP7x6fjtXiS1wTZuwtzNe4FOBCX2Kx8UnySZMRR69yo6jt/w
         B18fL+c+puMY77MfgRPAnXv3QblgadZBlNR9A=
MIME-Version: 1.0
In-Reply-To: <49A03A7C.2050703@telus.net>
References: <fc7eccec0902210140h2bf8c3f5v622f0add158b4283@mail.gmail.com>
	 <49A03A7C.2050703@telus.net>
Date: Sat, 21 Feb 2009 19:15:56 +0000
Message-ID: <fc7eccec0902211115o34395295ibff07f3ac0d2eb90@mail.gmail.com>
From: Andy Talbot <andy.g4jnt@googlemail.com>
To: rsgb_lf_group@blacksheep.org
DomainKey-Status: good (testing) 
Subject: Re: LF: Wanted - non-random PN sequence generator - so Off Topic it 
	shouldn't be allowed here!
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: owner-rsgb_lf_group@blacksheep.org
Precedence: bulk
Reply-To: rsgb_lf_group@blacksheep.org


Scott:
Its precisely that an LFSR does not give what is needed that made me
start thinking along these lines.   For one thing, LFSRs are only
random if considered over the whole repeat length, viz  2 ^ N - 1 bit
for a maximal length sequence.   They will have one single run of
exactly N ones, and N-1 zeroes, and a predicatable numbers of runs of
fewer successive equal bits.  It is a well established annoyance with
these that short register lengths cannot be used to generate
half-decent pseudo randomness

What I was idly speculating on was a straightforward way of generating
a semi-random sequence with deliberately limited continuous runs of
ones or zeroes.  By forcing this aspect, the sequence cannot possibly
be random. A ideal sequence would probably have very little
statistical randomness at all.  But it sems to have turned out to be
not at all straightforward.

Eg 33% duty cycle with no randomisation
      001001001001001001001001001001
A true PN sequence at 33% could be like
      010000111100100000001100101000
which has an excessively long sequence of ones for WSPR Tx purposes
A more optimised pattern might be
      001010100001010100100010001010
Apart from one bit, this one is actually a smaller pattern repeated.

Which all comes down to the idea that its easiest to just generate (by
inspection !) a set of precomputed tables - but that just feels like
cheating and I feel dissatisfied with it :-)

Andy
www.g4jnt.com



2009/2/21 Scott Tilley <sthed475@telus.net>:
> Hi Andy
>
> Try a 'Linear Feedback Shift Register', Google it...
>
> Very simple to implement in a MCU and can be scaled to any size you like.  I
> wrote some code to do this in PIC assembly years ago that was only a few
> lines long for a 256bit sequence...
>
> Best of all you can predict the outcome and choose a sequence that meets
> your needs given a unique seed word....
>
> Better yet it offers a means of identification over a long term integration
> :-)
>
> 73 Scott
> VE7TIL
>
>
> Andy Talbot wrote:
>>
>> ...but if any mathematicians,  number theorists or cryptographers
>> should be reading this...
>>
>> I've just got a WSPR generating routine running on a PIC / AD9852 /
>> GPS combination, but I'm looking for a half-decent way of generating a
>> pseudo random Tx/Rx sequence with defined duty cycle that does not
>> give the long(ish) consecutive runs of 0's or 1's that MUST ALWAYS
>> occasionally be seen in a truly random sequence.
>>
>> In other words, the sequence needs to be bandpass filtered.
>>
>> Before I cop-out and just use a pre-generated set of lookup tables,
>> take a look at   http://www.g4jnt.com/WSPR_PN_Sequence.pdf
>> for a fuller description of the mind-bender
>>
>>
>> Andy  G4JNT
>> www.g4jnt.com
>>
>>
>>
>
>