I am trying to use an Android device to transmit Eddystone beacons. I would like to know the approximate battery drain the device consumes to transmit beacons in the background.
Thanks.
Good news! The battery drain of transmitting as a beacon from a mobile phone is negligible. I did some tests on both Android and iOS to measure this drain, and found to my surprise that I couldn't even come up with a number. The drain was so small it was within the margin of error of the test setup.
The Android version of these tests happened to use the Android Beacon Library to transmit an AltBeacon frame, but I have seen similar results using the same library to transmit an Eddystone frame. And since the library simply wraps lower-level Android APIs, these numbers are applicable regardless of what API you are using to set up the transmission.
See this blog post for details.
Related
I want to write an app that when installed makes the smartphone broadcast a unique string to other smartphones using the app. So the app shall broadcast and check for broadcasts constantly in the background while not draining to much energy. I'd like to implement the app in Flutter. So if you could suggest a plugin or a native android/ios api that is suited for this usecase I would greatly appreciate it.
I have read a few articles and all of them talk about detecting the beacon when you are in the range and you cannot see the beacon without knowing its UUID. CBCentralManagerDelegate only gives you the ability to detect the beacon when it is active. Is there any way to detect to beacon when it is in sleep mode but still broadcasting?
"Sleep mode" is not a standard concept when it comes to bluetooth beacons. Some beacon manufacturers have proprietary solutions that alter the behavior of their hardware beacons when they are motionless for a period of time. Typically, this makes such beacons stop advertising entirely until motion is again detected, and advertising resumes.
Three possibilities:
If a beacon hardware manufacturer has implemented a sleep mode as described above, it the beacon will not be advertising in sleep mode at all, and it is impossible to detect via any APIs on iOS.
If a beacon hardware manufacturer has implemented a sleep mode in another manner such that it still advertises the same packets (perhaps at a slower interval?) then it will be detectable using the same APIs as used to detect it when it is active.
If a beacon hardware manufacturer has implemented a sleep mode such that it advertises different packets in sleep mode, then different APIs may be needed to detect. But there is no way to know how to do this without documentation from the manufacturer.
Bottom line: you must consult the documentation provided by your beacon manufacturer to see how sleep mode was implemented (1-3 above) and know how to detect when it is in this mode.
I'm building a progressive web application (target is smart phones for now). The app needs to be able to access heart rate and heart rate variability, ideally in real-time. While it seems totally asinine, I'm open to using REST calls to some remote server if that is the only way. I'm also fine with restricting the app to only work with certain hardware if necessary. In this case, the ideal hardware would be some sort of earbud that uses optics to scan for heart rate, but at this point, I'm open...
The best that I have thought up is to find a heart rate monitor that converts the direct signal into audio and use the microphone web API. That seems like a lot more work than ideal, so I'm hoping someone has a better idea. Any ideas are welcome. Please, no one downvote anyone if it doesn't solve all my constraints. I've been working on this for a bit and I'm not sure that there is a clean and perfect solution yet. Thanks in advance!
If the sensor can speak Bluetooth, the Web Bluetooth API can perhaps help: https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API
https://developers.google.com/web/updates/2015/07/interact-with-ble-devices-on-the-web
How about use a Web Bluetooth that lets you control any Bluetooth Low Energy device like heart rate monitors. It will read the Service Location Characteristics (which tells your where the sensor is placed - which body part) and subscribe to notifications from the Heart Rate Characteristics, meaning you will get an event whenever the device performs a new measurement. Then use a service worker that will define the behavior of the app to mimic native app capabilities like offline support and notifications.
It's like a Physical Web that you can send a link to your website from a Bluetooth beacon to a user's device and with PWA, that link can be to your web app that looks, feels and functions like a native app. Then with Web Bluetooth, you can then speack to the device. Visit this blog post for more details.
how to detect beacon signal and do we need to make any app to manage it or any predefined app or site is available?
I want to know how Beacon works and which Beacon is suitable for retail.
You need a mobile phone with Bluetooth 4.0 to detect beacons. They emit a BLE signal which is a little different from the normal Bluetooth signal. There are many generic apps in the play store and maybe in the app store to detect them.
But if you are looking for real functionality related to that, then you'll be needing the retail store-specific mobile app so that it can show you relevant updates in the app.
I deployed the same iBeacon region monitoring code in 7 devices. One of them, iPhone 6 running iOS 9.2.1, is regularly failing to detect beacon states (inside, outside, etc..).
I tried with and without SIM card and when the SIM card is inserted it gives better results. However, when compared to an iPhone 6 running iOS 9.2.3 and one running iOS 9.2.1 it gives worst results (the latter two iPhone's always detect the region).
Have you experienced the same in this version of iOS (iOS 9.2.1)?
Is this an known official Apple bug?
My theory behind this:
iBeacon region monitoring uses iPhone location, iPhone location can be
improved using Wi-Fi and phone signal and possibly also accelerometer
and gyroscope data.
iOS could be using these in combination withe the Bluetooth data to
"tune" the beacon ranging thread (in other words if a significant
location happens then the background monitoring frequency will be
increased). Hence if this tuning is depending on the SIM card
information there could be a version of iOS where they put a stronger
dependency on the SIM card presence leading to what I am observing.