SCPI Problems

[spel-oe]

Hello, when using SCPI commands I get somehow "ERROR" response for all kind of commands:

• some commands not working with no working SCPI afterwards
• saving calibration order loading calibration not possible
• performing touchstone export multiple times

telnet 127.00.0.1 9091
Trying 127.0.0.1...
Connected to 127.00.0.1.
Escape character is '^]'.
VNA:TRAC:LIST?
S11,S12,S21,S22
VNA:CAL:LOAD "S.cal"
ERROR
VNA:TRAC:LIST?
ERROR

telnet 127.00.0.1 9091
Trying 127.0.0.1...
Connected to 127.00.0.1.
Escape character is '^]'.
*IDN?
LibreVNA-GUI
VNA:TRAC:LIST?
S11,S12,S21,S22
VNA:CAL:BUSY?
ERROR
VNA:TRAC:LIST?
ERROR

further strange errors appear if I try to save or load a calibration, before saving a calibration was loaded in the GUI:

VNA:CALibration:SAVE S

as well as (with T.cal in the same folder as binary)

VNA:CALibration:LOAD T (or T.cal)

chosen "S" as filename as I don't know if ".cal" will be added or not.

third "ERROR" I get, if i want to read out the touchstone-file twice with no other command in between, when I execute "*IDN?" in between the two exports it works.

using version 1.2.1 for PC and Firmware on ubuntu 20.04.

Is there somehow an Error how I use the command set?

[jankae]

I am not sure if this is the solution for all your issues, but there is a colon (':') missing at the beginning of most your commands. The SCPI interpreter remembers the branch of the last commands and starts parsing there, unless the next command starts with a colon. As far as I know this is standard SCPI behavior, so also implemented it like that. This result is therefore normal:

VNA:TRAC:LIST?
S11,S12,S21,S22
VNA:TRAC:LIST?
ERROR

The second command is assumed to start at the last used branch (VNA:TRAC) and its full length interpretation would be :VNA:TRAC:VNA:TRAC:LIST? which does not exist. You have two options to solve this. Either you only send the remaining text:

VNA:TRAC:LIST?
S11,S12,S21,S22
LIST?
S11,S12,S21,S22

Or you start the second command with a colon, which forces interpretation from the root branch:

VNA:TRAC:LIST?
S11,S12,S21,S22
:VNA:TRAC:LIST?
S11,S12,S21,S22

In fact, I would recommend to start every single command with a colon. That way the command interpretation does not depend on any previous command.

[spel-oe]

thanks, will try it! (and will close or further comment)

[spel-oe]

the Trace List and Tochstone export is working fine with the leading ":", Thanks!

But I couldn't solve the calibration SAVE/LOAD Problem. SOLT calibration is loaded in the GUI. Loading and Saving works fine in the GUI but not over SCPI

:VNA:CAL:SAVE test
ERROR
:VNA:CAL:SAVE ./TEST
ERROR
:VNA:CAL:SAVE TEST
ERROR

When checking the Busy Parameter I found out that with a valid SOLT calibration without line parameter set, it returns Busy => True Only with all possible calibration sets satisfied Busy=>False is returned. This is not an problem, just an observation.

[jankae]

Unfortunately, I can not replicate the calibration save issue. It is working fine here with the exact same commands. Do you have write permissions for the directory where the LibreVNA executable is located? It will attempt to put the files there.

When checking the Busy Parameter I found out that with a valid SOLT calibration without line parameter set, it returns Busy => True Only with all possible calibration sets satisfied Busy=>False is returned. This is not an problem, just an observation.

This was due to an uninitialized variable, fixed now.

[spel-oe]

with the latest version from Github, compiled myself it is working now. Thanks!!

with the new version there is only an warning poping up "The device reports a different protocolversion (7) than expected (8)." re-uploading the compiled .vnafw from the github-release does not change anything. Not an problem just wanted to let you know.

[jankae]

Please try the latest development version of the firmware, that should get rid of the warning: https://github.com/jankae/LibreVNA/suites/4876310671/artifacts/139354286

The firmware from the 1.2.1 release is missing the logarithmic sweep feature which required an update to the protocol.

[scott-guthridge]

The colon at the beginning of a command should never be required because each new command line is expected to start at the top of the command tree. The behavior where the SCPI interpreter remembers the branch and uses the established prefix if no colon applies only to "compound" commands, i.e. commands separated by semicolons on the same line. This is described in section 6.2.4 of the SCPI Syntax and Style volume found here: https://www.ivifoundation.org/downloads/SCPI/scpi-99.pdf

There are several other deviations from the SCPI standard that took me a while to work through. One is that non-query commands are not supposed to return output, neither blank lines nor error messages. I had to read and discard many blank lines in my program. The standard error and event reporting commands ESE, ESE?, ESR?, :EVENT? are missing. Some other SCPI required commands are also missing: CLS, OPC?, RST, SRE, SRE?, STB?, TST?, *WAI.

The most challenging problem I found to work around was that OPC? doesn't wait for a VNA acquisition to finish, so a :VNA:TRACE:TOUCHSTONE? command following the OPC? gives empty output. I had to write a polling loop in my program that keeps sending and checking the :VNA:ACQ:FIN? query to wait for data after sending a :VNA:ACQ:SINGLE trigger -- not too efficient.

The TOUCHSTONE command should probably be renamed to something else as it doesn't really return Touchstone format. S12 & S21 are in row major order even if you ask for them in Touchstone v1 2-port column-major order, and if you don't ask for all four S parameters, it's missing fields. SCPI has recommendations for standard way to request and return array data.

I think the programming interface would be more valuable if it had a conforming SCPI interface. At least it would have saved me time in being able to adapt some of my many existing SCPI scripts to work with the LibraVNA. I would volunteer to help with that if desired.

[jankae]

The behavior where the SCPI interpreter remembers the branch and uses the established prefix if no colon applies only to "compound" commands, i.e. commands separated by semicolons on the same line.

Agreed, the required colon is due to a misinterpretation of the standard by me. I think I will just remove it and make it conform to the standard here.

There are several other deviations from the SCPI standard that took me a while to work through. One is that non-query commands are not supposed to return output, neither blank lines nor error messages.

Certainly a deviation from the standard but one that is intentionally there. I don't quite like sending stuff "into the dark" and would prefer to always get some sort of reply. I guess you could argue that it is a TCP connection which has an implicit ACK anyway, so maybe this is not needed. I am a bit hesitant to adjust the behavior because it would break existing scripts.

The standard error and event reporting commands ESE, ESE?, ESR?, :EVENT? are missing. Some other SCPI required commands are also missing: CLS, OPC?, RST, SRE, SRE?, STB?, TST?, *WAI.

Yes (although OPC is implemented as you mention further down). Most of these commands seem a bit pointless to me since I do not keep track of events or a status byte. *RST may be worth implementing but I am not sure what the default state should be (this has been discussed a few times).

The most challenging problem I found to work around was that *OPC? doesn't wait for a VNA acquisition to finish

My understanding is that OPC waits for the last operation to complete, not necessarily the whole acquisition. If you use OPC after starting a sweep, it means that the "start the sweep" command has completed (i.e. the sweep has indeed been started). It doesn't say anything about the status of the acquisition. Again, I sort of wouldn't even know when a acquisition is complete. I guess with a single sweep and no averaging it is simple. But what about continuous sweeps? Would *OPC ever return in that case? What about averaging? Would it return after the first pass or should it wait for all required averages?

I guess you would like something like :VNA:ACQ:FIN without polling?

The TOUCHSTONE command should probably be renamed to something else as it doesn't really return Touchstone format.

This may deserve its own issue but I'll try to answer here. Based on a simple test I just did, I believe the command is working as it is supposed to. When you execute the command it literally creates a touchstone object based on the traces you specified and transforms it into a string (with linebreaks). This string is then returned to you. The exact same function is used when you export a touchstone file through the GUI. Unless this is also broken I find it hard to believe that the SCPI command does not return a valid touchstone format.

S12 & S21 are in row major order even if you ask for them in Touchstone v1 2-port column-major order

The order of the traces depend on the order with which you give them to the touchstone command. Internally, they are just traces and the touchstone command does not really care whether you use a S12 measurement in place of S21. If you specify the parameters according to the programming guide in this order :VNA:TRAC:TOUCHSTONE? S11 S12 S21 S22 you should get a 2-port touchstone file with the usual S11 S21 S12 S22 order in each line. Personally, I have never encountered a (2-port) touchstone file with a different order.

and if you don't ask for all four S parameters, it's missing fields

According to the programming guide, you must ask for a square number of traces/parameters. Typically, this would be the 4 S parameters for a 2-port touchstone file. But you can also ask for just S11 which will give you a 1-port touchstone file. And you could also ask for 9 or 16 parameters which will give you 3-port/4-port touchstone files. Any other number of traces is invalid and should result in an ERROR being returned instead.

SCPI has recommendations for standard way to request and return array data.

The touchstone command is not my recommended way of extracting trace data. That would be the :VNA:TRACe:DATA command. The touchstone command exists because someone requested it (instead of manually creating the touchstone file from the extracted data). I don't particularly like that command because it breaks another of "my" SCPI conventions: Usually a command response is ended by a newline. In the touchstone command, the response includes multiple newlines and (apart from a timeout) there is no clean way of detecting the end of the response.

I would volunteer to help with that if desired.

Sure, I always appreciate help. The most useful thing is probably what you already did: point out problems and suggestions how to implement it better. I guess I have a blind spot sometimes when it comes to this.

Of course you could also help with the implementation itself. For most smaller changes it is probably faster if you just precisely write down what you expect to happen and what happens instead. Usually I am pretty fast with implementing bug fixes when I have a good description and can replicate them. In some cases, I may take more time to think whether I want to perform a certain change (e.g. removing the empty responses to SCPI commands).

And obviously you can jump into the code as well if you want to. I am always happy to accept pull requests. The likely starting point in this case is the SCPI class: https://github.com/jankae/LibreVNA/blob/master/Software/PC_Application/LibreVNA-GUI/scpi.h

Also: if you would like to continue the discussion about SCPI (or specific other things), please open new issues for that. I would prefer to have each topic covered by its own issue instead of a long thread in some older (already closed) issue which I am likely to forget about.

[scott-guthridge]

I'll follow up with some specific suggestions.  Would you prefer this to be in the form of an issue or a discussion?

Scott Message ID: @.***>

[jankae]

Issues for stuff you think is a bug or should be implemented differently for sure, discussions if you have more general questions. I'll get notifications for both but open issues are a bit more prominent on the repo. With discussions it may happen that I forget about them when there is no activity for a while