Return to KLUBNL.PL main page

rsgb_lf_group
[Top] [All Lists]

Re: LF: what causes this on wspr

To: [email protected]
Subject: Re: LF: what causes this on wspr
From: Andy Talbot <[email protected]>
Date: Wed, 1 Jul 2015 19:58:21 +0100
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4TZgwc91msP7cDXM05WVdT1m8LOlEG68lWXzH3F03pc=; b=MwOWSr/IKcOv+osclckICebnnb9+aSOTdiDTtawYIfqLbQGo1UyTCG1FOqfF46u/xp 5QdQYJItJUGVyTb2ZIleaAYDuvfTemdjLO734SMtlVzIiYf4JigN4I+vJs7sO7pNPiFJ 6l4g8rF4C3gThb3I1BEpq5mq6PjhRbfNn9MTkxx7ge1slddwhX8iZodun9iYs8nK7MQe pWIyG952li4VaLAklskV1uc+oEAFZrmG2Zp+CIPE/iivvPs7V1rdBnfAVDPXN81hGVpR wxloP+pTvJ3NKmbN24CcE3KWMAN9NxroNnRHuc9SMSAD6gGSegn5NWjCyk///6UZURkB kF8w==
In-reply-to: <DCDCBBEE0A3A4017A36D911D814CCFAA@AGB>
References: <7D577AEFBA43411C807FDDFBCF90CCC0@AGB> <CAA8k23TYF9baA_5ppsGCRZhDj5aE45josFa=t3USzW1X8nKW0A@mail.gmail.com> <A2BFB53FFC8847C9944A6EE20B266DE7@AGB> <CAA8k23S5nmktwO1L4A9YOOM8tdBbXUwNt-6M+q2v-YbhLBuaZQ@mail.gmail.com> <DCDCBBEE0A3A4017A36D911D814CCFAA@AGB>
Reply-to: [email protected]
Sender: [email protected]
Its more than just PLL settling time.   That could be controlled by suitable choice of loop bandwidth.  At least I think it is. 
It could be part of the PLL's own internal VCO calibration when it is reprogrammed.  First discovered this using the LMX2541 to generate WSJT modes on beacons.  But found a suitable work around on that chip.  Designers of the U3 with its Si5xxxx family device haven't even acknowledged the problem , don't have teh test equipment to measure it, won't take advice, and teh chip is poorly documented anyway - unlike TI's products.

 See next months RadCom (August issue) where I discuss in a lot more depth the problems using Fract-N synths with internal VCOs when generating  MFSK modes and why these occur.

Andy


On 1 July 2015 at 19:48, Graham <[email protected]> wrote:
I don't think  its  stability Andy  ,  could  be step  response and  settling  time ,   the  new  U3 kit   uses  a  PLL and produces  , what was thought to  be  key  click's  but  is  PLL   settling time ,  out of lock  detectors  would  normally inhibit  output , but for a  phase cont  system .. there's  a  conflict of interests , no problem  keying  Opera  as  its a  single  tone , fixed  frequency , but the  mfsk  modes  have  problems  associated  ..  the  original  used  DSS
 
 , PLL's   may  be   the  wrong  way to  go I think for a  exciter , where  large step  changes  in frequency  are  commanded  ,  after  all  ,  we  know  why  DDS's  where  first  devised : ) 
 
G,

Sent: Wednesday, July 01, 2015 6:22 PM
Subject: Re: LF: what causes this on wspr

Yep - I missed the fact it was over a minute long .
The sidebands are 12Hz (not 8Hz as I said before) which seems a bit close for any synth instability.  Nothing is that slow surely.

So a bit of a mystery in that case.    Still reckon it looks like CW though.    Hard on -off keing generates a spectrum at harmonics of the clock frequency



Andy


On 1 July 2015 at 17:58, Graham <[email protected]> wrote:
Hi Andy
 
Problem there  is  it  lasts  , what  seems  to  be  the  full  duration  of the  data  phase  [ phase as  a change  from  cw  to data .. etc ]
 
wspr  via a  ssb  rig ,  overdriving  usually  produces  , harmonic  side  bands ,   1000  , 2000   Hz etc  Mains  Hum  50/100/150  etc 
 
The  power  distribution  looks like a  FM signal ,  that  would  also  account  for the  equal    distribution   about  the  centre  and the  extended  group  of  side  bands  to  the  right ..
 
I would  take   shot  at  a  kit  using   either  a  PLL    or   one  of the  clock  pulse  systems  .. with  timing  jitter  ?
 
73 -G,

Sent: Wednesday, July 01, 2015 5:33 PM
Subject: Re: LF: what causes this on wspr

Fast CW ident perhaps ?
The spectral lines look to be about 8Hz apart so that makes it 10 WPM or thereabouts

Andy  'jnt


On 1 July 2015 at 17:24, Graham <[email protected]> wrote:
what causes this  on wspr
 
This  takes  some  doing  ...... but  how  to  do  it  ?
 
G,



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