12

I am porting an app that I originally wrote using the accelerometer for IOS 3, to incorporate the new IOS 4 motion capabilities.

While capturing motion, the application does little else - no graphics updates for example.

I'm doing the following to set up motion updates, as a replacement for my previous use of the accelerometer. I do realize that I could rebuild to do my own polling using NSTimer or something, and may pursue that yet.

[motionManager setDeviceMotionUpdateInterval:updateInterval];
CMDeviceMotionHandler motionHandler = ^(CMDeviceMotion *motion, NSError *error) {
[self processMotion:motion withError:error];
};

[motionManager startDeviceMotionUpdatesToQueue:[NSOperationQueue currentQueue] withHandler:motionHandler];

This works, but the update interval doesn't behave as expected. I've stripped out all execution code in the processMotion method, except for saving off timestamps in order to see what the real motion update rate is. I've tested this enough to prove to myself that it's repeatable, even the strange result for 1/40. The table below shows what I'm seeing:

updateInterval  actual events per second
1.0/20.0        13
1.0/30.0        27
1.0/40.0        27
1.0/50.0        34
1.0/60.0        40
1.0/70.0        57
1.0/90.0        60
1.0/100.0      74

Some notes:
1. i'm sure that the update interval is being set properly, and have checked it after setting to confirm.

2. I'm sure that I'm tracking every call of processMotion, there aren't any calls being made with nil CMDeviceMotion or other strangeness

3. I'm not doing any significant processing that would block things, just waiting on motion events and recording them. This all worked perfectly fine as a delegate for the accelerometer

4. the motion data is good, just too infrequently updated :)

5. this is using ios 4.2 on an ipod touch 4th gen

6. I've searched as best I can, haven't seen an explanation, though i have seen some reports of people seeing 50hz update frequency when requesting 60hz, which could be related.

The next thing i'll try is setting up a dedicated queue for the processing instead of using the current queue, however I did want to see if this was a known behavior. I could understand if the update rate was bottlenecked somehow, but not sure why it would still scale up as shown if that was the case.

Again, I suppose I could rebuild to use NSTimer and do my own polling, but I'd like to understand why i'm seeing this, in case i'm fundamentally misunderstanding the Core Motion framework.

J.Spiral
  • 475
  • 5
  • 10
  • Exactly what I found out with a similar approach on iPhone 4. It seems like there are still some bugs in CoreMotion. – Kay Feb 17 '11 at 20:52
  • thanks for the note, maybe i'll just use 1/90 and change to 1/60 if the timestamps show the rate is as expected... dirty hack though – J.Spiral Feb 17 '11 at 21:30
  • 2
    Just a quick update on this, I switched to polling driven by NSTimer, results are generally better but there are occasions where I get the same sample value twice in a row. Will keep experimenting. – J.Spiral Feb 18 '11 at 20:36
  • Missed your reply 4 days ago. Might be a racing condition problem, if timer is faster than core motion, expecially when core motion does not deliver events as expected. – Kay Feb 22 '11 at 20:19
  • yes, however it's fairly infrequent and since I can always check timestamps, things are ok for me. Will be interesting to see if this improves in the future or if new info comes to light. – J.Spiral Feb 23 '11 at 19:24

1 Answers1

3

Okay, here's a possible solution:

Number of concurrent operations on NSOperationQueue are determined by the OS. That means it sometimes can be very few or even 1 operation at a time.

You can explicitly set the number of operations to a certain reasonable number, e.g.

[operationQueue setMaxConcurrentOperationCount:5];

Enjoy.

Usman.3D
  • 1,791
  • 3
  • 16
  • 27
  • very interesting. i've long since moved on from that project and don't have a dev environment handy to test quickly, but it seems that people check this every now and again. if a couple people want to confirm this, i'll accept it, otherwise will have to wait until i get some time to set up a test of my own. – J.Spiral Jan 19 '12 at 20:20
  • Hey J.Spiral, was my answer of any help? You never responded. :) – Usman.3D Mar 20 '12 at 10:59
  • 1
    Sorry, took me forever to get back to it! – J.Spiral Mar 31 '12 at 01:22