Has anyone reverse engineered the TekVPI interface?

[Weston]

I have been looking at medium voltage differential probes and current probes and there are a number of cases where the probe with the TekVPI interface are significantly cheaper than an equivalent probe with the TekProbe (can be used on any scope with an adaptor) or normal BNC output.

There is a lot of documentation on TekProbe with many scope manufactures selling adaptors and a few online projects where people have built a converter box. I can find nothing similar about TekVPI, the closest I can find is this: https://debugmo.de/2010/03/probe-hacking-part-1/

Based on that persons documentation, it seems that TekVPI has a rather similar setup, with an I2C eprom. From some other reading online it seems that sometimes the probe is configured over I2C for things like gain or input range, but that still seems like it would not be hard to figure out based on some logic analyzer sniffing.

The fact that I cant find anything detailed online and no company sells an adaptor makes me think it must be more complicated. Do I have some misunderstanding? Is there some patent on TekVPI that would stop a company from selling an adaptor? It seems like the financial incentive is there and the interface has been around for a while.

[tmbinc]

Hey!

It's not complicated, but unfortunately not well documented either. It's all essentially I2C-based, and the protocol is pretty much the same as TekConnect, but the form factor is different.

Details from the protocol can probably be found by disassembling the scope firmware. Especially good is the old version of the DPO5xxx/7xxx-Software that still has PDBs, or even the DPO4xxx or 5-series firmware.

I only have TAP-probes so unfortunately that's not a lot of value for sniffing, but I don't expect any issues for, say, replaying I2C transactions to configure the probe.

TekVPI is nice to interface because it only needs a bulk voltage, not differential voltages, as the probes generate the voltage themselves.

On the unfortunate side it's hard to get a socket, but maybe with 3D-printers that can be fixed.

[jake111]

I have been looking at medium voltage differential probes and current probes and there are a number of cases where the probe with the TekVPI interface are significantly cheaper than an equivalent probe with the TekProbe (can be used on any scope with an adaptor) or normal BNC output.

There is a lot of documentation on TekProbe with many scope manufactures selling adaptors and a few online projects where people have built a converter box. I can find nothing similar about TekVPI, the closest I can find is this: https://debugmo.de/2010/03/probe-hacking-part-1/

Based on that persons documentation, it seems that TekVPI has a rather similar setup, with an I2C eprom. From some other reading online it seems that sometimes the probe is configured over I2C for things like gain or input range, but that still seems like it would not be hard to figure out based on some logic analyzer sniffing.

The fact that I cant find anything detailed online and no company sells an adaptor makes me think it must be more complicated. Do I have some misunderstanding? Is there some patent on TekVPI that would stop a company from selling an adaptor? It seems like the financial incentive is there and the interface has been around for a while.

The TekVPI probes integrate themselves into the channel menu when attached, letting you know on-screen when the current probe jaws are not closed, when compensation is needed, and allowing you to change parameters of the probe (i.e. gain and zero level on the voltage probes, initiate degauss on current probes, etc. ).  I don't recall anything in the menus that seemed like it was being handled exclusively on the scope side, with the exception of autozero for some probes, there might be some feedback there.  The older TekProbe current probes (like TCP202) have a potentiometer wheel that allow you to adjust your zero but on the TCP0030A it's just a button, there could be feedback from the scope in this case?  Not sure.

3D printing a socket should be feasible, the mechanical properties for a dongle will be less important because you don't need to hold the weight of the probe body securely against the scope, just maintain contact for ground + the 5 pins for power and communication.

Take note that there are two generations of TekVPI, the later one has a little ear on it that sticks out and the associated scope interface has a notch towards the upper right side, I believe this is mostly for the new generation passive probes (TPP series) which according to Tek are incompatible with the analog front end for the older TekVPI scopes, but I never verified this.

[tmbinc]

Yes - the new passive probes allow the scope to perform probe compensation. Not all scopes support this so hence the additional notch.

FWIW, the chip at least of the TPA-BNC wasn't locked (AVR). It would also be an option to read out the firmware and reverse the functionality that way, but with an I2C dump of course that would be way easier...

[Weston]

So it is just a I2C interface with no authentication or anything. Why are there third no party adapters then? Is it too fraught with IP issues?

Disassembling the firmware is a good idea.  What are you referring to by PDB? I searched the term online and could not find anything.

I have access to the DPO7254. I was considering making a flex cable to slip in between the scope and the TekVPI contacts so I can probe the I2C bus. If I decode enough transactions changing scope setting I could probably just replay them to the probe. Seems faster than disassembling the firmware but perhaps a bit less thorough.

[jake111]

Yes - the new passive probes allow the scope to perform probe compensation. Not all scopes support this so hence the additional notch.

FWIW, the chip at least of the TPA-BNC wasn't locked (AVR). It would also be an option to read out the firmware and reverse the functionality that way, but with an I2C dump of course that would be way easier...

Tek engineer told me it was more than compensation and that the TPP1000 would not be able to match to the original series DPO4000 even if we tried to modify it to do so - Any knowledge on this? I was always curious.  The TPP parasitics were about half the P6139x and always wondered if there was a way to make them work but didn't want to tear apart a TPP1000 from one of the newer scopes to find out 

[tmbinc]

PDBs are the "Program Debug Database", basically the detached symbol files that the compiler produces for debugging; some versions of the installer shipped them for scope.exe. 

With that, you get all sort of nice symbols around "VPI"/"Accessory"/"TekConnect" ("TC_*"). For example, the scope.exe embeds ROMs of a number of probes (TAP1500, TPABNC, TCP0030, P7313, P7380, tdp1500, TDP0500, P7225, P7520, TCP0150, TCP0020, TPP0500, TPP1000 and a few more) for an - apparently - integrated test suite.

Then there's Accessory::initAsTekConnect which calls EepromReadConfig::EepromReadConfig and then parses the eeprom contents.

It should also be possible to find the I2C writes for the various operations and events.

[Mechatrommer]

the eeprom on TPP0500 is 1-wire protocol, not i2c... https://www.eevblog.com/forum/testgear/can-tektronix-tpp0500-probe-be-used-with-non-tek-oscilloscopes/msg2985832/#msg2985832