Closed NolanNicholson closed 1 year ago
Thank you very much for testing. I'm surprised to see that we are getting packet size of 128, that would mean, that there are at least 128 clock impulses. Very strange. Could you please try to reduce the length of the trigger from 15µs to 10µs, or even less? Will this change anything?
I prepared a branch with some changes, which could help. It would be cool, if you'd try that one: #54
Hi, does this issue apply to Sidewinder FFB Wheel as well? I just connected mine today for the first time. Wasn't able to use it yet as I got different results on getting it connected/recognized (on Linux btw).
May be, yes. It could suffer indirectly due to some timing changes. @creopard was so kind to provide an SW FFB joystick and I'll try to find some time soon to take a look. If you want, you can try an older version. Would be interesting to know where exactly the problem first happened.
Thanks to @creopard I could fix the timing issues. I tested the code with FFB Pro, 3D Pro and GamePad. All work fine and I didn't spot any regressions. The FFB Pro gets now detected properly with the new readID() function to distinguish it from the Preciosion Pro. @creopard would you like to test it with your Precision Pro? Also @EXTgithub99cd2, is it possible for you to try this code on your wheel? Unfortunately, there seems to be currently nobody there, who else has the wheel.
The fixed code is on the branch: https://github.com/necroware/gameport-adapter/tree/sw-ffb-pro I will merge it as soon as I have your feedback.
I would love to try, but I'm not that savvy yet. Any instructions how to get the code from here to the device? Its been a while.
@EXTgithub99cd2 just download the files from the sw-ffb-pro branch and open the .ino file with the Arduino IDE. Compile, upload and (hopefully) have fun: https://github.com/necroware/gameport-adapter/tree/sw-ffb-pro/firmware/gameport-adapter
OK. Let me check with the supplier if this is a real arduino or compatible here, I didn't build it myself.
It's easier, if you download the whole project as a zip and then navigate to the folder, which @creopard mentioned. Otherwise you would need to download each file separately, at least I don't see a button to get them all at once. You can find the related branch archive here: https://github.com/necroware/gameport-adapter/archive/refs/heads/sw-ffb-pro.zip
@creopard would you like to test it with your Precision Pro?
The Precision Pro still works as expected 👍
The Precision Pro still works as expected +1
@creopard thank you very much. So, looks like at least we have no regressions. If the wheel will work, it would be a nice side effect, but it is not related to this ticket. @EXTgithub99cd2 if the wheel is still not working, we should open a dedicated issue.
I merge this one into the main branch then.
I will have to test this later on the SW FFB wheel. Compile in IDE succeeded, but I can not upload to the board at this moment, local problem. If it doesn't work on the FFB Wheel I will open an issue. Thanks for the support so far.
For completeness. Though not a technical test. I have it working as a user on both Window 10 and Linux without problem. Only issues I have are OS and/or application level and are outside the firmware.
(Sorry I've been off for a little while since submitting the PR for this device! I thought this issue was specific enough to merit a separate issue from the general SW FFB Pro support one, but feel free to merge them.)
Since the consolidation of the packet-reading code around the readBits() function, the adapter can no longer read packets from the Sidewinder FFB Pro. Instead, a packet size of 0 is repeatedly returned, and I'm having trouble figuring out exactly why.
If I re-add the
cooldown()
call to readPacket, and change the if statement inreadBits()
tom_clock.isHigh() || m_clock.wait(Edge::rising, wait_duration
, the packet size is either 0 still, or maxed out at 128.If I then also restore the trigger behavior from before, where the trigger is setHigh at the start of reading the packet and then setLow at the end of reading it, then the packets always max out at 128.
I don't think the reduction in the wait duration from 250 to 100 is the issue; I tried reducing it to 100 in my working version, and it still worked.