i am looking for a gps tracker using bluetooth low energy (so there's no need for mfi-programm. using apple devices).
Is it even possible, since BTLE saves energy and gps-tracking requires a more or less constant connection?
I'm thankful for any informations I can get about BTLE + GPS
Greetings
Timm
I know no equivalent on iOS platform - but on Android platform - use SmartNAVI to broadcast mock GPS location using the phone sensors (starting from a know location) as a replacement GPS (so GPS does not need to be on) - then feed this into an app called BlueScan - which logs BTLE device RSSI based on there GPS location and time. - I wish there were something equivalent on iOS - but alas iOS is seriously behind in the world of engineering development/IT platform when it comes to the world of IoT, BTLE, etc.
Related
If I would have a (custom made) external BT LE gps receiver (receiving NMEA GPS signals) that I would connect with bluetooth to an iOS device, would this automatically work with the CLLocation Manager services in all my Apps?
The BT LE connection is custom made hardware, is there any info of how to configure this to act like a iOS supported (MFi) GPS receiver?
Any tips or pointers much appreciated.
There is no way for your own custom made GPS to get integrated
with CLLocationManager unless you become a MFi vendor.
However, if you are targeting Jailbroken device, it's technically possible.
This is because BTStackGPS is integrated with the system so that we can use Apple's map application with non-MFi external NMEA bluetooth GPS. BTStack is open source and it's said that BTStackGPS runs on the BTStack. It supports BLE, too. Note BTStackGPS is not open source, so you need your own research on how to integrate your SW with the system.
I am working on a project where I first wanted to advertise a device as an iBeacon and make it possible to connect to that device via Core Bluetooth at the same time. Besides the fact that this is not easily doable (a device cannot advertise as an iBeacon and CB device at the same time), I noticed that the iBeacon part seems unnecessary - discovering peripherals with Core Bluetooth seems to be basically the same as discovering iBeacons.
My first Question: Am I right in assuming this? Or does iBeacon provide anything that central/peripherals in CB do not? Especially in regard to background advertisement/searching?
The only issue I can see right now is that the CLBeacon gives me both an rssi and an accuracy (and from this, the approximated proximity is calculated). With Core Bluetooth, centralManager:didDiscoverPeripheral:advertisementData:RSSI: gives me only an RSSI. Is there any way to retrieve the accuracy here so I can calculate a proximity? This is important for me and I guess relying on RSSI only for the proximity will give me less accurate results?
My second Question: Can I get the accuracy that I get with iBeacon in Core Bluetooth or a similar measure to calculate the proximity?
You can calculate your own distance estimate with RSSI using an algorithm like the one I posted here:
https://stackoverflow.com/a/20434019/1461050
The trick is that you will need as many RSSI measurements as possible averaged over a time window of 20 seconds or so to reduce the noise on the estimate.
The main advantages of using CoreLocation APIs to detect standard iBeacons vs. using CoreBluetooth to detect custom beacons are:
A variety of cheap off-the shelf hardware is available for the iBeacon standard.
CoreLocation can scan for iBeacons in the background (likely using hardware assist on iPhone 5+) in a way that can automatically launch your app relatively quickly, even if the user did not manually launch it since boot. As of iOS 7.1, even if the user kills the app from the task switcher, CoreLocation can re-launch it into the background if an iBeacon is detected. I do not believe all this is possible with CoreBluetooth.
The iBeacon transmission allows you to easily read the UUID/major/minor identifier combination in iOS without pairing. This 20 bytes of data (with the major and minor fields able to be set to arbitrary values) is more than you can get from a 16 byte Bluetooth Service UUID.
You don't have to roll your own software for distance estimation.
Is it possible to actually determine with any degree of certainty whether an iPAD actually has a GPS signal. I can think of three cases
Wifi-Only IPAD
Wifi-Only IPAD with External GPS (such as the DualXGPS)
Cellular IPAD with Internal GPS
Apple documentation mentions:
Some location services require the presence of specific hardware on
the given device. For example, heading information is available only
for devices that contain a hardware compass. This class defines
several methods that you can use to determine which services are
currently available.
Are there specific calls that work specifically with a GPS only such as heading or tracking? I'm assuming perhaps only GPS devices have a heading call because the documentation says:
In iOS, a device with the appropriate hardware may also report heading
information. When the value in the headingAvailable property is YES,
you can use a location manager object to retrieve heading information.
Some previous posts suggested trying to get a lock on a very accurate GPS update
Detect if Device has GPS
How can I tell if an iOS device has a GPS?
but i was hoping for something a little more concrete these methods "feel" wishy-washy - because just because an inaccurate GPS signal would likely look like there is no GPS when the device actually has the capability. Also I would think a wifi device which can "mimic-gps" might also some how pass one of these conditions.
Thanks for any help!
The simplest answer is that you should try to use the GPS at the accuracy you need and see if you get it. And deal with the fact that you might not get this accuracy because the user is in a building, or an urban canyon, or doesn't have GPS hardware, or has turned off location services (although this can be detected).
If you get better than 100m accuracy or if the CLLocation has altitude you almost certainly have GPS hardware (but you have to wait quite some time to get a signal lock on at least 4 satellites to get altitude). If you have a cellular radio connection (see Reachability) then you have GPS hardware (except iPhone1). If you have digital compass capability then you have GPS hardware (except iPhone 3G).
Internal GPS hardware is available on all iPhone and iPad that have cellular radios (except iPhone 1, see wiki chart). If you study that chart it appears that all devices (so far) that have GPS hardware also have digital compass (magnetometer) except iPhone 3G.
Using course (as suggested here) from the CLLocation only works if the device is moving fast enough and the GPS has satellite lock. A better option would be to detect if you have a heading from the compass (magnetometer).
You can use the hardware string to determine device capabilities by hardcoding a table of what hardware has what capabilities (described here). This has to be kept updated (which means an app update) when new devices are introduced. Erica Sadun has categories for UIDevice called Capabilities and Hardware on github that attempts this, but may not be usable in the app store.
None of this will help with external plug-in GPS or external bluetooth GPS devices.
if (location.getHoricontalAccuracy()< 40) {
// for sure GPS
} else {
// no GPS or unusable bad GPS
}
you can also use speed and course, if they are valid, then they are from GPS, because It is the only sensor that can measure speed and course. (magentometer shows the current heading, which works without GPS)
I am developing a system to locate an iPhone indoors. I am considering using Bluetooth triangulation based on signal strength.
Is it possible to get the signal strength of nearby bluetooth devices on iOS 6?
Is it possible to get the phone's bluetooth MAC (so I can identify the phone and do signal strength measurement from the other side)
Any other ideas to calculate position of iPhone based on bluetooth triangulation?
It's for a restaurant type app. The restaurant wants to know at which table the phone/app is sitting.
If your iOS device supports Bluetooth LE, you can easily obtain the RSSI between it and sensor stations, as well as a UUID for identifying the device. You can also read the MAC address if you're using the right software on your sensor side, but I don't believe that this information is exposed by Core Bluetooth in the same way that RSSI and UUIDs are.
There are two ways to approach triangulation if using Bluetooth LE. One is to do the triangulation by monitoring the iPhone from a series of placed sensor locations, and the other is to do triangulation on the iPhone itself by reading the signal strength between it and devices that are advertising from known points.
The latter can be done by placing a series of LE peripherals in known locations and having them advertise at regular intervals. Within the advertisement information, you could stamp the location of that peripheral in the room. The iPhone could read these advertisements, get the RSSI information from them using the -centralManager:didDiscoverPeripheral:advertisementData:RSSI: delegate method, and triangulate its location.
The former approach would be a little more involved. It would require that the iPhone itself be placed into an advertising mode using the new iOS 6.0 support for making the iPhone a Bluetooth LE peripheral. The sensor locations could then pick up the RSSI from them to the iPhone via these advertisement packets, as well as a UUID you generate for the phone. You can also pick up the MAC address of the phone is running the right software on the sensor nodes. A central server would then need to combine these readings to triangulate the iPhone's location.
You might need to experiment with the transmission strength to determine what kind of resolution this would provide. The RSSI information is noisy, and in my experience it only seems to resolve to +-30 feet at the normal transmission levels for my peripherals. You may be able to improve upon this with multiple sensor stations and a lower transmission strength.
Is it possible to get GPS information in a mobile device through APIs without having any GPRS connectivity?
Edited
Yes, for example on the Java ME platform or Apple iPhone
Yes; if you are on a device that has GPS hardware in it and software development on the device gives you access to that hardware from your software.
This can be using a built in API for opening a COM port. You then just need to open the port that has the GPS hardware connected to (internal GPS receivers inside the device are often connected to a fixed COM port number) start interpreting the (often) NMEA strings that the GPS receiver is sending out.
Or perhaps the device has more specific GPS related APIs, like the GPS intermediate driver in Windows Mobile 5+ that lets the OS talk to any GPS receiver (either built in, or connected via cable or bluetooth to a COM port) and lets multiple applications concurrently interact with the GPS data.
P.S.
GPS has nothing to do with GPRS per se. You might have gotten that idea because of A-GPS which uses telecom network information and/or a dataconnection (like GPRS, EDGE, UMTS, WLAN, whatever) to download a small file with information about the location of GPS satellites.
This data will then enable your device shorter GPS aquisition times within the time period that this retrieved data is current - often a couple of days to a week I believe - because it does not just need to see what GPS signals it can receive and make sense of that, but it has a lot of prior knowledge about the GPS constellation that should be in orbit in the part of the sky you can see.
GPRS is a two-way data transmission which enables you to access the iternet while the GPS is just a receiver and as peSHIr already mentioned it has nothing to do with GPRS. GPS receiver receives the signals from multiple satellites and calculates the location from time differences.
Anyway... you need GPRS or any other internet connection only if you want to use any web service for reverse geolocation or you want to use google maps or any other location service. But just for receiving (calculating) the coordinates GPS by itself is enough.