TSEP Kerberos:
Self-Certification Tool and More

Submitted by TSEP

Introduction
TSEP Kerberos is a hardware and software solution which was created to verify the functionality of a measuring device. This currently applies in particular to the LXI components of a device, because this was the initial spark to create such a test tool. The previous software solution for testing the LXI functionality required additional hardware, especially the choice of a suitable router that provided all the necessary parameters to configure, put many LXI testers in front of a great challenge. To solve this problem, TSEP has come up with a general hardware solution that not only solves the problems of finding individual hardware components, but also uses them to increase the level of automated testing for LXI functionality. Already during the development of the hardware, it was ensured that the components used can not only be used with regard to LXI tests but can also assume a general function in a test environment.

Kerberos Concept
First, you should take a closer look at the hardware of the TSEP Kerberos. The hardware includes all necessary components for testing. It contains several network interfaces. Two of which are routed to the outside, they serve to connect the client PC and the device-under-test (DUT). Another interface is only used internally to simulate another device in the test network. This is necessary, for example, when testing the 1588 protocol to determine whether a device can cope with multiple devices in the network.

These network interfaces are internally switched to achieve the appropriate combination for the selected test. This could be a peer-to-peer connection or a connection through a switch. In this context, it should also be mentioned that the hardware of the TSEP Kerberos is also able to independently disconnect the DUT from the network or to connect it to the network. This greatly increases the automation of tests. The built-in router also automates many tests, as any changes in router settings can be handled by the software.

Read more >>

IVI Web Forum Question and Answer:

USBTMC Gadget driver on Embedded Linux Board and Windows 7/10 Host viOpen Issue

Answered by Alan Copeland, Keysight Technologies
for the IVI Web Forum

Note:  Offering an IVI driver is a requirement for all LXI-conformant instruments, something you will find in the LXI Device Specification 2016, Section 6.1. The IVI Web Forum is hosted by the IVI Foundation.
It was created to answer the more practical questions that arise when using the IVI Drivers to program test systems. To see a list of the IVI Drivers, click here. To view this question/answer in the Forum, click here.

Question:

Hi All, I'm currently working on the device side function driver development for TMC gadgets. Based on my experience and reference from USBTMC Specification as well as a couple of example code from Google, I have developed this driver. Now I have one weird problem with my above USB TMC function driver, It works fine under Linux host but not in case of Windows host.
Case-1: Linux as host.
1) On embedded board load the g_tmc driver and it creates /dev/g_tmc0 device node. 2) Make a connection between Linux host and embedded Linux board. 3) On the Host side(Ubuntu 16.04), usbtmc class driver load automatically and /dev/usbtmc0 is also created well. 4) Command string also I can send from Linux host side like echo *IDN? > /dev/usbtmc0 5) on the device side /dev/g_tmc0 device file also give me a perfect output. I have attached snap of the same.
Case-2: Windows 7/10 as Host
1) On embedded board load the g_tmc driver and itcreate/dev/g_tmc0 device node.
2) Make a connection between Windows 7/10 host and embedded Linux board.
3) NI-VISA / IVI Shared component successfully detect my tmc gadget and I can see the device in my DEVICE MANAGER under Test & Measurement Class category.
4) Now If I run an example from Users/Public/Documents/National Instruments/NI-VISA/Examples/C/USB path of NI-VISA then viOpen and viFindRsrc function failed to open and find my device.
Questions:- Why is behaviour not same under the two different host? Why Windows 7/10 can detect my tmc gadget but NI-VISA fail to make a connection? What is the different between usbtmc class driver of vanilla Linux and NI VISA usbtmc driver?

Answer:

This is the point where you should put a USB protocol analyzer on the PC-side and monitor the communication. We've used USBlyzer pretty successfully in the past.

The Standard Request might be a generic USB 2.0 request. You should look at the USB 2.0 spec for details on the request if you don't see anything in the USBTMC spec about the transaction.

NI-VISA and Keysight VISA both use the IVI Foundation provided USB-TMC driver, which is ausbtmc.sys. It is installed as part of the VISA Shared Components package.

I have looked the USB packets in the USB analyzer software called FreeDeviceMonitorStudio.

As part of gadget driver response comparison on the same board, I have started g_serial service before goto debug g_tmc. And that ACM serial connection works perfectly. At startup Windows 7 can able to send "CLASS CONTROL REQUEST" and gadget device can answer it perfectly.

Now in case of g_tmc function driver,

After insertion of g_tmc module, windows can detect it and T&M(IVI) entry I can see in device manager. Now If I starting NI MAX and immediately watch in the USB analyzer software, I can see a couple of entry. I have debug that entry and say that Windows 7 send "STANARD REQUEST" instead of "CLASS CONTROL REQUEST".

Why Windows Can send "STANARD REQUEST"?

Underneath VISA is using ausbtmc.sys driver file. Is something wrong behind my NI-VISA?

For more comments, click here.

Thanks to all our readers.
Bob Helsel, Editor
www.lxistandard.org

Use the connection you already know!

New LXI Products

LXI Links