[hpsdr] exact frequency determination

[Chris Smith]

John

Last time I looked in a C or C++ programming manual >> denoted a right shift - divide by 2^n. Unless the integer arithmetic is double length and you're trying to end up with all the bits in the LS half. But then the shift would have to be n-25 where n is the word length in bits. Or should that be 25-n … ?  I can't be bothered to work it out. :-)

Chris G4NUX

On 21 Nov 2013, at 09:13, John Marvin <jm-hpsdr at themarvins.org> wrote:

> ***** High Performance Software Defined Radio Discussion List *****
> 
> 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:
> 
> The formula used for computing the phase word is:
> 
>     Frequency (in Hz) * 2^32 / 122880000
> 
> This can be reduced to:
> 
>     Frequency * 2^16 / 1875
> 
> 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:
> 
>     (Frequency * 2^41 / 1875) >> 25
> 
> 2^41 / 1875 is 1172812402.96106666.... . We round that up to 1172812403. So the equation becomes:
> 
>     (Frequency * 1172812403) >> 25
> 
> 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.
> 
> 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!
> 
> Hopefully I got it right this time :)
> 
> Regards,
> 
> John
> AC0ZG
> 
> On 11/20/2013 5:57 PM, John Marvin wrote:
>> ***** High Performance Software Defined Radio Discussion List *****
>> 
>> 
>> 
>> Brian,
>> 
>> The formula that is used in theory is:
>> 
>>     (Frequency * 2^57/122880000) >> 32
>> 
>> If you reduce that it becomes:
>> 
>>     (Frequency * 2^41/1875) >> 32
>> 
>> 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.
>> 
>> However, in practice, the fpga uses integer math. 2^41/1875 is:
>> 
>>     1172812402.961066666....
>> 
>> The fpga code rounds this to 1172812403 and uses that constant for the computation. So the actual formula used in the FPGA is:
>> 
>>     (Frequency * 1172812403) >> 32
>> 
>> 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.
>> 
>> This information should probably be put on the HPSDR wiki someplace.
>> 
>> Regards,
>> 
>> John
>> 
>> 
>> 
> 
> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at openhpsdr.org
> Subscription help: http://lists.openhpsdr.org/listinfo.cgi/hpsdr-openhpsdr.org
> HPSDR web page: http://openhpsdr.org
> Archives: http://lists.openhpsdr.org/pipermail/hpsdr-openhpsdr.org/


 1385031495.0