Update frequency for IMU

[gb2111]

Hello.
I was testing examples and they seem to use a high CPU. My idea is that if there is no data they create "empty" iterations.
After adding some code seems like I can get 300 FPS which of course is not easy to schedule on Windows.
I wonder if number 300 is something you can confirm or it might be something specific to my PC?
Thanks.

[nitsch]

I wonder if number 300 is something you can confirm or it might be something specific to my PC?

The controller's internal update frequency (for both ZCM1 and ZCM2) is roughly 180 Hz, I believe. Polling it faster than that would not yield any new values, i.e. psmove_poll() returns 0.

[gb2111]

Thanks for reply @nitsch . I am testing example.c file. Added some code to check FPS separately when I have returned zero or non-zero. I am using timeGetTime function and count how many I can get in one second.
When I have one device I have about 580FPS. When I have 2 devices I have about half of that, which is in practice 280FPS. Those numbers are not fixed and can vary even by 10-20. So can vary even 40 between min and max. No info about dropping frames what seem to be good indicator.

Then I see also about 5000000 fps for non-pooled values that is causing quite a overhead for CPU. The fans go loud immediately.

I changed code to disable noblocking and got only 'proper' values with same FPS. But there was no 'zero' calls from psmove_pool(). My CPU was almost idle and fans quiet.

@thp
I wonder if you would see it useful to have some flag to allow 'blocking' code or better just some timeout to give CPU idle time before waiting for new data. That seem relatively simple and I could do that part if you agree.
If I missed anything where this is already in place then sorry for that :)

[nitsch]

I don't think there is an option yet for blocking vs. non-blocking (or even ansync) reads. But it may be useful. If you want to add that to the library, just go ahead. Contributions are always welcome.

[thp]

Feel free to make a pull request. The example code, however, usually has the right way to do it -- for integrating sensor readings over time, you want to poll until it returns zero, and process every event, if you just care about the "latest" values, just poll until it returns zero, and then process only the last event (throwing away all in-between values, as they are "old data" anyway).