From: Will K. <wil...@gm...> - 2011-02-25 02:59:12
|
Greetings, I have been working on a personal computer controlled kiln control project in ubuntu, and am running into the following problem: Situation: 1. I have a tenma thermometer I want to use to monitor my kiln from linux, it has a basic windows application that retrieve's the current temp from the usb connected tenma. 2. After the windows application completes the handshake the device begins transmitting temp data, and continues to do so even after the application is exited. (which is great in the sense that in Linux I think I just need to get through the handshake and sit back an listen to the data after that) 3. I have successfully snooped the usb traffic for the handle shake and believe the new linux app is attempting to send the handshake to the device. Problem: 1. The efforts to send the handshake in linux fail: Handshake (in array form that I shoot to a perl usb output function): my @requests = ( [ 0x80, 0x06, 0x0200, 0x00, 0x29, 100000 ], [ 0x21, 0x0a, 0x0000, NULL, 0x05, 100000 ], # Returns error code -2, invalid value. [ 0x81, 0x06, 0x2200, NULL, 0x65, 100000 ], [ 0x21, 0x09, 0x0300, NULL, 0x05, 100000 ], ); I believe the problem with the 0x21 call is described over a couple of pages in this thread here: http://libusb.6.n5.nabble.com/Error-sending-control-message-No-such-file-or-directory-td6201.html The over all suggestion of that thread is you modify the usb core to permit calls of this type, and recompile the kernel. The server will really only be for interacting with the kiln thermostat and a relay control board, so I don't mind following that custom kernel path. However, I am unable to figure out the method for doing so from looking at the source files. Would anyone care to point out the changes needed to enable usb communication with this windows only usb hardware device? (or any existing linux flavors that permit more promiscuous usb communication) Thanks - Will Kirchheimer |
From: Alan S. <st...@ro...> - 2011-02-25 16:15:52
|
On Thu, 24 Feb 2011, Will Kirchheimer wrote: > > > Greetings, > > I have been working on a personal computer controlled kiln control project in ubuntu, and am running into the following problem: > > Situation: > > 1. I have a tenma thermometer I want to use to monitor my kiln from linux, it has a basic windows application that retrieve's the current temp from the usb connected tenma. > 2. After the windows application completes the handshake the device begins transmitting temp data, and continues to do so even after the application is exited. (which is great in the sense that in Linux I think I just need to get through the handshake and sit back an listen to the data after that) > 3. I have successfully snooped the usb traffic for the handle shake and believe the new linux app is attempting to send the handshake to the device. > > Problem: > > 1. The efforts to send the handshake in linux fail: > > Handshake (in array form that I shoot to a perl usb output function): > > my @requests = ( > [ 0x80, 0x06, 0x0200, 0x00, 0x29, 100000 ], > [ 0x21, 0x0a, 0x0000, NULL, 0x05, 100000 ], # Returns error code -2, invalid value. > [ 0x81, 0x06, 0x2200, NULL, 0x65, 100000 ], > [ 0x21, 0x09, 0x0300, NULL, 0x05, 100000 ], > ); This is a little hard to interpret since you haven't labelled the columns. I assume the first three columns are bRequestType, bRequest, and wValue. And the last column looks like a timeout. What about the fourth and fifth columns? Somehow they should should encode wIndex, a buffer address, and a buffer length. Is the fifth column supposed to be wIndex? The first line in the list looks like a regular Get-Config-Descriptor request. It probably isn't needed, although it won't hurt. (But why does it have 0x00 in the fourth column instead of NULL?) Also, the 0x65 in the third line looks suspiciously different from the rest. Maybe it should be 5. > I believe the problem with the 0x21 call is described over a couple of pages in this thread here: > http://libusb.6.n5.nabble.com/Error-sending-control-message-No-such-file-or-directory-td6201.html You're talking about the second line in the list above, right? It appears to be a standard HID Set-Idle request. Can you post the output of "lsusb -v" for this device? > The over all suggestion of that thread is you modify the usb core to permit calls of this type, and recompile the kernel. The server will really only be for interacting with the kiln thermostat and a relay control board, so I don't mind following that custom kernel path. However, I am unable to figure out the method for doing so from looking at the source files. That thread talked specifically about bRequestType = 0x22, which you aren't using here. Therefore it is not relevant. > Would anyone care to point out the changes needed to enable usb communication with this windows only usb hardware device? (or any existing linux flavors that permit more promiscuous usb communication) You should use usbmon (see Documentation/usb/usbmon.txt in the kernel source) and compare its output with your Windows snooping. Alan Stern |
From: Tim R. <ti...@pr...> - 2011-02-25 17:57:06
|
Will Kirchheimer wrote: > > I have been working on a personal computer controlled kiln control > project in ubuntu, and am running into the following problem: > > Situation: > > 1. I have a tenma thermometer I want to use to monitor my kiln from > linux, it has a basic windows application that retrieve's the current > temp from the usb connected tenma. > 2. After the windows application completes the handshake the device > begins transmitting temp data, and continues to do so even after the > application is exited. (which is great in the sense that in Linux I > think I just need to get through the handshake and sit back an listen > to the data after that) > 3. I have successfully snooped the usb traffic for the handle shake > and believe the new linux app is attempting to send the handshake to > the device. > > Problem: > > 1. The efforts to send the handshake in linux fail: > > Handshake (in array form that I shoot to a perl usb output function): > > my @requests = ( > [ 0x80, 0x06, 0x0200, 0x00, 0x29, 100000 ], > [ 0x21, 0x0a, 0x0000, NULL, 0x05, 100000 ], # Returns > error code -2, invalid value. > [ 0x81, 0x06, 0x2200, NULL, 0x65, 100000 ], > [ 0x21, 0x09, 0x0300, NULL, 0x05, 100000 ], > ); You have a HID device. The first request is a standard GET_DESCRIPTOR command to fetch the configuration descriptor. The second request is a HID SET_IDLE request. The third request is a HID GET_DESCRIPTOR request to fetch the report descriptor. The fourth request is a HID SET_REPORT request, sending a command to the device. That's probably the only important one. The reason this fails is because the standard HID driver has already claimed the device. You need to tell Linux to release that device so you can claim the interface yourself. It's interface #0. > I believe the problem with the 0x21 call is described over a couple of > pages in this thread here: > > http://libusb.6.n5.nabble.com/Error-sending-control-message-No-such-file-or-directory-td6201.html > > The over all suggestion of that thread is you modify the usb core to > permit calls of this type, and recompile the kernel. No, no, no. You are hearing hoof steps in the hallways and thinking "zebras" instead of "horses". A few minutes of investigation would have shown you that this was a HID class device, and the rest should have fallen out from that. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
From: Peter S. <pe...@st...> - 2011-02-25 18:59:37
|
Tim Roberts wrote: > .. the standard HID driver has already claimed the device. You > need to tell Linux to release that device so you can claim the > interface yourself. Alternatively please use HIDAPI instead of libusb when you are dealing with a HID class device. libusb is intended for devices which do not have a kernel driver that knows how to talk to them. HID class devices have the HID class driver. And HIDAPI can talk to the HID class driver on Mac OS, Linux and Windows. You can also use libusb to do the same thing, but as Tim explains you will then have to deal with how each operating system assigns kernel drivers to devices. It seems that on Mac OS it is now impossible to use libusb instead of HIDAPI. So better not waste time on libusb with HID. It's not designed for it, and it's not a good fit. > > The over all suggestion of that thread is you modify the usb core > > to permit calls of this type, and recompile the kernel. > > No, no, no. I agree with Tim. Any advice to introduce odd exceptions to a kernel must be taken with a whole fist full of salt. :) It would be a very special case. It's not a good idea. Try HIDAPI and you should be fine. //Peter |