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 <[email protected]> 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. > > > > > > >
