How to Stop Detecting estimote iBeacons with same Major and Minor?
Explaination:
1.Configured two iBeacons with same UUID,Major,Minor
2.In Did Range i am Getting Two Beacon Detection
3 But i need only one in detection (if they are with same UUID_Major_Minor)
4.Is there any way to avoid the same beacon Detections
thanks in advance..
Major and Minor values are numbers assigned to your iBeacons, in order to identify them with greater accuracy than using UUID alone.
Minor and Major are unsigned integer values.
The iBeacon standard requires both a Major and Minor value to be assigned.
Major values are intended to identify and distinguish a group – for example all beacons in on a certain floor or room in your venue could be assigned a unique major value.
Minor values are intended to identify and distinguish an individual – for example distinguishing individual beacons within a group of beacons assigned a major value.
You do not have assign same Major and Minor values for your iBeacons. Technically you do not have to assign these values at all (although they are all required as part of the Apple's iBeacon standard) – however they are very useful for identifying, organizing, and tracking iBeacons down to a finer level. If you want your iBeacons to deliver unique content, then they need to have a unique ID to distinguish them.
For more details: https://support.kontakt.io/hc/en-gb/articles/201620741-iBeacon-Parameters-UUID-Major-and-Minor
-(void)locationManager:(CLLocationManager*)manager
didRangeBeacons:(NSArray*)beacons
inRegion:(CLBeaconRegion*)region
{
// Beacon found!
CLBeacon *foundBeacon = [beacons firstObject];
// You can retrieve the beacon data from its properties
NSString *uuid = foundBeacon.proximityUUID.UUIDString;
NSString *major = [NSString stringWithFormat:#"%#", foundBeacon.major];
NSString *minor = [NSString stringWithFormat:#"%#", foundBeacon.minor];
switch (foundBeacon.proximity) {
case CLProximityUnknown:
//Unknown
break;
case CLProximityFar:
//Far
break;
case CLProximityNear:
//Near
break;
case CLProximityImmediate:
default:
//default
break;
}
if (foundBeacon.proximity != self.previousProximity) {
//check if last foundBeacon.proximity is equal or not
self.previousProximity = foundBeacon.proximity;
}
}
Related
I am working on a project to display the list of all Bluetooth LE devises with services with specific UUIDs. In method didDiscoverPeripheral, I save the discovered peripherals that are advertising. I use the option dictionaryWithObjectsAndKeys:[NSNumber numberWithBool:NO] when scanning for peripherals. I have an NSTimer to wake up every 30 seconds to update the list of discovered peripherals and see if all peripherals are still advertising. I use retrievePeripheralsWithIdentifiers method that I pass in an array of NSUUID of discovered and saved peripherals. This method is supposed to return an array of CBPeripherals that are still advertising. But it returns the original array of all the peripherals that I pass in as an argument, and it never sorts out the peripherals that are no longer advertising. Am I using this method incorrectly?
savedPeripherals is an NSDictionary where device ID is the Key, and CBPeripheral is the Value.
NSTimer *timer = [NSTimer scheduledTimerWithTimeInterval:30
target:self
selector:#selector(updateActivePeripherals:)
userInfo:nil
repeats:YES];
- (void) updateActivePeripherals:(NSTimer *)timer
{
NSMutableArray *peripherals = [[NSMutableArray alloc]init];
if (self.savedPeripherals.count > 0)
{
for(id key in self.savedPeripherals)
{
CBPeripheral *item = [self.savedPeripherals objectForKey:key];
NSString *identifier=[NSString stringWithFormat:#"%#", [[item identifier] UUIDString]];
NSUUID *id=[[NSUUID alloc]initWithUUIDString:identifier];
if (id)
[peripherals addObject:id];
}
}
if (peripherals.count > 0)
{
NSArray *list =[_centralManager retrievePeripheralsWithIdentifiers:peripherals];
}
}
}
The documentation doesn't state that retrievePeripheralsWithIdentifiers will return peripherals that are still visible/advertising. Rather, it says it returns:
A list of peripherals that the central manager is able to match to the
provided identifiers.
The central manager will return known peripherals even if the peripheral is not currently visible. This is to allow apps to connect automatically to a particular peripheral once it becomes visible. The workflow goes like this:
Application launches and retrieves desired peripheral identifier (such as from NSUserDefaults)
Application requests CBPeripheral via retrievePeripheralsWithIdentifiers
Application issues a connect to that peripheral
If the peripheral is currently visible, then the connection happens immediately and the delegate method is called
If the peripheral is not currently visible then the connection will happpen when/if the peripheral becomes visible and the delegate method will be called.
In order to achieve the functionality you require, you will need to use CBCentralManagerScanOptionAllowDuplicatesKey:YES and keep an age against each peripheral. For example, you could use the following approach:
Set up a dictionary, keyed by the peripheral identifier
When a peripheral is seen, store an NSNumber in the dictionary with value 30, also store the peripheral in your table view's source array if necessary
Set up an NSTimer to fire every second.
Each time the timer fires, go through the dictionary and decrement the value stored against each key
For each value that has decremented to 0, remove it from the tableview array and update the tableview
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
Here's my code:
// Initialize and monitor regions
for (NSString *serviceUUID in _serviceUUIDs) {
// Initialize region
NSUUID *uuid = [[NSUUID alloc] initWithUUIDString:serviceUUID];
CLBeaconRegion *appBeaconRegion = [[CLBeaconRegion alloc] initWithProximityUUID:uuid identifier:SERVICE_IDENTIFIER];
// Specify notifications
appBeaconRegion.notifyEntryStateOnDisplay = YES;
appBeaconRegion.notifyOnEntry = YES;
appBeaconRegion.notifyOnExit = YES;
// Add to regions
[_appBeaconRegions addObject:appBeaconRegion];
// Begin monitoring region and ranging beacons
[_locationManager startMonitoringForRegion:appBeaconRegion];
[_locationManager startRangingBeaconsInRegion:appBeaconRegion];
}
To clarify, "_serviceUUIDs" is an NSArray of NSStrings containing five UUIDs. I'm using Locate iBeacons for testing and have found that the last region to be added is the only one that is detected. It also appears to be the only one being monitored. I determined this by checking "_locationManager.monitoredRegions".
There are a number of threads on here saying it's possible to monitor multiple beacon regions. Any one have thoughts for why it's not working for me? Thanks!
You can monitor multiple regions, but each region must have a unique identifier. It looks like you're passing in the same constant SERVICE_IDENTIFIER for each region. Try setting that to a unique value for each one.
We have a product where the user registers by providing their phone number.
However after they register they could potentially change their sim.
Is it possible to programatically determine if the sim has been removed or inserted?
(Thanks if you provide it, but any digression comments on the use of using the phone number in the first place would be irrelevant to this discussion, I don't want to discuss that aspect of things, only the sim aspect).
Yes, of course it is possible. Link CoreTelephony.framework to make following code compile:
CTTelephonyNetworkInfo* info = [[CTTelephonyNetworkInfo alloc] init];
CTCarrier* carrier = info.subscriberCellularProvider;
NSString *mobileCountryCode = carrier.mobileCountryCode;
NSString *carrierName = carrier.carrierName;
NSString *isoCountryCode = carrier.isoCountryCode;
NSString *mobileNetworkCode = carrier.mobileNetworkCode;
// Try this to track CTCarrier changes
info.subscriberCellularProviderDidUpdateNotifier = ^(CTCarrier* inCTCarrier) {
dispatch_async(dispatch_get_main_queue(), ^{
NSLog(#"User did change SIM");
});
};
By values of mobileCountryCode, mobileNetworkCode, carrierName, isoCountryCode you can judge about presence of SIM. (Without SIM they become incorrect).
There is also some undocumented functions/notifications in CoreTelephony, but your app may be banned by Apple if you'll use them. Anyway:
// Evaluates to #"kCTSIMSupportSIMStatusReady" when SIM is present amd ready;
// there are some other values like #"kCTSIMSupportSIMStatusNotInserted"
NSString* CTSIMSupportGetSIMStatus();
// Use #"kCTSIMSupportSIMStatusChangeNotification" to track changes of SIM status:
[[NSNotificationCenter defaultCenter]
addObserver:self
selector:#selector(SIMNotification:)
name:#"kCTSIMSupportSIMStatusChangeNotification"
object:nil
];
// This one copies current phone number
NSString* CTSettingCopyMyPhoneNumber()
Addendum Another possible (and legal) solution: if your company has a database of phone numbers, you can send an sms or call(and cut) any specific number to verify that user still uses the same phone number.
UPDATE Function NSString* CTSettingCopyMyPhoneNumber() doesn't work anymore (returns empty string).
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.