Return-Path: Received: from post.thorcom.com (post.thorcom.com [195.171.43.25]) by klubnl.pl (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id wAQDuHqs003597 for ; Mon, 26 Nov 2018 14:56:18 +0100 Received: from majordom by post.thorcom.com with local (Exim 4.14) id 1gRHHa-0000y8-Qe for rs_out_1@blacksheep.org; Mon, 26 Nov 2018 13:50:38 +0000 Received: from [195.171.43.32] (helo=relay1.thorcom.net) by post.thorcom.com with esmtp (Exim 4.14) id 1gRHHa-0000xx-2u for rsgb_lf_group@blacksheep.org; Mon, 26 Nov 2018 13:50:38 +0000 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]) by relay1.thorcom.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91_59-0488984) (envelope-from ) id 1gRHHX-00022D-4T for rsgb_lf_group@blacksheep.org; Mon, 26 Nov 2018 13:50:36 +0000 Received: by mail-ed1-x530.google.com with SMTP id f23so15899821edb.3 for ; Mon, 26 Nov 2018 05:50:34 -0800 (PST) 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=20161025; h=mime-version:from:date:message-id:subject:to; bh=n+NW8QYN5tnnQNivWLbBMu5cTDvdl3QtOiE838Toz6A=; b=WG1KmoGAQfFPr5FH0QxoYdBvLcFPY1uGvfg9RFl9Hb6viJVcYqVIZQDIge53b5+XSX 0INEg4EimgPNi6DHvBYjZ21F37EnNfwFIfLmxUBh8R7qouVP/7uwVK84P6BKorBcOqdr 76XqZf+7hb3/Ri6I36WgWWRI/mFTzRw648qfh6iCHD8VHLVCPD1jV9HhL5X1IqhezRI+ gx7LhXeq28Nsfc9vtsr42Kzo/REYrbfWpnxSP+fA+yOuZcnNjn9qWVk8FMZrpZ9JpeyK cHK91pHbjajfrnXYcPAHFavAA7Eb2ykjAvogjecHr+aaZcdwlLrEnU/BXlx+9tBMhf33 Gxyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n+NW8QYN5tnnQNivWLbBMu5cTDvdl3QtOiE838Toz6A=; b=ZJ16XfGjb8PA7cWT2KmGosNioZUHFiHUWZWQyUn17XtyFYg196hRimYxoNbvgJPLTp 0XzErUThEneFDP533OCcWpl2xSTEFNARAzktBBBA4htHggpy5nTK9VijYbSDVhrSFS9f S7rIfo6lOLUzXAgvLUiSk9O9O4pkl+kwugNEat47cuY9jzKMnQWp0WK2uNZoPqtcW0gd 5jRGexBpGpZtqgEfwL7a0hI3eZnn8oxITn0SpHY45sI55e4CwELRoO+xuvlVq9J8by47 M6UvO9kRQ2PcQGyVG/sTqx/EjHl051xJJegRLg2yG/5MTj0IApDssvsP3rsW7rDFOm1+ vYjg== X-Gm-Message-State: AA+aEWZHXjhZJJJpZ5zOq9v7oacOcVVLLTilUkLyNZg6S/FgkhfSZ8et T+Y4lhV9waQ4Ruw6gyuLAZrxOe2xz0XhP2FihQo= X-Google-Smtp-Source: AFSGD/VRBKUm3PdUCg+I8Wm+rbMhybHSmLiLlU+I8SgQ6eBqwCwFDFINVktXp7yH9FEHJlniudSxm1Mqh9/2siYkCgY= X-Received: by 2002:a50:903c:: with SMTP id b57mr23748568eda.161.1543240233987; Mon, 26 Nov 2018 05:50:33 -0800 (PST) MIME-Version: 1.0 From: Andy Talbot Date: Mon, 26 Nov 2018 13:50:22 +0000 Message-ID: To: EladSDR@groups.io, "rsgb_lf_group@blacksheep.org" , rsgb_lf_group X-Spam-Score: 0.0 (/) X-Spam-Report: Spam detection software, running on the system "relay1.thorcom.net", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: After tests the other day looking at the few milliHz error observable using the FDM-DUO locked to an external reference, I decided to make sure it was purely an NCO rounding error and nothing else hap [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [2a00:1450:4864:20:0:0:0:530 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (andy.g4jnt[at]gmail.com) 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid X-Scan-Signature: b45446db24846e84db90eb694609e205 Subject: LF: FDM-DUO Useable for Coherent Comms !!!!!!!! Content-Type: multipart/alternative; boundary="000000000000f332b5057b919d1a" X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on post.thorcom.com X-Spam-Level: * X-Spam-Status: No, hits=1.8 required=5.0 tests=HTML_20_30,HTML_MESSAGE, PLING_PLING autolearn=no version=2.63 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 --000000000000f332b5057b919d1a Content-Type: text/plain; charset="UTF-8" After tests the other day looking at the few milliHz error observable using the FDM-DUO locked to an external reference, I decided to make sure it was purely an NCO rounding error and nothing else hapening inside the radio Assuming a 32 Bit NCO clocked at 122.88MHz, we need to know the lowest common frequency that is both a multiple of the tuning step and also a binary submultiple of the clock. this, and all its multiples, can be generated exactly with no NCO tuning error. For the DUO receiver this frequency is 1875Hz, being Fc/65536 and an integral number of Hz. Therefore, any RF tuning point (LO frequency) that is a multiple of 1875Hz should exhibit no NCO offset error. The only frequency in the 137kHz band that meets this criteria is 136.875kHz so the radio was set to this in USB mode. (1875Hz * 73) My DDS low frequency signal generator was set to generate at 137.975kHz so a 1kHz tone resulted. Using the DUO's internal soundcard, the G3PLX vectorscope software was used to measure the phase of the 1kHz output against a reference NCO of 1kHz derived from samples arriving from the soundcard. Since the soundcard samples at 48kHz which is an integer multiple of 1kHz there will be no rounding errors. Radio and sources were locked to the same reference (*) so its accuracy didn't enter into the equation. The only potential error in frequency is my DDS source that, due to its internal maths / rounding, was generating this RF 2.17uHz high (that 's 2.17micro-Hertz) The vectorscope showed a dot on the screen and a phase readout of this position to a resolution of 0.1 degree. After 48 minutes of monitoring, the observed phase of the 1kHz tone had shifted from 131.9deg to 130.0deg, ie -1.9 degrees in 2880 seconds. This equates to a frequency error of 1.9/360/2880 = 1.8uHz Which equal to the error of the DDS RF source allowing for the 0.1deg phase readout resolution So, it looks as if the EXACT frequency of the FDM-DUO's local oscillator when set to any particular frequency ought to be calculable: Work out the nearest integer N value programmed into the NCO for the 1Hz frequency specified, then calculate backwards using that N to get the actual frequency generated. Multiples of 1875Hz will be exact Glad that's sorted ! (*) initially, as I was running out of BNC sockets on my Shack master reference splitter (driven from an old GPSDO) I initially ran the RF source from another GPSDO. Almost immediately a slight phase wander of the 137kHz signal was seen. This calculated as being a frequency difference in the order of 10^-9 (1 PPB) between the two references. Which is exactly the sort of short term error one would expect to see in simple GPSDOs) A rearrangememt of 10MHz master feeds and all was sorted for the test. Andy www.g4jnt.com --000000000000f332b5057b919d1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
After tests the other day looking at the few mil= liHz error observable using the FDM-DUO locked to an external reference, I = decided to make sure it was purely an NCO rounding error and nothing else h= apening inside the radio

Assuming a 32 B= it NCO clocked at 122.88MHz,=C2=A0 we need to know the lowest common freque= ncy that is both a multiple of the tuning step and also a binary submultipl= e of the clock.=C2=A0 =C2=A0this, and all its multiples,=C2=A0 can be gener= ated exactly with no NCO tuning error.=C2=A0 =C2=A0

For the DUO receiver this frequency is 1875Hz, being Fc/65536 a= nd an integral number of Hz.
Therefore, any RF tuning point = (LO frequency)=C2=A0 that is a multiple of 1875Hz should exhibit no NCO off= set error.

The only frequency in the 137= kHz band that meets this criteria is 136.875kHz=C2=A0 so the radio was set = to this in USB mode.=C2=A0 (1875Hz * 73)
My DDS low frequenc= y signal generator was set to generate at 137.975kHz so a 1kHz tone resulte= d.=C2=A0 =C2=A0Using the DUO's internal soundcard, the G3PLX vectorscop= e software was used to measure the phase of the 1kHz output against a refer= ence NCO of 1kHz derived from samples arriving from the soundcard.=C2=A0 Si= nce the soundcard samples at 48kHz which is an integer multiple of 1kHz the= re will be no rounding errors.=C2=A0 Radio and sources were locked to the s= ame reference (*) so its accuracy didn't enter into the equation.=C2=A0= =C2=A0

The only potential error in frequ= ency is my DDS source that, due to its internal maths / rounding, was gener= ating this RF 2.17uHz high=C2=A0 (that 's 2.17micro-Hertz)

The vectorscope showed a dot on the screen and a pha= se readout of this position to a resolution of 0.1 degree.=C2=A0 =C2=A0 =C2= =A0 After 48 minutes of monitoring, the observed phase of the 1kHz tone had= shifted from 131.9deg to 130.0deg, ie -1.9 degrees in 2880 seconds.=C2=A0 = =C2=A0This equates to a frequency error of 1.9/360/2880 =3D 1.8uHz
Which equal to the error of the DDS RF source allowing for the 0.1de= g phase readout resolution

So, it looks = as if the EXACT frequency of the FDM-DUO's local oscillator when set to= any particular frequency ought to be calculable:

=
Work out the nearest integer N value programmed into the NCO for = the 1Hz frequency specified, then calculate backwards using that N to get t= he actual frequency generated.=C2=A0 =C2=A0Multiples of 1875Hz will be exac= t

Glad that's sorted !

(*) initially, as I was running out of BNC sockets on= my Shack master reference splitter (driven from an old GPSDO)=C2=A0 I init= ially ran the RF source from another GPSDO.=C2=A0 Almost immediately a slig= ht phase wander of the 137kHz signal was seen.=C2=A0 =C2=A0This calculated = as being a frequency difference in the order of 10^-9 (1 PPB) between the t= wo references.=C2=A0 =C2=A0Which is exactly the sort of short term error on= e would expect to see in simple GPSDOs)=C2=A0 =C2=A0 A rearrangememt of 10M= Hz master feeds and all was sorted for the test.

<= div>
--000000000000f332b5057b919d1a--