discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: QT GUI Digital Number Control / inaccuracy


From: Jeff Long
Subject: Re: QT GUI Digital Number Control / inaccuracy
Date: Sat, 1 May 2021 16:17:34 -0400

This is a buggy use of pmt.from_float() and/or pmt.to_float() in digitalnumbercontrol.py. Please submit an issue to https://github.com/gnuradio/gnuradio/issues and it will get fixed.

On Sat, May 1, 2021 at 3:58 PM Marcus D. Leech <patchvonbraun@gmail.com> wrote:
On 05/01/2021 10:37 AM, Tom Breyer wrote:
> Dear team,
>
> when I use "QT GUI Digital Number Control" to display a frequency I see
> some "special effects".
>
> Below 128MHz, it works fine but above I get wrong display data:
>
> ok:
> Input 128.001.000Hz -> Display = 128.001.000
>
> not ok:
> Input 138.001.000Hz -> Display = 138.000.992
> Input 137.999.000Hz -> Display = 137.999.008
>
> I simulate that input by using Gpredict via tcp port 4532 but found
> debug messages ok.
>
> Does that depend on the QT GUI Digital Number Control and the way it
> converts numerical data types, since (128 = 2⁷)?
> Can I adjust that module by my own?
>
> 73, Tom, DJ6TB
>
>
That's almost certainly an artifact of the machine representation of
single-precision floating-point
   numbers.

I'm not that familiar with the message infrastructure and whether it can
carry double-precision values or not.
   [The sample streams within Gnu Radio are almost always
single-precision floats, because;

A: Computations in single-precision are considerably faster than
double-precision
B: There's no numerical advantage to double-precision for most
signal-processing functions--there's more-than-adequate
     dynamic range in a single-precision (32-bit) representation.







reply via email to

[Prev in Thread] Current Thread [Next in Thread]