Return-Path: X-Spam-DCC: paranoid 1480; Body=3 Fuz1=3 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.5 required=5.0 tests=BAYES_00,DATE_IN_PAST_24_48, DNS_FROM_AHBL_RHSBL,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 u9NHNs1f006623 for ; Sun, 23 Oct 2016 19:23:54 +0200 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1byMS8-0000R8-6v for rs_out_1@blacksheep.org; Sun, 23 Oct 2016 18:20:56 +0100 Received: from [195.171.43.34] (helo=relay2.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1byMS6-0000Qz-0e for rsgb_lf_group@blacksheep.org; Sun, 23 Oct 2016 18:20:54 +0100 Received: from mail-wm0-x235.google.com ([2a00:1450:400c:c09::235]) by relay2.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1byMS2-0006DL-SG for rsgb_lf_group@blacksheep.org; Sun, 23 Oct 2016 18:20:52 +0100 Received: by mail-wm0-x235.google.com with SMTP id b80so66386245wme.1 for ; Sun, 23 Oct 2016 10:20:50 -0700 (PDT) X-DKIM-Result: Domain=gmail.com Result=Good and Known Domain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=UMApwShS1xHZeZ0/VxX3YnxqhlziXUQ5XMxri4hjIw8=; b=e0QA5Srjvl6yrdhP9eZSAdD9xwZ8ALAtmkia0rCvVRXzwC/3bVoIq0Sc163rtgUu+Q g9pCnM9UWDiWwLbQJu04OQZVw/V48nANJDTzWefrnoU7XdlMLmyM7T9hydd1lwGmwC7c OxO3hfCPT7J7BInJ4XZn7EF9x3O/vR1TJvFFK06N9Yxtx1EVhkJqaru5otTCJlTreIcW 8I7j+0sXqUEv/Sq5diembEdFgVefJfi+9ZwETS94WvXFXWhHqu9uXX8My3lFVWJ9VDLw XuHK+1RWsdSaywwD50CaeEFoBmAVbwQkXil1myY2EqvJ37RfYqmu6C5VtR2B/o8ET0OT cW4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=UMApwShS1xHZeZ0/VxX3YnxqhlziXUQ5XMxri4hjIw8=; b=Zj46JRNghIBydfTfSST12cFovRIgwx78AzWd0r14SPsgSBn46HzWGZxR3GjCQ4ogV7 BiGb4Mhtd9+RutRZQeVODl4rSvh4rE/yjmzxxGH9Fw8S9t1Chezs/hE7yzDOOWCqg9rL 0cu9pjNoAVkOwnxwB9EeFrIKplFx5401a7zGGKdeXsYa/bCMt5YlZh1Za5g1Aehm7Xkz /y+sNKC3t0JCzTs0PdWQh3gLDMxubGU+77R7T6hHFZomjDlxD5E2eKkMZLNoO+AgdFlH UkbRWSy8Ee4Ss+mRE2h3mLkzWSU6YEKyFXXnldwwt4PkpHIGVCbO/1WfAMOTdQFkGRhA 83rw== X-Gm-Message-State: ABUngvdvUs9+CvU68F66PUw4zOWdcyJrftkVNtkG0X0s3g33XvcXTEFPzENn23MyCm/LPqL8yUQgXm30zmO8Rg== X-Received: by 10.194.89.71 with SMTP id bm7mr5012027wjb.207.1477156137637; Sat, 22 Oct 2016 10:08:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.209.74 with HTTP; Sat, 22 Oct 2016 10:08:57 -0700 (PDT) From: Andy Talbot Date: Sat, 22 Oct 2016 18:08:57 +0100 Message-ID: To: rsgb_lf_group@blacksheep.org X-Scan-Signature: 40d35b6fcf8b66e4fec28fa30f99f125 Subject: Re: LF: Simultaneous decoding of WSPR on LF Content-Type: multipart/alternative; boundary=089e01030114dca0ec053f773661 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: 10222 Status: O X-Status: X-Keywords: X-UID: 9157 --089e01030114dca0ec053f773661 Content-Type: text/plain; charset=UTF-8 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.. 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 >>>> >>>> >>>> >>>> >>> >>> >> >> > --089e01030114dca0ec053f773661 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
WSPR, as in all the WSJT modes captures the signal synchro= nously; =C2=A0an entire block at soundcard sample rate, so isn't affect= ed by IRQs and the like.=C2=A0 In effect, all decoding is done off line, in= teh few seconds after teh transmission ends..

Decode fa= ilures 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.=C2=A0 Bu= t was a problem with the old WSJT trying to get to 11025 with modern sound = cards.

The block decoding uses the sampling rate t= o 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.=C2=A0 The block = capture should start on the minute interval, as should teh transmission.=C2= =A0 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 <g8fzk@g8fzk.fsnet.co.uk>= ; wrote:
Hugh ,

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

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

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

73-G,

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

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

73,=C2=A0 Hugh

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

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

Stephan=C2=A0 =C2=A0should have the=C2=A0 solution, his night=C2=A0 garden = uses similar things .

The other is=C2=A0 cpu loading ?

73-G,

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

So far I've been decoding Opera32, WSPR2 and WSPR15 simultaneously on a= n 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 ru= nning in the shack leaving nice, clean signals.

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

73, Hugh, M0DSZ









--089e01030114dca0ec053f773661--