February 12th, 2020 at 6:04 AM
Read over some of the docs for the programs they mention in the description (vJoy driver and vJoySerialFeeder)
I'm having trouble finding exactly how the 40Hz is determined and the manual isn't very helpful. Of course yeah 40Hz is decently fast, better than the framerate I get in most games on this old HP, but I still think that a cheap arduino clone can outperform it.
From what I've gathered, UJI only sends serial data. Of course it does, because there's no other real way to transmit data over USB. That data is read by vJoySerialFeeder and then fed to the device driver (vJoy) which then actually does something with that information (i.e. making your game display move on the x-axis or whatever.)
Now, there are 6 possible protocols that are supported by SerialFeeder, the only notable ones are IBUS, DSM, and SBUS, and from what I've gathered online, IBUS is the most commonly used one for people tinkering with joysticks and homebrew controllers, which is coincidentally what UJI lists as its protocol of choice. IBUS does all kinds of processing and formatting for making 'packets' as well as checksums so that the data can actually be verified and interpreted by the above programs, at least from what I can make out from SerialFeeder's GitHub files. I also see that the example Arduino sketch they use is using a baudrate of 115200 for actual data transmission, so I'm going to assume that's what SerialFeeder uses by default, and by extension, to ensure compatability with SerialFeeder, that's what UJI uses by default.
So let's do some math:
Seems a little high for a single packet of data, and the ibus headers/source don't look like they're going to be transmitting that much data at once.
I can't imagine a packet of data contains more than like 20 bytes or so, just in general for checksums, analog values and whatnot.
So theoretically, the device should be able to send up to 720 IBUS packets as an approximation. Don't quote me on numbers since most of this is (educated?) guesswork.
So I'm assuming most of the delay comes from SerialFeeder actually passing the data to vJoy and then vJoy actually doing something. Don't know which one is slower, but my guess is SerialFeeder just because I'm biased against serial as a whole
And at that point, I can't imagine that an arduino device would somehow perform worse by any means. From what I can make out in the photo, the UJI uses a (PIC)16F688 (Microchip) processor which is only capable of 8MHz clock at most, half the speed of most Atmel ICs, including the 32u4 and 328p.
Yeah. More inputs and it could be a good choice, especially considering form factor, but 15 quid is quite the markup for canucks like me when a chinese nano clone costs 2$ lol
I'm having trouble finding exactly how the 40Hz is determined and the manual isn't very helpful. Of course yeah 40Hz is decently fast, better than the framerate I get in most games on this old HP, but I still think that a cheap arduino clone can outperform it.
From what I've gathered, UJI only sends serial data. Of course it does, because there's no other real way to transmit data over USB. That data is read by vJoySerialFeeder and then fed to the device driver (vJoy) which then actually does something with that information (i.e. making your game display move on the x-axis or whatever.)
Now, there are 6 possible protocols that are supported by SerialFeeder, the only notable ones are IBUS, DSM, and SBUS, and from what I've gathered online, IBUS is the most commonly used one for people tinkering with joysticks and homebrew controllers, which is coincidentally what UJI lists as its protocol of choice. IBUS does all kinds of processing and formatting for making 'packets' as well as checksums so that the data can actually be verified and interpreted by the above programs, at least from what I can make out from SerialFeeder's GitHub files. I also see that the example Arduino sketch they use is using a baudrate of 115200 for actual data transmission, so I'm going to assume that's what SerialFeeder uses by default, and by extension, to ensure compatability with SerialFeeder, that's what UJI uses by default.
So let's do some math:
Code:
#Converting bits to bytes
#Represents bytes transmitted in one second
115200 / 8 = 14400
#For a polling rate of 40Hz...
14400 / 40 = 360I can't imagine a packet of data contains more than like 20 bytes or so, just in general for checksums, analog values and whatnot.
Code:
14400 / 20 = 720So I'm assuming most of the delay comes from SerialFeeder actually passing the data to vJoy and then vJoy actually doing something. Don't know which one is slower, but my guess is SerialFeeder just because I'm biased against serial as a whole
And at that point, I can't imagine that an arduino device would somehow perform worse by any means. From what I can make out in the photo, the UJI uses a (PIC)16F688 (Microchip) processor which is only capable of 8MHz clock at most, half the speed of most Atmel ICs, including the 32u4 and 328p.
Yeah. More inputs and it could be a good choice, especially considering form factor, but 15 quid is quite the markup for canucks like me when a chinese nano clone costs 2$ lol
