Hi Jeff, since I had non GitHub-Account up to now I created one, described that issue, and now we will see...
Thank you for now. When I receive a solution I will reply here. 73, Tom On 01.05.21 22:28, Jeff Long wrote:
Also, if you can describe the message flow in a little more detail, it would help. Is something sending a message to the number control, is the number control sending a message to something else, or both? If you are generating the message, make sure it is a double instead of a float. The number control is definitely generating a float, which can be shown to be wrong (same result as you reported): >>> import pmt >>> pmt.to_double(pmt.from_float(138001000)) 138000992.0 On Sat, May 1, 2021 at 4:17 PM Jeff Long <willco...@gmail.com <mailto:willco...@gmail.com>> wrote: 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 <https://github.com/gnuradio/gnuradio/issues> and it will get fixed. On Sat, May 1, 2021 at 3:58 PM Marcus D. Leech <patchvonbr...@gmail.com <mailto:patchvonbr...@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.
