<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">OK, I made some mistakes in my last
posting. The left shift should have been 25 bits, not 32 (I got
fooled by a bad comment in the code). I was also wrong about an
additional (very small) error being introduced by the rounding off
of the constant used for the integer multiply. I was looking more
closely at the algorithm in order to determine the maximum and
minimum errors, and realized my mistakes. So, let me start over,
rather than trying to correct my previous statements:<br>
<br>
The formula used for computing the phase word is:<br>
<br>
Frequency (in Hz) * 2^32 / 122880000<br>
<br>
This can be reduced to:<br>
<br>
Frequency * 2^16 / 1875<br>
<br>
In order to preserve accuracy while doing integer math we shift
everything to the left 25 bits, use a nearby integer constant for
the multiply and then shift the result back 25 bits:<br>
<br>
(Frequency * 2^41 / 1875) >> 25<br>
<br>
2^41 / 1875 is 1172812402.96106666.... . We round that up to
1172812403. So the equation becomes:<br>
<br>
(Frequency * 1172812403) >> 25<br>
<br>
Since we are multiplying by a constant slightly higher than 2^41 /
1875 we'll get a number slightly higher than the desired result,
but we lose that additional amount when we shift the result by 25
bits. Since the primary error is due to the integer truncation,
this slight addition actually helps shift the error range
downwards a tiny bit. In the case of frequencies that divide
evenly by 1875, the additional error introduced by rounding up the
integer constant won't accumulate into the 25th bit until we reach
a frequency of approximately 862 Mhz, which is much higher than
the highest frequency the current HPSDR boards support. So there
is no additional error introduced by this rounding, which means
that frequencies that evenly divide by 1875 Hz are "perfect" and
the lower bound on the error caused by the integer truncation of
the resulting computation is 0.<br>
<br>
What is the upper bound of the error? The upper bound would be
when the formula would result in a phase word of X.999999999.....
which then got truncated to X. So rounding the .999999999.... to
1, the maximum error is 1 unit in the phase word. Working
backwards we get (1 x 1875 / 2^16), which is approximately .02861
Hz or 28.61 mHz. It's actually a tiny bit less than that due to
the rounded constant used above, which would push values that were
slightly under a whole unit just over to the next integer value.
If we cared we could cut the maximum error in half, shifting the
error range from 0-~28.61 mHz to +/- ~14.31 mHz by adding another
constant (2^40/1875 = ~586406201) after doing the multiply but
before doing the 25 bit left shift (actually done as a bit
selection in the code). Probably most people wouldn't care!<br>
<br>
Hopefully I got it right this time :)<br>
<br>
Regards,<br>
<br>
John<br>
AC0ZG<br>
<br>
On 11/20/2013 5:57 PM, John Marvin wrote:<br>
</div>
<blockquote cite="mid:528D5A72.7050202@themarvins.org" type="cite">
<pre wrap="">***** High Performance Software Defined Radio Discussion List *****
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Brian,<br>
<br>
The formula that is used in theory is:<br>
<br>
(Frequency * 2^57/122880000) >> 32<br>
<br>
If you reduce that it becomes:<br>
<br>
(Frequency * 2^41/1875) >> 32<br>
<br>
So, theoretically any frequency that is evenly divided by 1875
would be a "perfect" frequency. I use that rule when setting
frequencies for the FMT.<br>
<br>
However, in practice, the fpga uses integer math. 2^41/1875 is:<br>
<br>
1172812402.961066666....<br>
<br>
The fpga code rounds this to 1172812403 and uses that constant
for the computation. So the actual formula used in the FPGA is:<br>
<br>
(Frequency * 1172812403) >> 32<br>
<br>
Therefore there is always some error, however it is minimized at
frequencies that are evenly divided by 1875. In those cases I
believe the error is less than .1 mHz.<br>
<br>
This information should probably be put on the HPSDR wiki
someplace.<br>
<br>
Regards,<br>
<br>
John<br>
<br>
<br>
<br>
</div>
</blockquote>
<br>
</body>
</html>