Hardware: simple utility for send hex commands to usb device

Hardware: simple utility for send hex commands to usb device - Printable Version

+- Forums (https://www.vdrift.net/Forum)
+-- Forum: Community (https://www.vdrift.net/Forum/forumdisplay.php?fid=3)
+--- Forum: General Discussion (https://www.vdrift.net/Forum/forumdisplay.php?fid=8)
+--- Thread: Hardware: simple utility for send hex commands to usb device (/showthread.php?tid=848)

Pages: 1 2 3 4

Hardware: simple utility for send hex commands to usb device - avl - 12-29-2007

Good morning everyone!

I'm found good tips for tweak my logitech g25 wheel.
thanks eckzow and anrp:
http://vdrift.net/Forum/viewtopic.php?t=412&postdays=0&postorder=asc&start=60

So, I'm not found any solution for sending hex strings to device and write small command-line utility for this in python.

This utility just works for me and, may be, for you Wink

ftp://srv.l14.ru/pub/usbtool-0.1.tar.gz

Build dependices: libusb, swig (for build python libusb wrapper)

Just unpack tarball and run build.sh

Run dependices: libusb, python

start python usbtool or ./usbtool --list for help

- thelusiv - 12-30-2007

Thanks for writing this, I have just been playing with my Logitech Driving Force Pro under Linux for the first time. My steering wheel is limited to 200 degrees as the G25 is by default.

I tried running the program you provided but have no success with my wheel. Here's the output I get:

Code:
thelusiv@deuxeau:~/code/usbtool-0.1$ sudo python usbtool -d 046d:c294:0 -v f810

Send command f810

opening device

alt setting 0

Traceback (most recent call last):

  File "usbtool", line 159, in <module>

    dev.write(buf)

  File "/home/thelusiv/code/usbtool-0.1/usb.py", line 273, in write

    res=usb.usb_bulk_write(self.iface.device.handle, self.addrout, data[:min(len(data), self.outsize)], timeout)

KeyboardInterrupt

After "alt setting 0" it hangs until I Ctrl+C to kill the program. This may have something to do with me not having a G25...I get the same thing if I run it with any of the commands listed.

I have a little free time over the next week, I may be able to figure out what to send the DFP to remove the steering limit. Has anybody got any tips on how to figure this out? I don't have a Windows install anywhere but I have a spare (slow) machine, I suppose I could use it to do some investigating...

- avl - 12-30-2007

What say
python usbtool --list
?

I think, You forget to rebuild libusb-wrapper.

execute next commands:

rm _libusb.so libusb.py*
./build.sh

- thelusiv - 12-30-2007

Code:
thelusiv@deuxeau:~/code/usbtool-0.1$ sudo python usbtool --list

List devices:

046d:c294:0 Device G25 (normal mode) found!

[.... my other USB devices (mouse, keyboard)]

I tried removing the wrapper, and rebuilding as per your suggestion. The program has the same result though, hangs after "alt setting 0". Sad

It's strange that the DFP and the G25 have the same USB id...My controller is actually a Driving Force Pro but the program recognizes it as a G25 because of this.

- avl - 12-30-2007

thelusiv Wrote:
Code:
thelusiv@deuxeau:~/code/usbtool-0.1$ sudo python usbtool --list List devices: 046d:c294:0 Device G25 (normal mode) found! [.... my other USB devices (mouse, keyboard)]

I tried removing the wrapper, and rebuilding as per your suggestion. The program has the same result though, hangs after "alt setting 0".

It's strange that the DFP and the G25 have the same USB id...My controller is actually a Driving Force Pro but the program recognizes it as a G25 because of this.

No it's not strange.
G25 have 3 different mode.
"normal mode" is emulation for standard logitech wheel (4 axis and 12 buttons)
But g25 have 6 axis and 19 buttons, so "normal mode" is not native for g25.

I think, Logitech Driving Force Pro have another contrrol sequences.

- thelusiv - 12-31-2007

So my DFP is similar to the G25 in "Normal mode"?

Does anyone know of a Windows program to monitor traffic over the USB bus?

- avl - 12-31-2007

thelusiv Wrote:So my DFP is similar to the G25 in "Normal mode"?

yes.

thelusiv Wrote:Does anyone know of a Windows program to monitor traffic over the USB bus?

usbsnoop

http://benoit.papillault.free.fr/usbsnoop/

- thelusiv - 01-03-2008

Thanks, I might get some time to inspect this in a week or so.

- thelusiv - 02-09-2008

Well, it took a lot longer than a week or so. But I finally spent some time setting up an older machine as a Windows XP test box. Using it I ran usbsnoop and logged what it did as I played with the slider that sets the steering wheel axis range. However it often seems that nothing happens in the log when I move the slider and commit the changes. It only logs when the device is restarted. Thus I have a hard time telling which of the packets might be the one that sets the axis range...

- thelusiv - 02-21-2008

Well, turns out that there is more than one version of usbsnoop. The one you linked seems unrelated to the open source one which I was using before, and the old one by the Wingman Team. Here's a page that kinda describes them all:
http://mxhaard.free.fr/snoopy.html

Using the one you suggested, it dumps out a very long file...how do you go about parsing it?

- thelusiv - 02-21-2008

More progress on this front...I finally got a good usbsnoop.log and parsed it with grep and less. Turns out that the commands to set the wheel range are the same for the DFP as they are for the G25. I see the value

Code:
0xf8818403000000

go by when the wheel is set to 900-degree mode, and

Code:
0xf8812800000000

when the wheel is set to 40-degree mode.

Now the big question is, why didn't this work for me when I tried it with my DFP before? I guess it's time to try it again, but will have to wait, I'm tired...

edit: here are some formulas for setting the axis-range on the DFP/G25. The command is prefixed by four bytes "f881", followed by four bytes representing the range value, followed by 6 bytes of 0-padding. The 4-byte range value can be found via the following formula (converting the result to integer and expressed as hex):

Code:
range_value = (degrees - 40) * (23555 / 860) + 10240

For example, the range_value of 600 degrees would be

Code:
range_value = (600 - 40) * (23555 / 860) + 10240 = 25578

The formula for finding the range in degrees for a given range value is thus:

Code:
degrees = (range_value - 10240) * (860 / 23555) + 40

and an example, range_value of 33795 (0x8403) degrees:

Code:
degrees = (33795 - 10240) * (860 / 23555) + 40 = 900

edit 2: most of the above info is crap, good info follows...

- thelusiv - 03-14-2008

Finally, I have made some progress getting my Logitech Driving Force Pro wheel working on Linux. I found this information from a contact at Logitech who has requested to remain unnamed. He has disclosed to me some information regarding the Logitech Driving Force Pro and G25 steering wheels.

First off, the DFP and G25 identify themselves as USB VenderID/ProductID 0x046d:0xc294 when they are first plugged in. This is the ID of the original Driving Force or Formula Force wheel, and when identifying as this ID the wheels are in a backwards compatible legacy mode, essentially emulating the DF. In order to use all of the features in the DFP and G25 they must be sent a command to switch them to their native mode. The command for DFP native mode is [0xf8, 0x01], and the command for G25 native mode is [0xf8, 0x10]. The G25 can also operate in DFP legacy mode using the DFP native mode command.

Once sent this native mode command the wheels can be sent other commands to change features such as wheel axis range. The DFP takes two commands for range switching. [0xf8, 0x02] switches the wheel to 200 degree mode, and [0xf8, 0x03] switches the wheel to 900 degree mode. The G25 also accepts these commands with similar results. Note: actually, I have found that at least in the case of the DFP, it will accept the range commands before being set into native mode.

The G25 also accepts the range setting mechanism I was trying to reverse engineer in the post above. The command is actually formulated like:

Code:
int16_t range = 900  // 16-bit integer representing degrees to set range to

command = [0xf8, 0x81, range & 0x00ff, range & 0xff00, 0, 0, 0]

Now here's a bit of confusion. The Logitech Windows drivers and Profiler accept this command for the DFP and translate it into the regular DFP commands and sets 200 or 900 mode. This makes it seem that the DFP firmware accepts the G25 commands, which it does not. This is all the traffic seen, however, when using USB Snoop[y] on Windows with the DFP. To get around this, one must use regedit to change a value in the Windows registry at:

Code:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\USB\Vid_046d&Pid_c298\*

Once this is located you must assign rights to your user to those nodes, then edit the "LowerFilters" key in each of the nodes. Where you see "WmHidLo usbsnoop" or "wmhidlo usbsnoop", reverse the order so that usbsnoop comes first. Now the output of USB Snoop[y] will show the actual commands sent across the bus to the DFP instead of just what the Logitech drivers "allow" to be seen.

Back to the topic of the DFP, I have tested out setting the wheel in 900 degree mode on Linux. First off, as I posted above I never could get avl's usb tool to work for my wheel. I finally figured out that if I plugged the wheel directly into one of the USB ports on my computer instead of the USB hub on my monitor, the "usbtool" program worked just fine. Once I figured this out, I was able to successfully send it commands to switch to native mode, 200 degree mode and 900 degree mode.

When the wheel is plugged in, a device /dev/input/js1 is created (js0 is my gamepad). When I send it any command, this device disappears. I thought at first this was because of the switch to native mode; that since the device simulates a USB unplug/replug and shows up as a different device ID not supported by the joydev driver, it does not recreate the js1 device. However, the js1 device also disappears if I only send it the [0xf8, 0x03] command to switch to 900 degree mode (which seems to work even if not in native mode).

Clearly, some changes need to be made to the Linux joystick driver to properly support the DFP and G25. In addition to the above mentioned problem of the disappearing joystick device, in order to change from a combined gas/brake axis to separated independent gas/brake axes, the driver must add "virtual axes", this is not provided by the wheel devices' firmware at all.

I'll be contacting the linux-input folks with this information soon and hopefully some progress can be made towards better support for the DFP and G25 in Linux. After consulting them for direction I hope to work on a patch and some user-land tools to easily change settings on the wheels.

- rm - 03-17-2008

By chance, does anyone know the USB command sequences to switch a Thrustmaster wheel's pedals from combined to separate axis mode? Currently the driver sees the wheel as a 3-axis device, but the "Z" value always stays at zero, and both pedals just control the "Y" value.

- thelusiv - 03-17-2008

rm Wrote:By chance, does anyone know the USB command sequences to switch a Thrustmaster wheel's pedals from combined to separate axis mode? Currently the driver sees the wheel as a 3-axis device, but the "Z" value always stays at zero, and both pedals just control the "Y" value.

Hi and welcome. I don't know much about a Thrustmaster, but if it's like the Logitech wheels, then there is no command to do this. The kernel driver must provide the extra axis.

- rm - 03-17-2008

Thank you.
I went to WinXP and got a capture of USB events at the moment of switching pedals from combined to separate. I think it's worth a try to poke the wheel with some of these codes and see if the third axis becomes active.

Tried to build usbtool-0.1. The packages I had to add to my Debian AMD64 system: swig, python2.5, python2.5-dev, python-usb, libusb-dev.

The program seems to compile fine, but does not run. It seems to be a problem with 64-bitness of the OS.

Code:
$ ./build.sh 

/usr/include/usb.h:330: Warning(302): Identifier 'usb_device' redefined (ignored),

/usr/include/usb.h:242: Warning(302): previous definition of 'usb_device'.

$ python ./usbtool 

Traceback (most recent call last):

  File "./usbtool", line 13, in ?

    import usb

  File "/r/hdd/s/src/usbtool/usb.py", line 13, in ?

    import libusb as usb

  File "/r/hdd/s/src/usbtool/libusb.py", line 7, in ?

    import _libusb

ImportError: /r/hdd/s/src/usbtool/_libusb.so: undefined symbol: Py_InitModule4_64

If I edit build.sh and add -m32 to the gcc line, it does not compile at all:

Code:
$ ./build.sh 

/usr/include/usb.h:330: Warning(302): Identifier 'usb_device' redefined (ignored),

/usr/include/usb.h:242: Warning(302): previous definition of 'usb_device'.

In file included from /usr/include/features.h:354,

                 from /usr/include/limits.h:27,

                 from /usr/lib/gcc/x86_64-linux-gnu/4.2.3/include/limits.h:122,

                 from /usr/lib/gcc/x86_64-linux-gnu/4.2.3/include/syslimits.h:7,

                 from /usr/lib/gcc/x86_64-linux-gnu/4.2.3/include/limits.h:11,

                 from /usr/include/python2.5/Python.h:18,

                 from libusb_wrap.c:118:

/usr/include/gnu/stubs.h:7:27: error: gnu/stubs-32.h: No such file or directory

In file included from /usr/include/python2.5/Python.h:57,

                 from libusb_wrap.c:118:

/usr/include/python2.5/pyport.h:750:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."