Return-Path: X-Spam-DCC: paranoid 1480; Body=2 Fuz1=2 Fuz2=2 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on lipkowski.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DNS_FROM_AHBL_RHSBL, HTML_40_50,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.3 Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by paranoid.lipkowski.org (8.13.7/8.13.7) with ESMTP id u9NISNgs006819 for ; Sun, 23 Oct 2016 20:28:24 +0200 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1byNRg-0001Kf-Kl for rs_out_1@blacksheep.org; Sun, 23 Oct 2016 19:24:32 +0100 Received: from [195.171.43.34] (helo=relay2.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1byNRg-0001KW-2S for rsgb_lf_group@blacksheep.org; Sun, 23 Oct 2016 19:24:32 +0100 Received: from smtpout2.wanadoo.co.uk ([80.12.242.42] helo=smtpout.wanadoo.co.uk) by relay2.thorcom.net with esmtp (Exim 4.87) (envelope-from ) id 1byNRc-0006cI-KV for rsgb_lf_group@blacksheep.org; Sun, 23 Oct 2016 19:24:30 +0100 Received: from AGB ([109.180.89.78]) by mwinf5d29 with ME id z6QS1t0091hRfNM036QSQT; Sun, 23 Oct 2016 20:24:27 +0200 X-ME-Helo: AGB X-ME-Date: Sun, 23 Oct 2016 20:24:27 +0200 X-ME-IP: 109.180.89.78 Message-ID: <992B4B986AB142A09FBAAB5C569B8FB9@AGB> From: "Graham" To: References: In-Reply-To: Date: Sun, 23 Oct 2016 19:24:26 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Scan-Signature: 9c6f861813be21b949fefb381c49ca48 Subject: Re: LF: Simultaneous decoding of WSPR on LF Content-Type: multipart/alternative; boundary="----=_NextPart_000_006A_01D22D63.115EE690" X-SA-Exim-Scanned: Yes Sender: owner-rsgb_lf_group@blacksheep.org Precedence: bulk Reply-To: rsgb_lf_group@blacksheep.org X-Listname: rsgb_lf_group X-SA-Exim-Rcpt-To: rs_out_1@blacksheep.org X-SA-Exim-Scanned: No; SAEximRunCond expanded to false X-Scanned-By: MIMEDefang 2.56 on 10.1.3.11 Content-Length: 13767 Status: O X-Status: X-Keywords: X-UID: 9164 This is a multi-part message in MIME format. ------=_NextPart_000_006A_01D22D63.115EE690 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable IRQs and the like=20 True , with no extended path between the RX and PC , time is = time , IRQ was a simplification , =20 but when the Rx is not at the PC , things like net congestion , = provide time shifts, which move block's in time as can be observed = using web-sdr's to monitor data transmissions, especially those at = the leading edge , where time is important , if the arrival times = are not as expected , thing's go wrong , , usually manifesting as = loss of lock or failing to reach min -s/n expectations , odfm = system , where pilot carriers are interspaced with data , seem to = transit the web quite well as the decode is instantaneous, but at = the expense of s/n =20 G, From: Andy Talbot=20 Sent: Saturday, October 22, 2016 6:08 PM To: rsgb_lf_group@blacksheep.org=20 Subject: Re: LF: Simultaneous decoding of WSPR on LF WSPR, as in all the WSJT modes captures the signal synchronously; an = entire block at soundcard sample rate, so isn't affected by IRQs and the = like. In effect, all decoding is done off line, in teh few seconds = after teh transmission ends..=20 Decode failures are most serious when due to sampling rate errors. which = is nowadays not much of a problem with WSJT-X adopting the standard = 48kHz Fs. But was a problem with the old WSJT trying to get to 11025 = with modern sound cards. The block decoding uses the sampling rate to define symbol timing, so at = the end of a 48 second block, even 0.5% error in sampling rate leads to = symbol misalignment at the end. The other error mechanism, is just timing itself. The block capture = should start on the minute interval, as should teh transmission. The = decoder can handle slippages here of a few seconds either way, but not = more than about 3 or 4s IIRC. Andy 'jnt On 22 October 2016 at 16:37, Graham wrote: Hugh , By 'time' I was more concerned with the synchronisation , along = the time line , ' clock jitter ' in computer speak .. if sections = of the time line are displaced due to IRQ action or similar , you = could reduce the system's ability to reach maximum - s/n Opera requires ~ min of 40% capture of the Tx signal , along the = time line , either randomly , blocks or 40/60 split , using manchester = coding , each data 'bit' is self-sync , so it impossible to 'loose' = lock.. where as a conventional system would need to establish sync at = the start ,...... as long as 40% of the opera recovered [or sent !] = plays ball , it will decode , [ or detect for dynamic, has the same = 40% requirement] or in wspr case , sync is provided externally If the time line is = then jumped , the system will no be able to recover the data , and = as in the 2 pass wspr , unless the two signals are exactly the = same in time and coherent phase , the expected +3 dB gain cannot = be realised . 73-G, -------------------------------------------------- From: "LineOne" Sent: Saturday, October 22, 2016 11:20 AM To: Subject: Re: LF: Simultaneous decoding of WSPR on LF I checked the PC time and it seems that the Realtek software stops = "net time" from loading on occasions so, for another reason as well, I = eventually found some older Realtek software that doesn't do this. The = software supplied with the motherboard will not share the "line out" = with any software if it's used for, as I do, a small speaker amplifier. = It has to have the Realtek drivers loaded otherwise no audio at all. 73, Hugh On 21/10/2016 23:27, Graham wrote: May be down to time Hugh , Opera is free running, so absolute time reference has no effect = on the system performance .. Stephan should have the solution, his night garden uses = similar things . The other is cpu loading ? 73-G, -------------------------------------------------- From: "LineOne" Sent: Friday, October 21, 2016 11:10 PM To: Subject: LF: Simultaneous decoding of WSPR on LF So far I've been decoding Opera32, WSPR2 and WSPR15 = simultaneously on an old IBM "Thinkpad" in the shack. This weekend I've = managed a wireless connection to a desktop PC in the house so only a = receiver is running in the shack leaving nice, clean signals. Decoding Opera 32 is going well (3000km best so far this = evening) but the PC, with the same operating system and radio software, = will not decode any WSPR at the same time. I haven't yet tried running = just WSPR-X (for WSPR2) on it's own but it does show a good signal on = the waterfall if I arrange a 1.5kHz heterodyne in the shack. Why would a = supposedly superior computer refuse to cooperate, I suspect the Realtek = on-board sound card and software is not actually up to the job? 73, Hugh, M0DSZ ------=_NextPart_000_006A_01D22D63.115EE690 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
IRQs and the like
 
True , with no  extended path  between  the  RX = and  PC ,  time  is  time , IRQ was a  = simplification=20 , 
 
but when the  Rx is  not  at the  PC  , = things=20 like  net congestion , provide time  shifts, which move = block's=20  in time  as can be observed  using  web-sdr's  = to=20 monitor data  transmissions, especially those at the  = leading =20 edge , where  time is important   , if the  = arrival=20 times  are not  as  expected , thing's  go  = wrong , ,=20 usually manifesting as  loss of  lock  or  failing = to =20 reach min -s/n  expectations , odfm system , where  pilot = carriers  are  interspaced  with  data , seem to = transit=20 the  web  quite well as the  decode is  = instantaneous,=20 but  at the  expense of  s/n  
 
G,

Sent: Saturday, October 22, 2016 6:08 PM
To: rsgb_lf_group@blacksheep.org= =20
Subject: Re: LF: Simultaneous decoding of WSPR on=20 LF

WSPR, as in all the WSJT modes captures the signal = synchronously;=20  an entire block at soundcard sample rate, so isn't affected by = IRQs and=20 the like.  In effect, all decoding is done off line, in teh few = seconds=20 after teh transmission ends..=20

Decode failures are most serious when due to sampling rate errors. = which is=20 nowadays not much of a problem with WSJT-X adopting the standard 48kHz = Fs. =20 But was a problem with the old WSJT trying to get to 11025 with modern = sound=20 cards.

The block decoding uses the sampling rate to define symbol timing, = so at=20 the end of a 48 second block, even 0.5% error in sampling rate leads to = symbol=20 misalignment at the end.

The other error mechanism, is just timing itself.  The block = capture=20 should start on the minute interval, as should teh transmission.  = The=20 decoder can handle slippages here of a few seconds either way, but not = more than=20 about 3 or 4s IIRC.

Andy 'jnt


On 22 October 2016 at 16:37, Graham <g8fzk@g8fzk.fsnet.co.uk> wrote:
Hugh ,

By 'time'  I was more =20 concerned  with the  synchronisation , along the time  = line=20 ,  ' clock jitter '  in  computer speak .. if = sections  of=20 the time  line are displaced due to  IRQ  action or = similar ,=20 you  could reduce the  system's ability to reach  = maximum =20 - s/n

Opera requires  ~ min of  40%  capture of=20 the  Tx signal ,  along the  time line ,  = either =20 randomly , blocks or 40/60 split , using manchester coding , each data = 'bit'  is  self-sync , so it impossible to  'loose' = lock..=20 where as a conventional system would need to  establish  = sync at the=20 start ,...... as long as 40% of the opera recovered [or sent !] plays = ball=20 ,  it  will decode ,  [ or detect for  dynamic, = has=20 the  same 40% requirement]

or in wspr  case , sync = is =20 provided  externally If the  time line is  then jumped = ,=20 the  system will  no  be  able to recover = the =20 data  , and  as in the   2 pass  wspr , = unless =20 the  two  signals  are  exactly  the  = same =20 in time  and  coherent phase , the  expected  +3 = dB gain=20 cannot be  realised=20 = .

73-G,

----------------------------------------------= ----
From:=20 "LineOne" <dhchurch@lineone.net>
Sent: Saturday, = October 22, 2016=20 11:20 AM
To: <rsgb_lf_group@blacksheep.org>
Subject: Re: = LF:=20 Simultaneous decoding of WSPR on LF

I checked the PC time and it seems that the = Realtek=20 software stops "net time" from loading on occasions so, for another = reason=20 as well, I eventually found some older Realtek software that doesn't = do=20 this. The software supplied with the motherboard will not share the = "line=20 out" with any software if it's used for, as I do, a small speaker = amplifier.=20 It has to have the Realtek drivers loaded otherwise no audio at=20 all.

73,  Hugh

On 21/10/2016 23:27, Graham = wrote:
May be  down to  time  Hugh=20 ,

Opera  is  free running, so absolute time  = reference has no effect on the system  performance=20 ..

Stephan   should have the  solution, his=20 night  garden uses similar things .

The other is  = cpu=20 loading=20 = ?

73-G,

----------------------------------------------= ----
From:=20 "LineOne" <dhchurch@lineone.net>
Sent: Friday, = October 21,=20 2016 11:10 PM
To: <rsgb_lf_group@blacksheep.org>
Subject: = LF:=20 Simultaneous decoding of WSPR on LF

So far I've been decoding Opera32, WSPR2 and = WSPR15=20 simultaneously on an old IBM "Thinkpad" in the shack. This = weekend I've=20 managed a wireless connection to a desktop PC in the house so = only a=20 receiver is running in the shack leaving nice, clean=20 signals.

Decoding Opera 32 is going well (3000km best so = far this=20 evening) but the PC, with the same operating system and radio = software,=20 will not decode any WSPR at the same time. I haven't yet tried = running=20 just WSPR-X (for WSPR2) on it's own but it does show a good = signal on=20 the waterfall if I arrange a 1.5kHz heterodyne in the shack. Why = would a=20 supposedly superior computer refuse to cooperate, I suspect the = Realtek=20 on-board sound card and software is  not actually up to the = job?

73, Hugh,=20 = M0DSZ









------=_NextPart_000_006A_01D22D63.115EE690--