Precision of SCPI readings (Rigol DG4000 AWG/Counter)

[RoGeorge]

The instrument has a counter input that can act as a frequency meter.  When fed with a 10 MHz signal (from its own 10 MHz reference), the measurement on the instrument display is a stable

10.000 000 000 0 MHz

(10 digits after the decimal separator).  However, when reading the counter using SCPI command ":COUNter:MEASure?", the SCPI response is a number in engineering format showing a different value:

9.999 999 975 E+06

Same problem reading other numbers, for example the frequency set for channel 2 of the generator.  On the screen is "123.123 456 789 kHz", but when reading it by SCPI it is shown as "1.231 235 E+05".  In the pics the SCPI commands were sent using LXI Tools/LAN/Ubuntu.  With other tools (e.g. using netcat instead of LXI Tools) the results are the same, it's the instrument that sends the numbers in engineering format and with less decimals than displayed.

1.  Is this a common issue for SCPI readings, or is it something specific to this instrument?
2.  Any idea how to read by SCPI the full numbers, with all the decimals shown on the instrument's display?

[unitedatoms]

Could be gate time is different for screen and for SCPI command.

try
:COUNter:GATEtime?


and

:COUNter:GATEtime USER5

[RoGeorge]

":COUNter:GATEtime?" returns "USER5".  The gate time can be set just fine by SCPI, for example ":COUNter:GATEtime USER4" switches the instrument to Gate Time = 1s, while ":COUNter:GATEtime USER5" set it back to 10 seconds.

However, no matter the gate time, on the display the number of decimals doesn't changes.  Even when the gate time is set to 1 ms (either by SCPI or from the instrument's buttons), the instrument still displays the same

10.000 000 000 0 MHz on the screen and
9.999 999 975E+06 by SCPI.

[unitedatoms]

Oh, I re-read your post. I see, from its own reference. That means that there is the bug. Perhaps there were more than one dev. One for scpi and one for UI. Ui guy had it patched over to go to vacation. The scpi guy did not get a memo, that bug is in FPGA or something. It is 2.5ppb after all.

Edit: Or even simpler, the bug is scpi only, used float precision instead of double for sprint or something. 22 bit precision when dealing with 48 bit values is no joke.

[RoGeorge]

Leaving aside the frequency counter, the same problem happens with other numbers.

For example if I set by hand to generate a waveform of "123.123 456 789 kHz", then ask by SCPI what frequency did I just set, I get "1.231 235 E+05", so I suspect the digits are lost when they are converted to the engineering format, before sending them as text through SCPI.

[unitedatoms]

There could be a remote chance that a scpi client trying to reparse the data. Try telnet and see if responds are different.

[RoGeorge]

I've tried already, with "netcat".  The whole message is plain ASCII text, including the numbers.