I was browsing through the Android Wifimanager class and I found this method:
public boolean isDeviceToApRttSupported ()
Returns
true if this adapter supports Device-to-AP RTT
But what is Device-to-AP RTT?
WiFi RTT (round-trip-time) is for indoor positioning, and is included in the Android P preview: https://developer.android.com/preview/features.html
Android P adds platform support for the IEEE 802.11mc Wi-Fi
protocol—also known as Wi-Fi Round-Trip-Time (RTT)—to let you take
advantage of indoor positioning in your apps.
On Android P devices with hardware support, your apps can use the new
RTT APIs to measure the distance to nearby Wi-Fi Access Points (APs).
The device must have location enabled and Wi-Fi turned on, and your
app must have the ACCESS_FINE_LOCATION permission. The device doesn't
need to connect to the APs to use RTT. To maintain privacy, only the
phone is able to determine the distance to the AP; the APs do not have
this information.
If your device knows the distance to 3 or more APs, the API uses a
multilateration algorithm to estimate the device position that best
fits those measurements. The result is typically accurate within 1 to
2 meters.
With this accuracy, you can build new experiences like in-building
navigation, fine- grained location-based services such as
disambiguated voice control (for example, "Turn on this light"), and
location-based information (such as "Are there special offers for this
product?").
RTT = round trip time
= time of a signal going from one device to the other and back
Judging just from the name of the method this should answer the question if measurment of rtt is possible (supported) or not.
speculative:
It's more likely that this answer is given for your android device and its wifi-hotspot feature and not for any remote devices that are connected.
Related
I am new and I hope I am posting in the right section. I am developping an iOS app using indoor advertisement. The app scan fro iBeacons and when it detect one it sends a get request to the server which determine the position of the mobile device and send back a response. I found this text on the internet
Mobile-centric and network-centric technologies are different only in
where the data and/or logic resides for calculating the location of a
mobile device. For example, the American Museum of Natural History’s
original Explorer mobile wayfinding app used Cisco’s Mobility Services
Engine (MSE), which was a device that sat on the network and processed
the raw signal-strength data provided by the mobile device to
triangulate the location based on a map that was managed and stored in
the MSE. The new Explorer still uses triangulation to determine the
phone’s location. However, the map and beacon locations are downloaded
to the phone, and processing is done locally in the app.
Considering this text, in my use case I am using a network-centricsystem bacuase the location logic reside in the server. Is that true ? I thought that device-centric location is when the mobile device scan for beacons and network-centric is when the beacon send it's position to the nodes.
Beacons are devices that send signal all the time. Also mobile device is scanning for beacons all the time. Those things doesn't change based on technology. You are using network-centric technology. So what is the diffrence:
Mobile-centric
location is calculated on your phone
Network-centric
data is send to server which returns your location based on given data
Network-centric is often used when doing task on phone may:
drain too much energy
be not fast enough
I'd say that triangulation doesn't require server for calculations as is quite easy and you may notice, that waiting for server response may be not fast enough for displaying location to user.
In your case you're using a mobile-centric. Your mobile device is determining where it is at by using its physical distance to a an iBeacon. You have to tie a beacon to a location so you phone will say, "Ok, I see beacon 1 which I know is in Room A".
If you were going for network-centric, then the iBeacons would be telling the mobile device where it was. (even though this is not how iBeacons work but as an example) The beacon would be discovering the phone and saying, "Hey mobile device, you're in Room A".
So you see in the latter the network is telling the mobile device where it is, thus "network-centric". Where in the first case the mobile device is determine where it is, thus "mobile-centric". So even though you are pinging a server for the data associated with a location, the device is still telling the server where it is in physical space based on the proximity to a beacon.
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)
Is it possible to limit the ranging of the beacon, so that only devices within a certain close range(or proximity) can identify and connect to the beacon? Lets say for example the devices outside 0.5 meter zone shouldn't be able to see or connect to the beacon. I am using a iOS device as a beacon. In the Apple's CoreLocation API, there is a method called peripheralDataWithMeasuredPower in the CLBeaconRegion class which says:
peripheralDataWithMeasuredPower:
Retrieves data that can be used to advertise the current device as a beacon.
(NSMutableDictionary *)peripheralDataWithMeasuredPower:(NSNumber *)measuredPower
Parameters:
measuredPower:
The received signal strength indicator (RSSI) value (measured in decibels) for the device. This value represents the measured strength of the beacon from one meter away and is used during ranging. Specify nil to use the default value for the device.
Can this be used to limit the range of beacon? If yes, I am unable to understand how to decide the value to set for measurePower parameter? What are they trying to say by ...value represents the measured strength of the beacon from one meter away..?
Please forgive if this is a very basic question. I've recently started iOS development and will appreciate your help. Thanks.
Unfortunately, there is no easy way to adjust the range of an iBeacon without special hardware.
The power field that you mention is simply a calibration value transmitted by an iBeacon. It doesn't affect the actual physical radio range of the iBeacon. If the transmitter can be seen by an iPhone 50 meters away, altering the power field value will not change this at all. The only thing it does is change is the calibration constant which is an input to the distance estimation algorithm (used for the accuracy and proximity fields) inside the iOS software. Altering the power field will affect the estimated distance returned by the API, but it won't change the actual distance at which the iBeacon is first detected.
Altering the transmit power of a standard bluetooth iBeacon is practically impossible. In theory you can use metal shielding to construct a "faraday cage" around the transmitter to mute its power, but my experience is that it isn't very effective and it is highly susceptible to tiny imperfections in the shielding. If you want to change the transmit power you have to have somebody build you custom hardware.
The software alternative is to use the ranging API to track an iBeacon while it is visible, and only perform an action when the estimated distance is close enough, say 0.5 meters as you suggest. This works great -- only in the foreground.
If you require actually waking up your app in the background at a close range, this won't work. The best you can do is have the monitoring API wake up your app when the iBeacon is first detected, and then send a notification to the user and start ranging. If the user elects to bring the app to the foreground (at 50 meters) you can keep monitoring and then perform your desired action at 0.5 meters. If the user does not elect to bring the app to the foreground, iOS will only give you about 5 seconds of time to continue ranging before it suspends your app. It is very unlikely that the distance will change from 50 meters to 0.5 meters in this time.
With most BLE chips I've investigated, there are usually at least four settings for transmission power level that can be used to limit the advertising range.
The Texas Instruments CC2541 (as used in their SensorTag development device) and CC2540 have +4, 0, -6, and -23 as their power level options. However, changing that in the SensorTag does require a recompile of the firmware. As-is, the provided firmware mentions the power level in only one place, but that is just a value that is broadcasted to inform any central listener how loud the beacon is—so that the central device can better calculate an estimated range based on received signal strength (RSSI). An additional line must be added to the firmware to actually change the transmission power. For example:
HCI_EXT_SetTxPowerCmd( HCI_EXT_TX_POWER_0_DBM );
Based on this, there should be two places on an iOS device where you can set the power level: one that just informs the listeners what the level is, and one where the BLE chip's true transmission power is actually changed. However, expect these values to be restricted to only a few enumerated choices which may or may not meet your real-world range needs.
(The SensorTag's -23 setting would probably do well for a 0.5 meter detection range. But if you want the SensorTag to always be advertising, it will require an additional firmware change.)
Have you looked to see if the proximity property was helpful? From the apple docs:
CLProximity
Constants that reflect the relative distance to a beacon.
typedef {
CLProximityUnknown,
CLProximityImmediate,
CLProximityNear,
CLProximityFar
} CLProximity;
I would also experiment trying to combine the the proximity with accuracy and rssi.
It's gonna vary from beacon to beacon. If you use beacons from Radius Networks, they have a transmit power setting that lets you essentially limit the ability of the beacon radio to broadcast to long ranges. I don't know if other brands have it, but most do not from what I've seen.
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.