No, I connected directly to one of the computer's USB ports. Also, another piece of info, as long as I uncheck Misc-> Force Feedback in DCS Options menu, I seem to be able to go on forever without stick control dropping out but the stick stays limp due to DCS overwrite.
FFB appears to have something to do with the drop-out. The grounding issue sounds very plausible. I'll reduce the string and periodic effects to see if anything changes.
Thanks but I cannot take the credit. Credit should go to you, Propeler3D, and Washout! I just hacked my way through borrowing everyone's wisdom along...
@walmis Hi, I'm still trying to debug the DCS freeze issue even though that I have improved all of the ground and power supply connections. The USB controller is now directly connected to a 24V lab power supply and the freeze issue still persists. I use a program called Wireshark to capture the USB traffic in order to understand the underline activities that cause DCS to freeze. I notice on the captured data that at some point the URB interrupt from the host (i.e. DCS) is not acknowledged by the USB controller. Maybe either something times out or prolonged waiting on the ACK causes DCS to hang. Funny enough, unplugging the USB cable to the USB controller after freezing forces the corresponding ACK's to be finally sent so these ACK's have been in the buffer all along and just didn't get sent timely. Have you seen anything like this before? Please refer to the screenshots and captured data for detail. The relevant data packets are:
USB Host to Stick URB_INTERRUPT 64992 46.373221 IRP ID:0xffffd782f98bc010 66728 47.427333 IRP ID:0xffffd782fe1196e0 USB Stick to Host URB_INTERRUPT 78621 61.816345 IRP ID:0xffffd782f98bc010 78622 61.816350 IRP ID:0xffffd782fe1196e0
Ah Sh!t these USB issues are hard to debug. And yours is the first such case to my knowledge. Did you try running it through a usb hub? Also could you check the FFB board revision number for me?
I'm sorry to ruin your day. I'm like a magnet that seems to attract outliers. Anyway, I did try using a USB hub earlier as you suggested and observed pretty much the same freeze symptom. The revision of my Rhino FFB board is Rev. 1.2, dated 2022.06.02.
My motherboard provides USB 2.0, USB 3.2 Gen 1, and USB 3.2 Gen 2. So far, I only tried on multiple USB 3.2 Gen 1 ports and saw the issue. For some reason, I couldn't get your stress test program started. I kept getting this write error.
@walmis I got to play with your USB stress test program a bit more. I found out it could go for a long long time when the stick (i.e. motors) was not under any load. As soon as I moved the stick around, the USB error started to occur. Interestingly enough, the Wireshark capture shows the ACK from the endpoint was eventually sent but after 1 second instead of the typical 1 ms. The error check shows 'hid_write/WaitForSingleObject: (0x000003E5) Overlapped I/O operation is in progress.'. Apparently, time-out happens after the long wait, hence, the error. What do you think may cause this kind of delay in ACK from the endpoint?
One quick thing you could try is to isolate the PSU ground from the mains earth connection, other than that I'm baffled. Looked the code, USB driver is pretty simple, maybe errors occur on cable and are not recoverable. I could send you another board with a different MCU to test.
Is the power supply (+19 to 24V) ground tied to USB ground through a 0ohm resistor somewhere on the PCB that I can remove? If not, how do I separate USB ground from power supply ground? Thanks!
Thank you for your offer! Let me play with the current board some more. I actually enjoy learning stuff about the USB interface that I knew nothing about before. If, say, I still struggle in a few days, I'll take up on your offer. I'm willing to pay for the shipping to offset some of your cost.
You can completely disconnect the 20V (both positive and negative) from the USB board (the fan will not work then though) - that will break the GND loop. Or 2. remove the GND finger on the mains plug/or the earth wire from the mains lead that connects to the power supply input/or use a mains cable without grounding.
My +19 to 24V supply is a lab power supply, which has red(+), black(-), and green(chassis ground) terminals. My understanding is, since I'm connecting through red and black, I don't think the earth ground is part of the ground connection. Anyway, I did try tying +19 to 24V directly to the motors bypassing the FFB USB control board as you suggested and I still got the same USB issue. Looking closely at my build, I did notice the USB panel-mount connector that I got through Aliexpress does not have the shield tied to ground. I don't think it would matter but I would try to connect it to ground just to be sure.
Alright, it's not GND loop then, perhaps the USB wires go parallel and close with the power wires? You could try to add a ferrite to the USB wires. Or maybe try another power source? Man, you have a strange case there
Man, I agree with you that this is a real doozy. I tried AC outlets from different part of my house and from different circuit breakers. I also found a USB cable that had a built-in ferrite core and tried. All of the tried cases so far reproduce the same USB issue (occasional 1 sec ACK from endpoint). I haven't tried tying the shield of the panel-mount USB connector to ground (a somewhat difficult mod) but I'm skeptical that anything will be different. I'm close to the end of my wit unless you can come up with something else for me to try. I was in a process of building a home-made reflow oven but got distracted and didn't finish. I'm seriously considering completing this reflow oven project so that I can put the FFB control board in to reflow for a while just to see if my luck changes... Sigh...
Maybe the issue is the lab power supply. I know Chinese rebranded ones are very noisy. Maybe you can try a different one like a laptop power brick or one that uses a transformer. Worth a try?
I actually started out with a laptop power brick and noticed the issue. I thought it would be better by switching to a lab power supply but the problem persisted regardless of form of supply.
Thank you for your response! My motherboard is AMD based Asus Tuf Gaming X570 Pro WiFi. I finally had a chance to do the same test on my Intel based laptop and could not reproduce the issue. I updated BIOS and AMD's chipset driver for Windows 10 to the latest and turned off all USB power/standby/sleep/selective suspend settings as you suggested. I still see the same issue. Unfortunately, my laptop is not powerful enough for gaming so I'm pretty much stuck. Where did you hear about this USB thing with AMD motherboards? Is it something that people complained a lot in the past?