QT GUI Digital Number Control / inaccuracy

[cbxtom]

Hi team,
when I use "QT GUI Digital Number Control" to display a frequency I see some "special effects".
I feed the control by sending numbers from Gpredict to it.

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⁷)?

[willcode]

This is due to use of pmt.from_float() or similar. Verified that, with two chained controls, the second one displays wrong values. Could be just in the control, or could also be in whatever is sending messages to the control

[willcode]

@cbxtom I've put in a fix for some floating point precision problems in the Python GUI widgets. I'm still not quite sure this fixes your problem, since I do not know how you have gpredict wired up to send data to the number control. Can you describe that in any more detail?

[cbxtom]

Here I explain what I did and I add a screendump of my flowchart:
I use a program called gpredict to calculate a frequency drift for satellites flying by to compensate the doppler shift. You can setup the frequency also manually and there I found that misinterpretation of the values coming from gpredict.

[cbxtom]

In the left bottom edge one can see that the incoming values seem to be correct:

[cbxtom]

Does that help?
If a solution is available I offer to test it immediatly.

[willcode]

That helps. So, while you pointed out something that needed to be looked at in GNU Radio, the problem you are seeing is actually this code in gr-gpredict-doppler/python/doppler.py:

  def sendFreq(self,freq):
    p = pmt.from_float(freq)
    self.message_port_pub(pmt.intern("freq"),pmt.cons(pmt.intern("freq"),p))

The precision is being lost at the message sender. It is coincidence that the digital number control makes the same mistake when it sends out a message - that's the bug I was looking at.

The gr-gpredict-doppler code has not changed in a while, so I don't know if it is maintained. There is also this version (I have not looked at it): https://github.com/gruffen/gr-gpredict-doppler-3.8

[willcode]

The GNU Radio portion of this is fixed now. The problem mentioned here is here, in gr-gpredict-doppler:

https://github.com/ghostop14/gr-gpredict-doppler/blob/4c7773262cb76e033ab2c0f42e428e3a8b681b69/python/doppler.py#L149

Closing.

[willcode]

@ghostop14 see above

[ghostop14]

Hi @willcode, ah yes. frequencies as floats produces errors. Good catch. I'll update it to from_double.

[ghostop14]

Pushed fix to gpredict.