developers!
I would like to know whether is it possible for AltBeacon Transmitter Android App to detect if a Scanner Android App is listening to the Transmitter? If it is possible, how do I start?
I have attached an image for a clearer picture of my question. Overview
A beacon transmitter is a transmit-only device that emits packets with no knowledge of whether any receiver is listening. It is not possible to know directly if a receiver is present.
This is equivalent to an over-the-air television broadcast. The transmitter sends the signal with no knowledge of there is anybody with a television turned on and tuned to the proper frequency.
in both cases in order to find out if anybody is listening you must build another feedback mechanism. With Bluetooth beacons, it is typical to build a mobile app to call a server to tell it the advertisement has been received.
Related
I work on iOS application which is using BLE for communication with our custom made BLE unit.
We want to send specific commands via BLE to the unit automatically.
When user is near unit and specific criteria are met, the app should connect to the unit, "login" the user, send command via BLE and disconnect right away.
These specific criteria are based on manufacturer data from advertisement (i.e. the unit is in "available to login" state when manufacturer data has last byte 0x01, when it's "NOT available to login", last byte is 0x00).
In foreground, this mechanism works flawlessly.
We want to do this even when app is in background or terminated (swipe up in dashboard on iPhone).
The mechanism we have implemented:
the unit has capability of acting as iBeacon
when unit is NOT available for login, the iBeacon is OFF
when it IS available for login, the iBeacon will turn ON and wakes up application, upon that the BLE scan will start in background mode
background mode setting is bluetooth-central
Problem here is that no matter what I tried, the advertisement:
sometimes it's not discovered at all (looks like it's timing issue?)
when it's discovered, it does NOT contain manufacturer data
Did anyone come across something similar?
Any help is appreciated and have a nice day!
An app simply cannot read raw BLE manufacturer advertisement data when in the background on iOS -- the operating system prohibits it.
Two exceptions to this rule:
iBeacon, which itself is implemented as a specific type of manufacturer advertisement. An app can detect iBeacons in the background on iOS, although only four bytes of readable data (encoded in the major and minor fields) are fully usable. If you can modify your device to send information this way, it will do what you want. However you must use CoreLocation APIs to detect iBeacon, as CoreBluetooth does not allow reading manufacturer data from iBeacon advertisements. If you do use CoreLocation, you cannot use the detections to establish a Bluetooth connection with CoreBluetooth as the two APIs are sandboxed.
Overflow Area advertisements. Backgrounded iOS apps can read these special types of manufacturer advertisements when in the background but only if the screen is turned on. (It is often possible to force the screen on at specific times by sending a local notification.) See my blog post here for more info: http://www.davidgyoungtech.com/2020/05/07/hacking-the-overflow-area
An alternative to detecting manufacturer advertisements is to use BLE Service advertisements with attached data. For this to work, you'd need to define a 16 bit or 128 bit GATT Service UUID and send out an advert with attached data bytes. Eddystone beacon formats work this way, and allow detection in the background on iOS. This is probably the best approach if you can alter the BLE hardware.
Is it possible to simultaneously broadcast my iOS app as an iBeacon and at the same time publish a service?
My app currently advertises a service, which works perfectly fine. My client app (central) is able to find the peripheral, connect, obtain the service and read data from the characteristic. However, if I update my server app (peripheral) to start broadcasting as an iBeacon emitter in addition to the service, I am no longer able to find services that I setup to advertise on the client app (central).
The idea of this is that I want to be able to read information from the server (peripheral) app when in close proximity from the client (central).
Is this technically feasible?
I was thinking about turning off iBeacon transmission when a device comes into close proximity and then starting the service broadcast, but there is no API in Core Bluetooth that calls back to the emitter when a client device enters the region being advertised.
Is this doable? Is there a workaround that would achieve something along these lines? I would like to avoid any networking, as this should be an offline solution.
Taz, For sure you can be an iBeacon and you can look for iBeacons. What I did and what I see other doing is combining iBeacons with other services, such as the CloudKit [which yes, means networking too] to add functionality to their basic functionality.
That said I can imagine an app in which your iBeacons switch to a different protocol when they see each other, the challenge; how-to negotiate a channel/UUIDs for a BLE peripheral/central pair.
I am still in the process of building, but have implemented something similar over the past months... in short you hardcode an initial channel to start your BLE conversation, your first and only exchange on said channel being to agree a new BLE one to use.
I really haven't read into much about iBeacons beyond the fact that they are low energy bluetooth transmitters that are able to detect nearby proximity devices. I am aware that there are beacon devices such as estimote that allows users to get prompts when entering their proximity. However, I am wondering if two iPhones can act as both beacons and receivers at the same time. So is possible for User A to be able to connect to User B when he arrives in a particular distance of the person?
By connect what I mean is for some sort of interaction to occur.
(e.g. Notifying User A that User B is nearby or exchanging messages that these users would like to send to people that comes in their proximity)
Thanks guys.
Yes, iPhones can both act as iBeacons and receive iBeacon signals. But they can only act as an iBeacon when the transmitting app is in the foreground.
What you suggest is all possible, but it is important to note that the iBeacon concept is connectionless. It is a one way transmission of a simple identifier from beacon to receiver. If you want to make a connection and exchange data, you need a separate mechanism like the internet or a non-iBeacon Bluetooth connection.
Is it possible to send only 1 iBeacon packet? I have tried using CBPeripheralManager,but since there are only 2 method to start and stop advertising, so I can't control how many packet is being broadcast.
What I want to try to do is use an iBeacon packet as a command, instead of just a broadcasting some ID. So I could send 1 iBeacon packet, and if the receiver got the message, it can send back Acknowledgement with another iBeacon packet. The intention is to avoid the pairing of bluetooth to send very simple data. The information will be linked to UUID, major, and minor of the packet.
Or are there better ways to do this than using iBeacon.
Yes, you can use iBeacon technology to send information back and forth between two iOS devices without pairing. If you have two devices, Device A and Device B, you set both of them up to range for beacons with a common ProximityUUID, say, E2C56DB5-DFFB-48D2-B060-D0F5A71096E0. And then you can exchange information in the two byte major and minor fields.
What you can't do is control the transmitter enough to send only a single iBeacon advertisement. The transmitter in iOS sends out 10 advertisement packets per second, so the best you could do is start the transmitter then stop it on a timer about 100ms later. (You probably shouldn't do this, because there is no guarantee that a single iBeacon advertising packet will be received successfully by the other device -- it may be lost due to a CRC error in the radio noise. You are probably better off letting the packet continue to transmit until you can confirm from a response from the other device that it was received.)
You can see an example of starting and stopping a transmitter on a timer in my answer here.
Of course, there may be easier and more robust ways of accomplishing what you want with built-in Bluetooth data exchange mechanisms. But that doesn't change the fact that what you propose is certainly possible.
No you can't since iBeacon is uni-direction device
I want to build and app which can detect other iPhones with my app within 65 feet range. As I understand I have the following choices:
Use Bluetooth to check periodically whether there is device with my app in the range. Send list of found devices to the server. The problem here is battery consumption. Is it true that Bluetooth will be disabled after some period of time automatically?
Can I use BLE technology for this purpose? If so, do you know what devices support BLE?
What is the best option on your opinion? Did I miss some other option?
Thanks
UPDATE
I plan to run search every 20 seconds or even more often.
There is no simple answer to this problem.
Bluetooth has 2 flavors: "Regular" bluetooth, used for hands-free devices, headphones, and the like, and BLE (Bluetooth Low Energy)
Regular bluetooth devices must be paired. (I'm less familiar with regular bluetooth than BLE, so take my explanation of this bit with a grain of salt.) In order to be paired they have to be put into "discoverable" mode, which broadcasts their ID. That is a battery-draining and only done briefly. It's not an "always on" solution.
BLE has a range of up to 60 meters, so it should meet your need in that regard.
BLE devices can "advertise" as a "peripheral" for extended periods. Other Bluetooth devices can act as a "central" and ask to be notified when certain peripheral devices are detected. I'm not sure if you can make an iOS device advertise (broadcast) as a BLE peripheral while it's in the background and/or if the device is locked, but it will certainly advertise while it's running. I'm pretty sure you can register to be notified when you detect a certain BLE peripheral from the background, but not positive.
iBeacons are a specific use of BLE with some extra limitations and some extra abilities. An iBeacon is a dirt-simple transmitter that sends a UUID plus a major and minor value and a signal strength calibration value periodically (usually once a second.) You can't add any other data to an iBeacon transmission. iOS can only act as an iBeacon transmitter when the app is in the foreground. If your app moves to the background, it stops transmitting. Period.
However, you can listen for iBeacon signals even from the background. AND, if you've registered as a listener for an iBeacon and the system terminates your app due to low memory, the system still listens for those beacons on your behalf. If iOS detects a beacon you're listening for, you get re-launched if needed, and notified in the background. You can then post a local notification to get the user's attention.
iBeacons are probably your best bet, but you will need your users to be actively running your app in the foreground in order to transmit a signal. That will drain your user's battery fairly quickly.
One possible solution would to have have every single device send their locations to your server every predetermined time period (more frequent the better but more resource intensive). Then, query the data from the server and get the location of all the devices near you.
Keep in mind, that this probably won't be very useful for real-time data collection. For example, if you want to send data every 30 seconds or so, this isn't a good option.
Use this option if you want to get data every 15-20 minutes or so.