Well, I add my report to github.
Hopefully I explained my way to show the error correctly.
https://github.com/gnuradio/gnuradio/issues/4562
Am 02.05.2021 um 16:18 schrieb Tom Breyer:
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.
