Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
Okay, so contrary to what I said in HCWP tonight, I still think I'm missing something about controlling the haptic feedback in my GameCube Controller -> USB adapter.

As far as I can tell, the only packets going from Host -> the adapter during normal operation (e.g., excluding about 12 packets of setup with asking for descriptors and what-not) are Set_Report packets of the form either:

Code:
0x21,0x9,0x0,0x2,0x0,0x0,0x2,0x0
or
Code:
0x21,0x9,0x0,0x2,0x1,0x0,0x2,0x0

depending on which of the ports of the adapter my gamecube controller.

According to http://www.beyondlogic.org/usbnutshell/usb6.shtml and page 52 of http://www.usb.org/developers/hidpage/HID1_11.pdf and Wireshark, this corresponds to a device request with:

Code:

bmRequestType = 0x21
bRequest = 0x09 # SET_REPORT
wValue = 0x0200 # ReportID = 0, ReportType = 0 (Output)
wIndex = 0x0001 / 0x0000 # The port I'm plugged into
wLength = 0x0002 # Report_Length


However, as far as I can find anywhere, there's no report data that follows. Can anyone make suggestions for debugging / understanding what's going on here? What are the characteristics of the packet I should be looking for? Is there a reasonable chance that USBPcap missed something?
Geekboy asked for the logs. If anyone else is interested, they are here.
So my digging around (nothing solid to support this hunch up other then my own digging sadly) is that the response packet is more of an ack then anything and the data returned is just data to have there.

Now I did some searching inside the raphnet gcn -> usb adaapter and it shows that it uses set_report to handle the force-feedback and it does it in a loop kinda grossly. Which makes me feel even more its just a required ack because they are not even looking at the data as far as I can tell
Well it wasn't the response packet I was concerned about so much as the fact that the the request packet claimed it was sending a report to the device of length 2, and doesn't appear to be doing that at all.

I suspect you may be right that it's just a cheapo non-spec following adapter or something, but it's still weird.
Ok What it is, is its a length of data to be sent _IF_ there is a data phase. But it seems there is not? It seems set_report is just used to turn the motor on or off? I would open it up with python as a usb device and see what sending data to it does. Thats the best I can suggest otherwise just ignore it? It seems they are just relying on the request to actually handle turning it on and off or something like that.
There has to be something I'm missing here. I got PyUSB set up and can read button presses intelligibly, but am not getting an sort of rumble response when I write the control packets that should be corresponding to the set-report above. Do I actually need to read the response and status packets it's sending back?
At that point I am afraid I have no clue :/ I would say bring it with you to maker fair and I could help you debug there but who knows if we will have the time to do that at all Razz

Honestly though I have no idea :/
1-year necrobump: there is definitely something weird going on. I've figured out how to turn on the rumble, and I do need to send 2-byte data packet. I think the first byte is rumble strength, but I still can't find where it's being sent, or what else is happening. Moreover, the adapter appears to be stateful rather than relying on any sort of USB PWM (as we previously suspected from the vast amounts of set reports taking place), because if my program exits prematurely (without sending a rumble-off packet), it keeps going.

I still can't find any of these packets in my logs though, so it was mostly just a lucky guess that got me here.
Okay, screw Wireshark. I got a Windows VM setup with VMWare Player, and am using it to capture USB traffic. Apparently modern VMWare releases have log throttling, so this tutorial doesn't quite work verbatim, but the author has since made some updates to parse modern log formats, and has a tip for working around the the throttling issue. We'll see how this goes.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement