Here's a few more plots, this time of a longer data set (3 minutes or so @ Brianza in the BT20) with the default smoothing level of 9. Interestingly this shows something in the timing that the earlier plots didn't - the consistent spiking in the timing. The bottom plot is zoomed in to one of the spiky areas of the middle timing plot. Edit: Yes, I spun off into the grass at the end!
Nice one Ade! If you like this, have you seen the other technical analysis I did on rF2 which I posted here just a few days ago? It should be right up you wheel house! http://isiforums.net/f/showthread.php/14482-rFactor2-FFB-Technical-Analysis Also, I'm too slow; I was about to ask you if the plugin is called at full 400 Hz rate, but apparently it is. On the FFB command timing variation, I can confirm that is seen also in the FFB controller, check the linked thread. On the observed integer ms, USB full speed operates at integer ms intervals for I/O data units, so with a full speed FFB controller you either have 2 or 3 ms for 400 Hz, which averages to exactly 2.5 ms over time (see the linked thread). If the Win USB driver stack for your wheel operates in a synchronous manner, you will see the same in the Win application code - in this case your plug in. What wheel are you testing with? BR,
Ha, I actually thought I was posting in that other thread and got very confused when I couldn't see all your plots when I scrolled back up after posting. Now it all makes sense, there were two threads! That's very interesting about the synchronous operation, thanks. I'll go take another read of your other thread when I get a chance. I was testing with a G27.
Heh, no I should probably not have created a new thread for the latest analysis, but I did not think as far when reposting it here... :S I am pretty sure the G27 USB driver stack is asynchronous in operation, so the reason you see integer ms intervals I think is due to ISI. Somewhere they seem to use a a low resolution timer (i.e. integer ms only), which affects plug in timing. BR,
