Afonso Teles

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).

Hi Sam,

The recommended way to remote control pretty much all of our instruments is to use a VISA (like TekVISA) which handles the connection details for you (USB, GPIB, Ethernet, etc) and gives you a robust protocol for communication. You can then use a library in your favorite language (like pyvisa for Python) to write programs that send and receive data through VISA.

For Ethernet specifically, if you don't want to use VISA (which is probably a mistake), then you can use what we call "raw sockets", which is not well documented and significantly harder to use. To do this you simply connect to the instrument's IP on port 4000, you can then send commands and receive back data, similar to a Telnet interface.

Hi Max,

This delay is caused by the fact that the TBS2kB isn't displaying the whole record length on the screen (you can see this at the top of the screen), which means about 0.5 to 1 s of record is off the screen to the right, which creates the delay you're seeing.
To reduce the delay I'd suggest decreasing the time/div.

Hi John,

query_binary_values() is a standard pyvisa function: https://pyvisa.readthedocs.io/en/latest/api/resources.html#pyvisa.resources.MessageBasedResource.query_binary_values

The encodings are explained on page 2-445 of the programmer's manual.
Indeed using RPB (positive integer) instead of SRI (swapped signed integer) would explain the issue you're seeing as one represents the waveform data as an unsigned integer and the other as a signed integer, leading to the shifting you're seeing.

Hi Michael,

I wonder if it's a power rail that has gone bad?
The fact you get partial failures across such different systems suggests to me that it's power rail that has dropped out or is badly out of tolerance, so that's what I'd check first.

NVRAM failures usually show up as the scope working fine with power on, but losing data once you power it off (as the NVRAM becomes volatile), so I don't believe that's your problem.