From what I understand monitoring provides you information when a region has become visible in the vicinity of your scans (with callbacks like regionentered, regionexit etc) and then ranging gives your information about beacons in that region.
So behind the screen is same bluetooth scan sufficient to call both callbacks? Or we need to start separate scans for each?
In theory, one scan is enough for doing all these. The scan callback provides enough information to calculate beacon region/ranges. (You can use libraries or write your own algorithm for these.)
However practically the app need to restart separate scans, just to protect the Bluetooth stack on your device. There are quite some device specific issues if you run one Bluetooth scan for long time. Restarting scan periodically will improve the stability significantly on some devices.
Related
I want to create an android application with background scanning of BLE beacon (like Eddystone or ibeacon). All I need is the detection of a beacon with a specific ID on my phone. I do not need distance between devices.
Is there any beacon with the ability to send signals through cca 3 walls in a building (or 1 flood up/down) in an area with a radius around 30m?
Can my app scan in the background every few seconds all day? (or just when Bluetooth is on, obviously...)
I tried some solutions, but android changed some politics about background running apps, or bluetooth receiver (to detect, when bluetooth is on). My solution sometimes works even 7 hours, but when I restart phone, the app is not restarted. I want a full background run, not foreground service with notification.
Thank you!
Two points:
All bluetooth beacon formats use the same radio transport mechanism. Radio power is limited by international regulatory bodies making transmitters weak.
The laws of physics decide how well they will travel between floors of a building, which will vary based on construction materials, but results will generally be poor. Again, this will be the same for all beacon formats.
Android 8+ limits detections of BLE in the background without a foreground service. You can do at most one scan every 10-25 minutes (this is randomized) when the phone is not in deep sleep mode. the only alternative is a foreground service with an ever present notification.
I realize these are not the answers you want to hear, but it is important to recognize and accept real-world limitations that exist and come up with creative solutions that work within these limitations.
I'm working on an Android app that needs to detect if other users of the app are close to each other (lets say within the same room or Bluetooth range). The app needs to be able to detect this without any user interaction.
Geolocation is not an option as this is too inaccurate indoors.
The app runs only on company owned phones that stay on company ground, privacy is not a concern.
All devices are always connected to the same wifi network and BT is always enabled.
My idea is to detect if users are within a close distance of eachother by periodically Bluetooth scanning and checking the results against a list of MAC adresses that contain all the devices that have the app installed.
The MAC adresses of all devices are send to a server, the devices then grab this list of mac adresses from the server to compare to the results of a BT scan.
Problem is, BT and Google's seem to use Advertisement / Discovery patterns where one device acts as the server and one device acts as the client. For this to work properly i feel like the devices need to always be discoverable.
Will an implementation based on Google's Nearby or BT work for my needs ?
Is it possible to detect the presence of a nearby device without it being discoverable ?
As battery life is a concern (need to be able to do this for atleast 8 hours a day) is BLE an option?
You can almost certainly handle 8 hours a day if the phones aren't really used for much else. There are a lot of variables, however.
Many older phones require a different type of scanning using infinite scanner restarts in order to properly report "seeing" a peripheral. This can dramatically decrease battery life.
If the phones are running Marshmallow or later, they have a doze mode which interrupts scanning. This can be circumvented using an AlarmManager, JobService/Dispatcher, or WorkManager. This can dramatically decrease battery life.
If the phones are running Oreo or later, they require a foreground service (persistent notification) in order to prevent the app from being automatically killed by the OS to save battery. The app should also be whitelisted from battery optimization because even with the foreground service, the app will still be killed off by the OS.
Finally, scanning and broadcasting and using location services is pretty expensive battery-wise. If you're attempting to cluster phones and guess their position based upon what other phones are nearby, at some level you'll still need the location data off of the phones to figure out where they're at.
You're much better off just scanning. You could carpet your company property with beacons, where each individual beacon's location is recorded. When the phone "enters a region" (comes within range of a beacon), it should send something to your api reporting which beacon it just found. This will tell you what room/area it's in.
Another less flashy (and potentially less accurate) way to track everything would be via the IP addresses of the wireless access points they're connected to. Use a WorkManager to periodically update an api with some unique ID for the phone and the IP address of the AP. Your IT department should know the locations of each of them. This way you get reasonably good tracking and virtually no battery drain.
android.net.wifi.WifiManager has the startScan() method to perform a passive scan of the WiFi channel and when the scanning is completed onReceive() method is called to access the WiFi channel readings.
However, as this webpage shows, which I have also confirmed with my own code implementation, the passive scanning of the WiFi channels take different times with different phones. Sometimes, some platforms are even around 10 times slower..
I would like to know what causes the phones to use so much time. Is it the driver? Is it some energy saving features? Or none of them and something very different is the reason?
The article gives you a hint:
Passive scans are slower to perform, because the device needs to
listen on every channel for some period of time, waiting for
broadcast beacons. Beacon frames are transmitted by APs periodically
to announce the presence of a wireless LAN. Beacon frames contain all
the information about its network. This approach consumes less energy,
since the radio doesn't use transceiver, but only the receiver. It
also takes more time to finish, since it has to listen on every
channel.
Some period of time is different for each device. If you listen for too short a time on a channel, you might miss a beacon frame. Too long and it might take a while to enumerate all the available APs when the user first scans a new location.
Furthermore, I didn't see actual details on how those results were generated. One might imagine a smart algorithm would use a longer listen time when first in a new location but switch to shorter ones after it's been there for a while.
I'm working on an Android application that needs to scan nearby Wi-Fi access points on a regular basis. Currently the scan takes place every 2-3 minutes, which requires registering a BroadcastReceiver to capture the scan results, calling WifiManager's startScan method and processing the results (something that also requires network calls in my case). This loop consumes a lot of energy, and I want to improve my power consumption by implementing a smart power policy for the app.
Aside from scanning only on "busy hours" (for example, stopping the loop at night), I'm thinking about using the accelerometer through the SensorManager to detect whether the device is stationary (placed on a table) or in motion (in the user's pocket while walking, for example). Then, by determining if the device is moving, I can adjust the scan frequency (reduce when it is stationary, and increase when the device is in motion).
I have a few questions on the matter:
1) Will tracking accelerometer data on a regular basis be more power efficient than running the scan loop every 3-5 minutes? How much power will tracking the accelerometer really cost?
2) How can I determine if the device is stationary or in motion? I've seen many question online talking about detecting shakes and tilts, but there's not a lot of information about natural motion detection. Also, how frequently should I sample the sensor?
I think the best way is to use ActivityRecognitionApi class included in the google play sevices which is optimized for such goals. This class gives a method : requestActivityUpdates which is optimized to return device state with minimum consumption of power.
The activities are detected by periodically waking up the device and
reading short bursts of sensor data. It only makes use of low power
sensors in order to keep the power usage to a minimum.
I second Fouwad Wahabi’s answer to your question.
I would recommend taking another approach to the track accelerometer and your user’s activities. I’d integrate a free SDK (available online) such as:
1. Tranql
2. Neura
3. Atooma
Some of these SDK’s send you the details of the user’s activities as soon as they occur and use less than 1% of your battery.
How can a device identify the other devices to whom we need to send data and transfer the data to other device.
If the device1 send the data to device2, will other device say device3 near to them will receive same data?
Please read up on the whole Bluetooth story. You seem to have problems with basic concepts. Also, it would probably help to be a bit more specific in your questions for example specifying which BT version are you referring to.
For identifying the devices, each of them has a separate address. They even have human readable names. (Look at the Wiki page linked above Connection and communication) Also, during the pairing process, you should have to get to know and explicitly allow the devices which you really want to communicate with, the goal of the process is exactly to make sure to have an explicit authorization between the devices for communication.
Yes, device3 will receive the radio signals, but if not authorized, it won't be able to tell what is going on - unless it is a misbehaving device cracking the encryption... (Given the communication is actually encrypted, that is.) Reading the Security Concerns part is also useful.
Bluetooth can connect up to eight devices simultaneously. With all of those devices in the same 10-meter (32-foot) radius, you might think they'd interfere with one another, but it's unlikely. Bluetooth uses a technique called spread-spectrum frequency hopping that makes it rare for more than one device to be transmitting on the same frequency at the same time. In this technique, a device will use 79 individual, randomly chosen frequencies within a designated range, changing from one to another on a regular basis. In the case of Bluetooth, the transmitters change frequencies 1,600 times every second, meaning that more devices can make full use of a limited slice of the radio spectrum. Since every Bluetooth transmitter uses spread-spectrum transmitting automatically, it’s unlikely that two transmitters will be on the same frequency at the same time. This same technique minimizes the risk that portable phones or baby monitors will disrupt Bluetooth devices, since any interference on a particular frequency will last only a tiny fraction of a second.
So what if they interfere and there is a erroneous data, the receiving system simply discards it based on correcting bits of the packets transffered.
Bluetooth devices have a parameter or option called visibility. When you enable visibility, then the bluetooth device starts
publishing its presence within the bluetooth frequency range. This presence can then be detected by any other bluetooth device which can connect to this device when
it scans the above bluetooth frequency range.
As they use spread-spectrum frequency hopping described above they
publish data to all receivers but only the intended receiver with whom
the sender is connected will have the key to unlock the data.