For my research project, I wrote an app that makes the iPhone vibrate
when it faces north. Yet I have a problem. It takes a about a third of
a second for the iPhone to read the magnetic heading (from CLHeading).
The compass app has the same lag. Is there any way I can use code that
more directly accesses the data from the compass, so that I can make
the app read the heading faster? It's very important that I eliminate
the lag, if possible.
Thank you,
Rose
It may be possible to dig under the hood and find some private means of accessing "more raw" compass data but I highly suggest against it. Apple generally has reasonably good reasons for what they do, especially if it' appears to be impacting performance.
I don't know the specific components Apple is using in the iPhone magnetometer but many of these devices, esp. the cheap ones, have both an internal lag and a fair amount of noise. The time delay is partly due to averaging and oversampling to help with error correction.
One alternative that comes to mind would be simultaneously monitoring the compass and accelerometer (which reports much more quickly) to detect the lag between start of motion and direction updates. If you also track the mean rate of rotation (decaying average, maybe) you could use the lag to project actual heading ( i.e. 1.3s reporting lag * -35 degrees per second rotation means actual heading = reported heading + -45.5).
~jonathan
> --
>
> You received this message because you are subscribed to the Google Groups "Portland IPhone Developers" group.
> To post to this group, send email to pdxi...@googlegroups.com.
> To unsubscribe from this group, send email to pdxiphone+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pdxiphone?hl=en.
>
>
I suspect this is a hardware limitation of the magnetometer. They'll
never be instantaneous anyway (at least not the parts you'd find in a
phone). I notice in Compass that even movements after the first one
have roughly the same amount of delay before it is shown on the
display.
If you explain the need for making the lag time shorter, maybe we can
suggest alternatives.
B
The reason I need to eliminate or anticipate the lag is that I'm
testing the efficacy of a navigational aid that vibrates when it
points north. If it is indeed possible for the brain to learn to
process the meaning of the vibrations (and previous research shows the
brain can learn to process new sensory input quickly), the vibrations
must always occur when the user is facing north. If the device can
give the user a constant sense of north, then the device can improve
the user's sense of spatial orientation, which is one of the two most
important factors determining navigational ability—and the most
important factor for the blind.
I could try anticipating the lag by making the iPhone vibrate when
it's within a certain range of north at a certain speed. I'm sure
there's a calculation I could devise that involves the speed and the
heading, and when this calculation gives a certain value, the app
would make the iPhone vibrate. Do you think the accelerometer works
quickly enough?
Thank you,
Rose
You might want to try a sound that changes tone or interval as the user approaches facing north. This would allow the user to gradually correct until they are pointing north. It would also help mask the latency of the compass. To prevent it from being super annoying, you might want the audio cue to only play while a finger is on the screen.
Calvin
> For my research project, I wrote an app that makes the iPhone vibrate
> when it faces north. Yet I have a problem. It takes a about a third of
> a second for the iPhone to read the magnetic heading (from CLHeading).
> The compass app has the same lag. Is there any way I can use code that
> more directly accesses the data from the compass, so that I can make
> the app read the heading faster? It's very important that I eliminate
> the lag, if possible.
Don't try to eliminate the lag. You can't. Instead, combine data from the compass and the accelerometer.
You know you need a stable device for a third of a second. Maybe make it a half second to be safe. So help the user to hold the device steady for half a second. When you begin to register the compass heading, display an indicator to show the user how much longer he needs to hold the device steady.
After you have registered the current heading, track the rotational acceleration around the z axis. After holding the device steady, you know the initial heading, and you know the angular velocity is zero. So just integrate twice in order to find the change in angle around z. That's current compass heading. Every time the user has held the device steady for a half second, re-register the current steady to eliminate drift due to compounding error.
Good luck!
Dave Howell
Avatron Software