Afonso Teles

Hi Leo,

A binary block is a standard data type specified in section 8.7.9 of IEEE 488.2 (called a "definite length arbitrary block response data" there).

Here's a quick summary of how they work:

#nddddxxxxxxxxxxxxxx.............

Where # signifies the start of an arbitrary block, n is the number of digits in the length (in ASCII), d are the digits of the length (also in ASCII), xxxxx is your binary data (the format of which depends on your configuration).

Here's an example:
#215THIS IS A BLOCK

For more information please refer to the standard and the following examples: https://forum.tek.com/viewtopic.php?f=580&t=133570

Hi Siyuan,

I would suggest querying "data:source?" after you set it to make sure it's set to what you expect.

Hi Clayton,

The command for changing units is documented in the programmer's manual, it's SV:CH<x>:UNIts.

The Spectrum View command group lists many other commands, if you know of some commands that aren't listed there please do let me know and I'll try to get it fixed.

Yes, with the Time Overview window open, you can adjust the Offset and Length to change Spectrum or Analysis window.
This is more fully laid out on page 100 of the manual: https://download.tek.com/manual/SignalVu_PC-Help_EN-US-077-0720-18-Rev-A_077072018.pdf

From what you're asking, you probably want to adjust the Spectrum time.

Hi,

As the warning on the bottom left corner is telling you, the time overview is disabled when the RSA is sweeping. This happens when the bandwidth is over 40 MHz (which is the max real time bandwidth of the RSA306B).
So the solution is simply to reduce the difference between your start and stop to 40 MHz or less.

Hi Ovidiu,

Here's how you'd use it: filesystem:writefile "C:/test.txt", #215This is a test

The second argument is a "block argument" which is defined on page 2-9 of the manual.

Hi Ed,

I was able to replicate your -230 error when I had no signals being input into the FCA, which hints at the fact that it's probably caused by too long of a period between A and B, which leads to "stale data".
So, in between running your scripts the FCA is still trying to capture data but it's unable to, which creates this -230 error. You then catch this error next time you run your script.

In terms of a fix, what worked for me was to write *CLS at the start of my script to clear the error queue, and then proceed as normally.

I've attached my script for your convenience.

Hi Ovidiu,

If the setup file is currently on the scope, you can just use the recall:setup command to load it.
If it's not on the scope drive, you can transfer it to the scope using filesystem:writefile and then proceed with the above command.

Hi Max,

It's possible to change the position with the horizontal position knob, but I did not see a significant improvement, which kind of disproves my theory.

I talked with our product line team but we were unable to come up with a workaround. For now, that's just the way it is, there's a bit of delay when capturing in roll mode.

Hi Sam,

That sounds like a good reason to use raw sockets.

I try to steer most people away from raw sockets because it can cause some real headaches, but there are legitimate reasons to use them (mainly if your controller can't run a VISA or if speed is critical).