Afonso Teles

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.

Hi Rohika,

The sanitzation procedure is available on our website: https://www.tek.com/en/oscilloscope/csa7404b-manual/tds6000c-tds6000b-tds7000b-csa7000b-tds6000-tds7000-csa7000-series

Hi John,

I use Y'n = Yn*Ymult + Yzero in my scripts and it works as intended.
I've attached said script for your convenience. Line 73 has the relevant math.

Hi Eric,

That's normal, I'm getting very similar values with my P6248 and TDS784A at 100 mV/div.
At 10 mV/div I'm getting around 10 mVpp, without the probe I get about 2.5 mVpp (that's the noise from the scope itself), so let's say the probe itself adds about 8 mVpp.


You have to remember this probe is meant to be used for signals up to 1.7 Vpp (in 1x mode), so ~10 mVpp of noise is perfectly acceptable and it should be just fine for most Ethernet testing.
Additionally, the probe has a bandwidth of 1.7 GHz; if we recall that noise goes up proportionally with bandwidth (assuming it's white noise), then its high bandwidth will inevitably lead to much higher noise levels than your typical 500 MHz passive probe.

Hi Hans,

I haven't received an update no.
There's a very good chance this won't be changed as it's working properly, it implements a phase shift as commanded, but it should instead be done as a time delay, in my opinion. This would require a feature change which would break backwards compatibility for other users.

I'll let you know once I get a more definitive answer though.

Hi Thales,

I would suggest sending an email to bmc-international-csr@tektronix.com and they should be able to help you setup a repair for your probe tips.

Hi Anirudhh,

The connection reset error really make it seem like something with the network setup is wrong and not allowing the connection to go through.
Make sure eScope is configured for port 81 and that that port is not blocked by a firewall on your PC or network.