HID Report Descriptor over VISA

[Intaris]

I'm trying to interface to a HID over VISA (WinXP) and I'm having problems getting the HID Report Descriptor.

I'm using VISA 4.1.

I'm able to get the Device, Configuration (including Interface, HID and Endpoint descriptors) and some other descriptors no problem.

As soon as I try to target an Interface instead of the Device for a Query, it doesn't work.  I order toquery the HID Report descriptor (Usage pages and so on) I need to make a request as following:

Recipient: Interface
Request Type: Standard
Direction: Device->Host
Request: 0x6 (GET_DESCRIPTOR)
Value: 0x2200
Index: 0x0
Length: 0xfe

Using exactly these settings, the Windows driver is able to ge the HID report descriptor, but over VISA I just can't.   The problem isn't thatnothing's coming back, my USB sniffer doesn't even register an outgoing request!  It seems that my VISA installation isn't passing the Interface request to the device......

 Setting Destination to Device instead of Interface works in that a request is registered by my sniffer ptogram.  Obviously nothing is returned because it's a faulty request.

Anyone able to offer hinst as to what the problem is?

Bug in VISA?

Shane.

[Intaris]

I'll try again:

When I attach a HID device, I can observe the traffic over the USBport via a USB sniffer (Device monitoring studio).

GThe HID Report request is executed without error with the following response:

 05 01 09 00 A1 01. 85 01 09 01 A1 00 05 01 09 30
 09 31 09 35 16 00 FE 26 FF 01 35 00 46 FF 03 75
 0A 95 03 81 02 C0 75 01 95 02 81 01 05 09 19 01
 29 0C 15 00 25 01 35 00 45 01 75 01 95 0C 81 02
 05 09 15 01 25 03 09 0D 09 0E 09 0F 75 02 95 01
 81 20 75 01 95 02 81 01 75 02 95 06 15 00 25 02
 05 08 19 4B A1 02 19 49 A1 02 09 3C A1 02 09 41
 09 3D 09 40 B1 60 C0 C0 C0 75 02 95 01 15 00 25
 02 05 08 19 4B A1 02 19 48 A1 02… 09 3C A1 02 09
 41 09 3D 09 40 B1 60 C0 C0 C0 75 01 95 02 B1 01
 85 02 75 08 95 01 15 01 26 FF 00 35 01 46 FF 00
 66 01 10 55 02 09 45 B1 60 09 46 B1 60 C0
Setup Packet

 81 06 00 22 00 00 FE 00
.."..þ.
Recipient: Interface
Request Type: Standard
Direction: Device->Host
Request: 0x6 (GET_DESCRIPTOR)
Value: 0x2200
Index: 0x0
Length: 0xfe

We see that the request is registered on the USB port, and a response (which makes sense when interpreted according th HID guidelines) is returned.

Trying to do exactly the same thing via VISA apparently does not result in a request being sent to the instrument.

Why?

We see from the setup packet that the first entry is 0x81, which corresponds to

Recipient: Interface

Request type: Standard

Direction: Device->Host

A request with value 0x80 (Recipient DEvice instead of Interface) is sent correctly.

Can VISA make requests over VISA RAW connections directed to an Interface?

 Shane

Message Edited by Intaris on 01-20-2009 03:13 AM

Message Edited by Intaris on 01-20-2009 03:13 AM

[SFK]

Hello Shane,

I just received the confirmation from the VISA product support: as you already assumed, NI-VISA is not designed to communicate directly with the USB host interface.


If you think that this feature should be implemented in one of the future VISA versions, please file a corresponding request at NI's Product Suggestion Center at http://digital.ni.com/applications/psc.nsf/default?OpenForm.

Best regards,
SFK

[Intaris]

No no, I think you misunderstood the problem.

A USB device (mouse, USB Stick, whatever) has three different possible communication Targets in a pretty simple hierarchy.  First is the Device itself which is required for enumeration (Configuration descriptor and so on).  The second is an Interface, each device must support at least one.  Here any class to which the device belongs is defined (HID, Mass Storage and so on).  Third is the Endpoint.  All three of these are part of the USB DEVICE not the USB host interface.

Part of the specification for the HID device class requires the software to be able to find out the format of the HID report (A description of what the data being sent back via Interrupt transfers actually MEANS).  For a mouse of joystick this is largely irrelevant, but there are many devices out there for which this is required.

In order to retrieve this information it is necessary to talk with the current INTERFACE of the DEVICE, not the host adapter. This is a request for information from the DEVICE about the capabilities and configuration.

My problem arises when I try to access the so-called "HID Report Descriptor".  Please see pages 48 and 49 (Printed page numbers, not PDF page numbers) of the HID specification.

Issuing this request over USB does not trigger any actual communication to the device (remember, the interface in question is part of the device, not the host controller).  It should, but it doesn't.

I have sent a VI with my report via product support, it will be necessary to install a mouse as a RAW device to use this program.

Regards

Shane

[Intaris]

Just an update:

the problem is not with a standard HID report descriptor request.

I have a piece of hardware I was using for testing (from Microisoft) which, despite identifying itself as a HID, does not see fit to adhere to the HID standard.  Standard HID requests work fine when the device supports them.

The problem remains however that many USB commands generate no error AND no bus traffic which seems odd.  There are several command combinations which don't seem to make it past the actual VISA driver..... Some of these may be failing on the Status stage of the transfer, but some kind of error or warning should be produced if this is the case........

Problem is being investigated.

Shane.

[SFK]

Hi Shane,

my colleagues from R&D requested me to ask you if you could specify the HID device that you are using and give us a sample piece of the VISA code that you wrote.

Additionally - have I understood correctly that the interface request that you send works with a standard HID device (e.g. a mouse)?

Best regards,
Sebastian

[Intaris]

No problem,

The device is a "Microsoft Sidewinder Stratregic Commander", I don't they're manufactured any more.  It's a great device for testing (theoretically) because it has multiple axes and buttons.....

Unfortunately it does not adhere to the proper HID standard, typical Microsoft.  The device seems to require some kind of "activation" which my usb sniffer records as a request with some reserved bits set.  I don't seem to be able to reproduce this or the request to the Interface which follows (Request to the Interface as per HID spec page 49 - see below).

The problems seem to be more or less device-specific at the moment.  I have implemented more code since I filed the problem report and I have been able to access the endpoints of the device directly (Set_Feature, Clear_Feature).  Since there are currently no Features defined for an interface, I have not been able to directly test this.

I am teaching myself USB communication and I think page (printed page index) 49 of the HID 1.1 specification had me confused for a while.  It describes how to call a "HID Class Descriptor".  This says to target the Interface as a communications target (bmRequestType 10000001).  I understood this to relate to the request of a HID report descriptor, but that request seems to work fine when the Device is set as the communications target.  If I try to do this (with a normal Logitech mouse - HP branded) with a HID, the same request to the Device works fine (bmREquestType 10000000), but to the Interface does not (bmRequestType 10000001).  I don't know at this stage what validity the aforementioned "HID Class Descriptor" call has at all since this would appear to me to be the only usage for it.  This is kind of getting into the nitty-gritty of the USB protocol, but I am trying my best to use the Official USB spec to guide me.

I'll try to send some code later today to illustrate the problem.  Maybe someone with more experience programming low-level USB can tell me if this is expected behaviour or not.

An additional "problem" is that many requests (some generarated simply for testing) do not return an error yet also do not lead to any communication on the bus (According to me USB sniffer).  This part I don't understand and was the reason for my original wording of my problem.  Again I'll try to get some code together to illustrate this problem.

Regards

Shane O'Neill

[SFK]

Hi Shane,

thanks for the update. How is your investigation going? Are you still working on the code example you intended to post?

Best regards,
Sebastian

[Intaris]

No code organised yet,

I'm very busy with another project at the moment.  Deadline coming up tomorrow and then I'm off for a well-earned break for a week.

I've since been told by a local AE that NI doesn't support third-party hardware and so for them the topic is closed.  I don't agree because it seems there may still be problems with the VISA communication interface itself.  I need to do some more testing (Whenever I get time) and I'll be able to update then.

I don't want to post something which is just gonna have NI wasting their time.

Shane.

[SFK]

Shane, hi,

I was wondering if you had the time to continue testing yet. My colleagues from R&D are quite interested in your code. Can you at least give us an example of the function calls you used and what data you expected them to return?

Best regards,
Sebastian