Many SCPI query commands return empty responses or "Undefined header" error in firmware 1.50

[Draman87]

RD6012P + Riden WiFi Dongle

After connecting via raw TCP (port 5025) and testing various SCPI commands, most measurement and setpoint query commands do not return any value — they either return an empty string or (when sent an invalid/unknown command) produce the error:

Commands that work correctly:

• *IDN? → returns correct identification string
• OUTP:STATE? → returns '1' or '0'
• OUTP:MODE? → returns '"CV"' or '"CC"'
• SOUR:VOLTAGE:PROTECTION:TRIPPED? → returns '0' or '1'
• SOUR:CURRENT:PROTECTION:TRIPPED? → returns '0' or '1'
• SYST:BEEPER:STATE? → returns '0' or '1'
• DISP:BRIGHTNESS? → returns integer (0–5)
• DISP:LANGUAGE? → returns language string

Commands that do NOT work (always empty response or timeout):

• MEAS:VOLTAGE?
• MEAS:SCAL:VOLT?
• MEAS:CURRENT?
• MEAS:SCAL:CURR?
• MEAS:POWER?
• MEAS:SCAL:POW?
• MEAS:TEMPERATURE? SYSTEM
• MEAS:SCAL:TEMP? SYSTEM
• SOUR:VOLTAGE?
• SOUR:CURRENT?

What I already tried:

• Using both \n and \r\n line endings
• Sending full long-form commands (MEASURE:SCALAR:VOLTAGE:DC?, etc.)
• Making sure output is enabled (OUTP:STATE ON)
• Waiting longer between commands (0.5–2 seconds)
• Multiple retries (up to 3–5 times per command)
• Tested with PuTTY (raw connection) and custom Python asyncio client

Expected behavior:

According to SCPI_COMMANDS.md, the measurement queries (MEAS:...) and setpoint read-back commands (SOUR:VOLT?, SOUR:CURR?) should return actual values.

Actual behavior:

All measurement and read-back queries return empty string or time out. Only status/configuration commands seem to be implemented.

Question:

Is this a known limitation in firmware 1.50?
Are these measurement queries implemented in later firmware versions?
Or is there a specific configuration step I'm missing?

Thanks for any information or pointers!

[morgendagen]

Hi,

This is definitely not the expected behaviour.

I haven't been using my Riden power supplies for a while, and just fired them up to see if I could reproduce the issue. Which I could. I will have to dig in to this some more to figure out what is going on.