I would like an action to take place when the phone is stationary for 2 seconds. I've searched for ages around google and stack overflow. I discovered that "Accelerometer DidAccelerate" has been depreciated and that CoreMotion is the replacement. Everything I have seen has been to do with the 'shaking' motion. I've tried reading through apple's documentation but It just confuses me!
Basically, I want the app to detect that the g-forces on the phone have remained within a small limit for a certain amount of time (suggesting that the phone has been laid down on a table or something) and for it to call and instance or make the app do something.
Any help would be greatly appreciated.
It's similar to the problem described in Simple iPhone motion detect. The basic setup for CMMotionManager is described in the Apple docs like Mike Pollard stated in his comment. I recommend especially the Handling Processed Device Motion Data section.
What you then need is CMDeviceMotion.userAcceleration which contains the pure acceleration without gravity.
CMMotionManager *motionManager = [[CMMotionManager alloc] init];
// UPDATE: set interval to 0.02 sec
motionManager.deviceMotionUpdateInterval = 1.0 / 50.0;
[motionManager startDeviceMotionUpdatesToQueue:[NSOperationQueue mainQueue]
withHandler:^(CMDeviceMotion *deviceMotion, NSError *error) {
CMAcceleration userAcceleration = deviceMotion.userAcceleration;
double totalAcceleration = sqrt(userAcceleration.x * userAcceleration.x +
userAcceleration.y * userAcceleration.y + userAcceleration.z * userAcceleration.z);
// UPDATE: print debug information
NSLog (#"total=%f x=%f y=%f z=%f", totalAcceleration, userAcceleration.x, userAcceleration.y, userAcceleration.z);
// if(totalAcceleration < SOME_LIMIT) ...
Then proceed like codeplasma has described in his answer above.
Also be aware that the solution might not be precise if used in the underground, bus, etc. because of external accelerations.
You can do something like this:
CMMotionManager *mManager = [[CMMotionManager alloc] init];
if ([mManager isAccelerometerAvailable] == YES) {
__block float lastActivityBefore = 0.0;
[mManager setAccelerometerUpdateInterval:0.1];
[mManager startAccelerometerUpdatesToQueue:[NSOperationQueue mainQueue] withHandler:^(CMAccelerometerData *accelerometerData, NSError *error) {
double totalAcceleration = sqrt(accelerometerData.acceleration.x * accelerometerData.acceleration.x + accelerometerData.acceleration.y * accelerometerData.acceleration.y + accelerometerData.acceleration.z * accelerometerData.acceleration.z);
if(totalAcceleration < SOME_LIMIT)
lastActivityBefore = lastActivityBefore + 0.1;
else
lastActivityBefore = 0.0;
if(lastActivityBefore >= 2.0)
{
//do something
}
}];
}
Accelerometer will show some minimal acceleration even if your device is steady, so you should make a testing in order to determine SOME_LIMIT value.
Also be advised that you should have only one instance CMMotionManager class in your app, so you're better to put it in your AppDelegate and initialize it only once.
Related
So I have been designing an iOS game (in Sprite Kit) for a while now and just recently added a CMMotionManager to my project so that my character would be controlled by the tilt of the screen. It took some fiddling but I got it to work, and here's how I've implemented it:
In my initWithSize method I have
self.motionManager = [[CMMotionManager alloc] init];
self.referenceAttitude = nil;
Then, I've written methods beginMotionSensing and switchToLiveSensing. The first is intended to get an idea of how the phone is being held and the second starts the game itself. Using SKActions, I call the first method, wait a second, and call the second. They look something like this:
-(void)beginMotionSensing{
CMDeviceMotion *deviceMotion = self.motionManager.deviceMotion;
CMAttitude *attitude = deviceMotion.attitude;
self.referenceAttitude = attitude;
[self.motionManager startDeviceMotionUpdatesToQueue:[NSOperationQueue currentQueue] withHandler:^(CMDeviceMotion *motion, NSError *error) {
[self setNull:motion];
}];
self.motionManager.deviceMotionUpdateInterval = .3;
}
and,
-(void)switchToLiveSensing{
gameIsLive = YES;
[self.motionManager stopDeviceMotionUpdates];
[self.motionManager startDeviceMotionUpdatesToQueue:[NSOperationQueue currentQueue] withHandler:^(CMDeviceMotion *motion, NSError *error) {
[self captureRoll:motion];
}];
self.motionManager.deviceMotionUpdateInterval = .02;
}
So I had all of this set up and it was working great, until I added the ability to play the game more than once. Before this, I would simply have to close out of the app and quit the game when I lost. Obviously this became annoying so I added a "game over" scene, with the ability to go back and play the game scene again. The game scene is presented again like this:
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
SKTransition *transition = [SKTransition fadeWithColor:[UIColor colorWithRed:147.0/255.0 green:213.0/255.0 blue:216.0/255.0 alpha:1.0] duration:2.0f];
MyScene *gameScene = [MyScene alloc];
gameScene = [gameScene initWithSize:self.frame.size passedInFuel:100];
[self.view presentScene:gameScene transition:transition];
}
I had remembered someone saying something in a previous post about a singleton - the comment was directed at someone implementing a CMMotionManager. They had said something along the lines of, "you should probably make it accessible through a singleton if you are going to initialize your class more than once." Well, sure enough, that's what I'm doing now. I had forgotten about this until I was playing the game and noticed that suddenly the phone seemed to ignore my tilt and went along with it's own business, killing my character in the process. It hasn't happened since, but is clearly something that needs to be fixed.
Could someone help me implement this so-called "singleton"?
I'm not convinced this is the problem you had, as the CMMotionManager object should be released anyway when your SKScene goes away. Can you duplicate the problem by starting the game again quickly after it ends?
You could probably do it by adding a class method in your main view/navigation controller (which ever one stays around longest) to create a singleton and then make it available to your SKScene object.
e.g.
+ (CMMotionManager *)sharedInstance
{
static CMMotionManager *sharedCMMM = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
sharedCMMM = [[CMMotionManager alloc] init];
// Do any other initialisation stuff here
});
return sharedCMMM;
}
I am trying to establish a geofence for CLbeacons, which is like this :
a> Any beacon whose accuracy <= 2.5 metres of distance should get detected.
Now, when I place the beacons in about 7m distance apart both get detected. What is more shocking is that the accuracy sometimes goes like 15.70 m for the beacon (checked by running the Airlocate App), which happens randomly and thereby makes the geofencing thing impossible to construct.
I tried to apply the custom formula to calculate the beacon distance double accuracy = (0.89976) * pow(ratio,7.7095) + 0.111; where double ratio = rssi*1.0/txPower; but since the txPower for CLbeacons are not provided, the function depends on me providing a static value as txPower.
Can anyone guide as to how the geofencing for these CLBeacons should be constructed then?
You are correct in that the accuracy value of the beacon can fluctualte drastically over short periods. The way I handle this (we have a similar need to determining when devices have been returned to a base location) is a combination of two approaches: First, we are tweaking the power on our iBeacons to lower them so that the didDetermineState: delegate call does not get called to many times for entering and leaving the beacon's range. Second, my iBeacon model keeps track of the accuracy for any beacons in range and averages them out. That way someone walking in between the device and the beacon, or the user turning the device a particular way won't cause the huge fluctuations in the accuracy value, messing up your logic.
I don't believe Apple intended developers to use iBeacons as indoor geolocation. The geofencing aspect of it is to simply adjust the transmit power so that you can get notified of when your device can detect the signal or not. The accuracy can be used, but it is so inaccurate it should be used with caution.
There is a developer that claims to have developed an algorithm for using iBeacons for indoor positioning, but I have not experience with it. Also, if it were possible with any level of accuracy, I feel that Apple would be using it for it's indoor location capabilities, which they are not.
Here's some of the code I use:
Here's my custom MyBeacon class:
#interface MyBeacon()
#property NSMutableDictionary *accuracyHistory;
#end
#implementation MyBeacon
- (id) init
{
self = [super init];
if (self!=nil) {
self.accuracyHistory = [[NSMutableDictionary alloc] init];
}
return self;
}
- (void) addAccuracyValue:(CGFloat)rangeValue forDate:(NSDate *)rangeDateTime
{
[self removeOldRangeHistoryItems];
[self.accuracyHistory setObject:[NSNumber numberWithFloat:rangeValue] forKey:rangeDateTime];
}
- (double) getBeaconAverageAccuracy
{
[self removeOldRangeHistoryItems];
if( self.accuracyHistory.count == 0 )
{
return -1;
}
CGFloat sumRangeVals = 0.0;
int numRangeVals = 0;
for(NSDate *accuracyDateTime in self.accuracyHistory) {
NSNumber *curValue = [self.accuracyHistory objectForKey:accuracyDateTime];
if( [curValue floatValue] >= 0.0 )
{
sumRangeVals += [curValue floatValue];
numRangeVals++;
}
else // let's toy with giving unknown readings a value of 30.
{
sumRangeVals += 30;
numRangeVals++;
}
}
CGFloat averageRangeVal = sumRangeVals / numRangeVals;
return averageRangeVal;
}
- (void) removeOldRangeHistoryItems
{
NSMutableArray *keysToDelete = [[NSMutableArray alloc] init];
for(NSDate *accuracyDateTime in self.accuracyHistory) {
// remove anything older than 10 seconds.
if( [accuracyDateTime timeIntervalSinceNow] < -10.0 )
{
[keysToDelete addObject:accuracyDateTime];
}
}
for( NSDate *key in keysToDelete )
{
[self.accuracyHistory removeObjectForKey:key];
}
}
#end
I'm new to iOS development.
I follow the tutorial from Ray Wenderlich to create a little location based AR app. However, the tutorial uses an AR Toolkit which has not been updated for a while. The UIAccelerometer it uses has already been deprecated since iOS 5, so when I try to run it on my iPhone (iOS 7.0.4), the Xcode says that there are 3 warnings, and all of them are caused by UIAccelerometer.
The result it leads to is that all the marks stay at the center of the screen one above another, and the tilt does not work at all.
According to my research, I guess what I need to do is to use CMMotionManager instead of UIAccelerometer, but as I said before, I'm totally new to iOS development and have no idea how to replace it.
Here is the source code. I add some little functions such that you can manually add locations that are not in the Google database, but I don't think it is these functions that result in the problem.
Thanks for you help in advance!
Try this link: https://www.inkling.com/read/learning-ios-programming-alasdair-allan-2nd/chapter-9/the-core-motion-framework
I'm learning a few tidbits that translate some-what with the UIAccelerometer
i.e.
[self setAccelometerManager [UIAccelerometer sharedAccelerometer]];
could become
[self.motionManager = [[CMMotionManager alloc] init];
Setting manual update intervals like
[[self accelerometerManager] setUpdateInterval: 0.25];
you can have
self.motionManager.accelerometerUpdateInterval = 0.25;
and releasing the delegate
self.accelerometerManager.delegate = nil;
would now be
[self.motionManager stopDeviceMotionUpdates];
Also from the link, I ended up doing something like this:
motionManager = [[CMMotionManager alloc] init];
motionManager.accelerometerUpdateInterval = 1.0/10.0; // Update at 10Hz
if (motionManager.accelerometerAvailable) {
queue = [NSOperationQueue currentQueue];
[motionManager startAccelerometerUpdatesToQueue:queue withHandler:^(CMAccelerometerData *accelerometerData, NSError *error) {
switch (currentOrientation) {
case UIDeviceOrientationLandscapeLeft:
viewAngle = atan2(accelerometerData.acceleration.x, accelerometerData.acceleration.z);
break;
case UIDeviceOrientationLandscapeRight:
viewAngle = atan2(-accelerometerData.acceleration.x, accelerometerData.acceleration.z);
break;
case UIDeviceOrientationPortrait:
viewAngle = atan2(accelerometerData.acceleration.y, accelerometerData.acceleration.z);
break;
case UIDeviceOrientationPortraitUpsideDown:
viewAngle = atan2(-accelerometerData.acceleration.y, accelerometerData.acceleration.z);
break;
default:
break;
}
[self updateCenterCoordinate];
}];
}
I've been working on an AR framework for a while now and am trying to update from UIAccelerometer (deprecated) to CMMotionManager but am running into some efficiency problems?
Basically it seems like CMMotionManager is MUCH larger and slower than UIAccelerometer is. Has anyone experienced performance issues with CMMotionManager before?
As you can see here, I had this:
accelerometer = [UIAccelerometer sharedAccelerometer];
accelerometer.updateInterval = 0.01;
[accelerometer setDelegate:self];
and
-(void)accelerometer:(UIAccelerometer *)accelerometer didAccelerate:(UIAcceleration *)acceleration {
rollingZ = (acceleration.z * kFilteringFactor) + (rollingZ * (1.0 - kFilteringFactor));
rollingX = (acceleration.y * kFilteringFactor) + (rollingX * (1.0 - kFilteringFactor));
if (rollingZ > 0.0) currentInclination = inc_avg(atan(rollingX / rollingZ) + M_PI / 2.0);
else if (rollingZ < 0.0) currentInclination = inc_avg(atan(rollingX / rollingZ) - M_PI / 2.0);
else if (rollingX < 0) currentInclination = inc_avg(M_PI/2.0);
else if (rollingX >= 0) currentInclination = inc_avg(3 * M_PI/2.0);
}
and all works great even on "older" devices like the iPhone 4 (not really old but yea...).
But when trying the exact same code but with CMMotionManager:
motionManager = [[CMMotionManager alloc] init];
with
[motionManager setAccelerometerUpdateInterval:0.01];
[motionManager startAccelerometerUpdatesToQueue:[NSOperationQueue currentQueue]
withHandler: ^(CMAccelerometerData *accelerometerData, NSError *error){
rollingZ = (accelerometerData.acceleration.z * kFilteringFactor) + (rollingZ * (1.0 - kFilteringFactor));
rollingX = (accelerometerData.acceleration.y * kFilteringFactor) + (rollingX * (1.0 - kFilteringFactor));
if (rollingZ > 0.0) currentInclination = inc_avg(atan(rollingX / rollingZ) + M_PI / 2.0);
else if (rollingZ < 0.0) currentInclination = inc_avg(atan(rollingX / rollingZ) - M_PI / 2.0);
else if (rollingX < 0) currentInclination = inc_avg(M_PI/2.0);
else if (rollingX >= 0) currentInclination = inc_avg(3 * M_PI/2.0);
}];
The math seems to slow the crap out of it..! I say this because when I remove all the math part it works great.
An iPhone 5 will work alright but an iPhone 4S will show signs of lag and the iPhone 4 will just freeze...
(I can give you more details if you want but its relatively complicated to explain)
I was just having this same problem, and wouldn't you know it, the solution was in the documentation ;)
The problem is with the block format. All of the tutorials seem to favor that method, but Apple recommends periodic polling of the CMMotionManager as a more performance oriented approach. The block format adds overhead.
From the CMMotionManager Class Reference:
To handle motion data by periodic sampling, the app calls a “start”
method taking no arguments and periodically accesses the motion data
held by a property for a given type of motion data. This approach is
the recommended approach for apps such as games. Handling
accelerometer data in a block introduces additional overhead, and most
game apps are interested only the latest sample of motion data when
they render a frame.
So what you want to do, from the docs again:
Call startAccelerometerUpdates to begin updates and periodically
access CMAccelerometerData objects by reading the accelerometerData
property.
Something along these lines
CMMotionManager *mManager = [(AppDelegate *)[[UIApplication sharedApplication] delegate] sharedManager];
[mManager startAccelerometerUpdates];
Then, in some sort of periodically updating method of your choosing:
CMMotionManager *mManager = [(SEPAppDelegate *)[[UIApplication sharedApplication] delegate] sharedManager];
CMAccelerometerData *aData = mManager.accelerometerData;
This solution appears to work as well as UIAccelerometer on an iPhone 4 from the limited testing I've done.
I use CADisplayLink.
First, setup CMMotionManager instance.
-(void)viewDidLoad
{
[super viewDidLoad];
self.motionManager = [[CMMotionManager alloc]init];
if(self.motionManager.isDeviceMotionAvailable)
{
[self.motionManager startDeviceMotionUpdates];
}
[self setupDisplayLink];
}
Secondly setup displaylink instance like this:
-(void)setupDisplayLink
{
CADisplayLink *displayLink = [CADisplayLink displayLinkWithTarget:self selector:#selector(update:)];
displayLink.frameInterval = 10;// how many frames to skip before next update
[displayLink addToRunLoop:[NSRunLoop currentRunLoop] forMode:NSRunLoopCommonModes];
}
Display link is an object that is connected to your device screen, and which can run specified selector with specified frame rate; More on them here
Thirdly you should implement update: method you specified as display link selector.
-(void)update:(CADisplayLink *)displayLink
{
// handle new accelerometer data here
CMDeviceMotion *deviceMotion = self.motionManager.deviceMotion;
NSLog(#"Acceleration: %#", deviceMotion.accelerometerData.acceleration);
}
I have an app that revolves around the device's GPS and the information that comes from it. It is important that the location data be accurate and up-to-date. I know that the device is limited by its GPS and the GPS's limits, but I was wondering if there is anything I can do to tweak/improve the performance of the iPhone GPS, particularly in the speed area. Because location updates lag about 3-5 seconds behind the real-time location of the device, the velocity reported by the location manager also lags that far behind the real-time value. In my case, that is simply too long. I understand that there might not be anything I can do, but has anyone had any success in improving the responsiveness of the iPhone GPS? Every little bit makes a difference.
Edit 1:
My location manager is inside a singleton class, as Apple recommends.
Inside SingletonDataController.m:
static CLLocationManager* locationManager;
locationManager = [CLLocationManager new];
locationManager.distanceFilter = kCLDistanceFilterNone;
locationManager.headingFilter = kCLHeadingFilterNone;
if(([[UIDevice currentDevice] batteryState] == UIDeviceBatteryStateCharging) || ([[UIDevice currentDevice] batteryState] == UIDeviceBatteryStateFull)) {
locationManager.desiredAccuracy = kCLLocationAccuracyBestForNavigation;
} else {
locationManager.desiredAccuracy = kCLLocationAccuracyBest;
}
[sharedSingleton setLocationManager:locationManager];
[locationManager release];
Inside MapView.m (where the location manager is actually used):
- (id)initWithNibName:(NSString*)nibNameOrNil bundle:(NSBundle*)nibBundleOrNil {
//setup
[SingletonDataController sharedSingleton].locationManager.delegate = self;
//more setup
}
- (void)batteryChanged {
if(([[UIDevice currentDevice] batteryState] == UIDeviceBatteryStateCharging) || ([[UIDevice currentDevice] batteryState] == UIDeviceBatteryStateFull)) {
[SingletonDataController sharedSingleton].locationManager.desiredAccuracy = kCLLocationAccuracyBestForNavigation;
} else {
[SingletonDataController sharedSingleton].locationManager.desiredAccuracy = kCLLocationAccuracyBest;
}
}
- (void)viewDidLoad {
//setup
[[NSNotificationCenter defaultCenter]
addObserver:self
selector:#selector(batteryChanged)
name:UIDeviceBatteryStateDidChangeNotification
object:nil];
//other setup
}
The data handling happens inside locationManager:didUpdateToLocation:fromLocation:. I don't believe that inefficiency here is the cause of the lag.
locationManager:didUpdateToLocation:fromLocation: calls this method to update the UI:
- (void)setLabels:(CLLocation*)newLocation fromOldLocation:(CLLocation*)oldLocation {
//set speed label
if(iterations > 0) {
if(currentSpeed > keyStopSpeedFilter) {
if(isFollowing) {
[mapViewGlobal setRegion:MKCoordinateRegionMake([newLocation coordinate], mapViewGlobal.region.span)];
}
NSString* currentSpeedString;
if(isCustomary) {
currentSpeedString = [[NSString alloc] initWithFormat:#"%.1f miles per hour", (currentSpeed * 2.23693629f)];
} else {
currentSpeedString = [[NSString alloc] initWithFormat:#"%.1f km per hour", (currentSpeed * 3.6f)];
}
[speedLabel setText:currentSpeedString];
[currentSpeedString release];
} else {
speedLabel.text = #"Not moving";
}
}
//set average speed label
if(iterations > 4 && movementIterations > 2) {
NSString* averageSpeedString;
if(isCustomary) {
averageSpeedString = [[NSString alloc] initWithFormat:#"%.1f miles per hour", (float)((speedAverages / (long double)movementIterations) * 2.23693629f)];
} else {
averageSpeedString = [[NSString alloc] initWithFormat:#"%.1f km per hour", (float)((speedAverages / (long double)movementIterations) * 3.6f)];
}
[averageSpeedLabel setText:averageSpeedString];
[averageSpeedString release];
}
//set elapsed time label
NSInteger seconds = [[NSDate date] timeIntervalSinceDate:dataObject.locationManagerStartDate];
NSInteger minutes = seconds / 60;
NSInteger hours = minutes / 60;
//get remainder
seconds %= 60;
NSString* timeString;
NSString* secondsString;
NSString* minutesString;
NSString* hoursString;
if((seconds % 60) < 10) {
secondsString = [[NSString alloc] initWithFormat:#"0%i", seconds];
} else {
secondsString = [[NSString alloc] initWithFormat:#"%i", seconds];
}
if((minutes % 60) < 10) {
minutesString = [[NSString alloc] initWithFormat:#"0%i", minutes];
} else {
minutesString = [[NSString alloc] initWithFormat:#"%i", minutes];
}
if((hours % 60) < 10) {
hoursString = [[NSString alloc] initWithFormat:#"0%i", hours];
} else {
hoursString = [[NSString alloc] initWithFormat:#"%i", hours];
}
timeString = [[NSString alloc] initWithFormat:#"%#:%#:%#", hoursString, minutesString, secondsString];
[elapsedTimeLabel setText:timeString];
[timeString release], timeString = nil;
[secondsString release], secondsString = nil;
[minutesString release], minutesString = nil;
[hoursString release], hoursString = nil;
NSString* totalDistanceString;
if(isCustomary) {
totalDistanceString = [[NSString alloc] initWithFormat:#"Total: %.2f mi", (float)distance * 0.000621371192f];
} else {
totalDistanceString = [[NSString alloc] initWithFormat:#"Total: %.2f km", (float)distance / 1000.0f];
}
[customTopBar setTitle:totalDistanceString];
[totalDistanceString release];
}
With a couple of NSDates and NSLogs I have found that the execution of the entire locationManager:didUpdateToLocation:fromLocation: (not just the label updating method) never takes more than about 8ms on my iPhone 4; in other words, the data handling isn't the problem.
OK, a couple of things could improve your lag. First of all, use kCLLocationAccuracyBestForNavigation always. There is no real battery usage difference between that and kCLLocationAccuracyBest, they both use the GPS at top speed. The main difference is in the post-processing that Apple does.
Second, there is no need to filter for speed == 0. Apple already does that filtering: if your speed from the GPS drops below a certain threshold (about 4 km/h), the OS assumes you are standing still, and it substitutes the same location value for all subsequent samples. It does that until it thinks you are moving again. I assume they do that to avoid "jittering" on the map when you are standing still. In fact, speed drops to 0 already for the last real value of a sequence of "standing-still" values, so if you filter on speed == 0 than you are missing one real GPS sample.
Unfortunately, they is no way to avoid that filtering and get real GPS samples. I talked to Apple about it, and their response was that they are not going to change the behaviour. kCLLocationAccuracyBestForNavigation does less aggressive filtering than kCLLocationAccuracyBest, so it's best to use that.
Third, you probably are already doing this, but make sure that you call "setNeedsDisplay" on your view right from the "didUpdateFromLocation:", to make sure that the map is actually redrawn.
If you do all that, you should have a lag of about 1 second. If you want to improve on the 1 second than you can try to use predictive techniques. From the last two locations, and the given speed, you can calculate where the next location is likely to be, and already display that location. I have had mixed results with that. It works well for fast movement that does not change speed suddenly, like driving a car. It works less well for slower movement like walking or biking.
In iPhone we can configure location services by two methods -
By using Standard Location Services, that is satellite GPS which provide you more accurate data.
By using Significant Location Changes that uses A-GPS or get location through wi-fi which provide less accurate data.
We can configure location services by any of these two methods but it depends on what is the requirement of the app.
If the app is a navigation app or a location tracking app then we should use Standard Location Services but before using standard services we have in mind that if you want more accurate data then you have to suffer with battery consume more quickly.
If the app don't require location update more frequently and also the accuracy doesn't matter a lot then we should Significant Location Changes because it will save a lot of battery consume as compare to Standard Location Service.
Standard Location Service uses desiredAccuracy and distanceFilter value to determine whether and when to deliver event.
desiredAccuracy is the parameter where you can define how much accuracy you want from GPS hardware. It uses some pre-defined constants as -
kCLLocationAccuracyBestForNavigation
kCLLocationAccuracyBest
kCLLocationAccuracyNearestTenMeters
kCLLocationAccuracyHundredMeters
kCLLocationAccuracyKilometer
kCLLocationAccuracyThreeKilometers
distanceFilter is the parameter where you have to define distance, means for how much distance gap you want to ask GPS hardware to send a location update.
In your case you are dealing with the speed parameter, so i guess its something related to navigation. So you should use Standard Location Services. I think you are also doing that but the issue that you are facing is lag between location updates. Here i suggest you to modify your desiredAccuracy and distanceFilter value to this -
[locationManager setDesiredAccuracy:kCLLocationAccuracyNearestTenMeters];
[locationManager setDistanceFilter:10.0f];
by setting values to this you will get location update in less then 1 sec if your are driving.
One more thing you have to put in your mind that when you get location update you should check its timestamp value to ignore old location updates. Its because when you start locationManager by calling startUpdatingLocation then the first location you get may be your old location. Also you have to check for horizontalAccuracy value because first few location updates that you get are always not accurate and might have accuracy in 1000 or more that you are not looking for. So you have to check its value to ignore inaccurate location updates.
Note: If you try with different accuracy and different distance filter value then you will be more clear about it how accurate data iPhone GPS hardware return.
Aside from the other good examples of how to use Core Location, also keep in mind the general technique for getting good kinematics results from a not-so-great sensor (e.g. smartphone location services) of Kalman Filtering.
It's a lot of math and testing and tweaking, but it does allow you to get what users would consider better results than simple data from the sensor provides.
This is what's used in avionics and things like radar processing systems.