Hi - I received my New 3DSXL w/capture card installed a little while back and tested it out on a Windows system using the driver/software combo hosted on this site with no issue. However, I'm a full time Linux user and bought this card knowing that I would likely need to create my own solution in order for it to work on my system. I'm aware that the CuteCapture UNIX software exists but that it's incompatible with the newly released board, so I figured I would try to determine what the differences are by running some tests. I wrote a small user space driver that attaches itself to the device by VID and PID in order to access the 2 interfaces/4 endpoints that it employs. Since the single bulk input (endpoint 2 on interface 1) was failing to transmit any data on request, I figured that this new board was similar to the previous one in that it first requires a vendor specific control request be sent before it starts capturing any data. Looking at the CuteCapture software, the previous board's control request for this is as follows:
Code: Select all
bmRequestType: 0x40 (DEVICE | VENDOR | HOST_TO_DEVICE)
bRequest: 0x40 (Vendor defined value.)
wValue: 0
wIndex: 0
wLength: 0
With 0x40 being an invalid bRequest for the new board, I had to determine which values are actually defined to it (results posted below). Since the bRequest value is only a single byte, I looped though all values from 0 to 255, passing no wValue or data buffer, just to see which requests would succeed/timeout.
Unfortunately, something I didn't expected could happen occurred when bRequest 0xcf was issued. I first noticed that the device was no longer connected and found that a different device was now present on my system with the same VID (0x0403) but different PID (0x601e). Here are some noticeable differences between the device descriptors for the two:
Code: Select all
idProduct: 0x601f Myriad-RF LimeSDR-Mini -> 0x601e
iManufacturer: 1 3DS Capture -> 1 FTDI
iProduct: 2 N3DSXL -> 2 FTDI SuperSpeed-FIFO Bridge
iSerial: 3 nxl126054 -> 3 000000000001
(Configuration 1)
wTotalLength: 0x003f -> 0x0069
bmAtrtributes: 0x80 (Bus Powered) -> 0xe0 (Self Powered/Remote Wakeup)
MaxPower: 200mA -> 96mA
(Interface 1)
bNumEndpoints: 2 -> 8
All endpoints are identical to how they were previously except there are now 6 additional endpoints (3 pairs of bulk in/out) on interface 1.
Much to my disappointment, this change has occurred on the device itself, evident by the fact that it shows up this way when connected to other computers and no longer works on the Windows system that I originally tested it on. My guess is that issuing the 0xcf vendor control request with no wValue/data initializes the board to its generic configuration, overriding the custom configuration implemented for 3DS data capture. I'm not actually all that knowledgeable about hardware, but since the PID decremented from 0x601f to 0x601e, it's as if its logically a different device now.
I'm now wishing that I had come here first to ask if anyone could provide the vendor defined controls implemented in firmware rather than poke around and attempt to reverse engineer them myself.
Instead, now I'm left wondering if there's any way that a control request could be used to reconfigure the board back to the way it was. I tried a few things with no luck, but it would be practically impossible for me to do anyway if specific data needs to be transmitted to the device in order to do it. In any case, I'm wondering if there's any chance I can get some assistance with this absolute fiasco that I've gotten myself into. Any help would be greatly appreciated!
--------
Test Results:
bRequests 0x03, 0xcf, and 0xdf appear to be the only vendor defined control requests for the device, each working for both 0x40 (write) and 0xc0 (read) bmRequestTypes.
0x03 is valid for all wValues (0 - 65535) in both directions and anticipates a data transfer since it timeouts if no buffer is provided.
0xcf *shakes fist* is valid in both directions when wValue 0 is passed with no data buffer or wValue 1 is passed with a data buffer. This causes the device to disconnect and reconnect likely due to the fact that it's being reconfigured.
0xdf is valid for wValues 0 and 5 - 65535 in both directions when no data buffer is passed but doesn't appear to do anything as far as I can tell. wValue 1 is valid for a read request and wValues 2 and 3 are valid for a write request each when a buffer is passed.
At this point, I was planning to eavesdrop on the data transfer while the device was running on Windows using the provided driver/software to see what I could glean from the packets being passed, but since my board has effectively become nonfunctional, I never actually got to try this out unfortunately.. :[
