Preferred USB Device Class for Test Equipment - Page 1
Forum section: electronics / testgear

author: NF6X
author_rank: Unknown
timestamp: October 22, 2015, 06:30:43 pm
content: I'm developing a piece of test equipment with a USB interface, and I'd like to see some opinions about the preferred USB device class that engineers would like to see it implement. This particular item will be a temperature measurement interface, but that's not especially relevant to my questions here.This piece of equipment will have a USB interface, and will support Linux, Mac OSX and Windows. However I implement it, I'll provide Python bindings to support it. I can think of at least three choices for the device class it would implement:1) USB TMC (Test & Measurement Class): This is an obvious choice because it has "Test & Measurement" right in the name. Some sort of software layer would be needed to talk to it, whether they're the Python code I provide, some other code like python-ivi, etc. As I understand it, I'll need to provide a signed INF file for Windows users. Low-level communications would likely involve libusb.2) USB CDC (Communications Device Class): Making the device look like a serial port has the advantage of letting a user talk to it with any old dumb terminal program, without any custom software at all. All of the targeted operating systems already support CDC devices, but I'd still need to provide a signed INF file for Windows machines to get the usbser.sys driver to talk to it. The protocol might be SCPI or something arbitrary, but that's a separate consideration from what device class is used.3) USB HID (Human Interface Device): The main attraction of this choice is, if I'm not mistaken, that no INF file is needed under Windows. Custom software would still be needed like in the USB TMC case, most likely using hidapi at the low level.So, what do y'all think about these trade-offs?

author: bson
author_rank: Unknown
timestamp: October 23, 2015, 12:36:11 am
content: USBTMC.

author: Lukas
author_rank: Frequent Contributor
timestamp: October 23, 2015, 09:45:59 pm
content: Definitely USBTMC. It's used by all serious test equipment manufacturers and makes your instrument integrate well with the existing software infrastructure (VISA). With an USBTMC driver installed, all USBTMC equipment effectively becomes plug'n play.

author: NF6X
author_rank: Unknown
timestamp: October 24, 2015, 04:36:17 am
content: USBTMC does seem like the way to go after more research and consideration. I'll probably duct-tape together a very dumb CDC implementation for my initial hardware bringup since my microcontroller vendor has already done 90% of the work in their example application code, but then I'll implement proper USBTMC firmware before the product leaves my Secret Laboratory.Hmm, maybe I should get my hands on at least one piece of off-the-shelf test equipment with a USBTMC interface so I can get experience with USBTMC from the other end of the cable. In particular, I want to get a feel for working with USBTMC devices under OSX, which doesn't include a native USBTMC driver (I think).

author: Karel
author_rank: Super Contributor
timestamp: October 24, 2015, 07:18:34 am
content: Quote from: NF6X on October 24, 2015, 04:36:17 amYou probably already know this but still, one advice. When your usbtmc implementation is ready, use a script or a small programto send, very fast, random different (valid and invalid) SCPI commands to your device and check it for stability.There are a lots of bad implementations of SCPI in tm equipment that behave badly when you want to use it in another way then it was tested during design.

author: NF6X
author_rank: Unknown
timestamp: October 24, 2015, 07:38:50 am
content: That sounds like good advice. And when I can't break it any more, then I can ask for some beta testers to help me find the bugs I missed!