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
Related
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.
I and my team are working on a beacon that we need to talk to an app on the user's iPhone. Since we need the app to detect the beacon and execute code to talk to our API even when killed, we cannot use CoreBluetooth and need to operate as a beacon.
We're attempting to make a custom beacon on a BCM20737S BLE module. Is it possible to have this custom beacon talk to an app on an iPhone as a beacon? (CoreLocation framework)
Thanks!
As long as your packet is broadcasting a packet with the iBeacon protocol, then corelocation can detect it and your app will wake based on detection of this signal. An iBeacon protocol packet is a 25 byte payload set as the manufacturer data field in the BLE advertisement.
The company ID is 2 bytes (0x004C)
The type is 1 byte (0x02)
Data Length is 1 byte (0x015)
Proximity UUID is a 16 byte Hex String
Major is 2 bytes uint16_t
Minor is 2 bytes uint16_t
Measured Power is 1 byte int8_t
This stack thread might be of some use to you.
What is the iBeacon Bluetooth Profile
But essentially corelocation is only configured for ibeacons, if you want to transmit a different protocol packet youre going to need to use CoreBluetooth on iOS, then once you receive the packet, translate it somehow for use with your app.
The CoreLocation framework will only detect iBeacons, which means beacons that meet the iBeacon byte format. You can certainly build your own, and while it does not have to be an official Apple certified iBeacon, but it does have to match the byte pattern. This pattern is widely available on the internet, even if you do not sign up for Apple's certification program that earns you the right to see the spec.
Be careful, however, that you make no changes to rhe byte pattern. Some vendors have built beacon transmissions that tack extra bytes on to the end to send the battery level. While these transmissions are detected, they are detected much more slowly because the header has a different length field, which does not match the hardware filter used for rapid detection in the background.
If you want to customize your beacon format, you must use CoreBluetooth for detections. I have written some open source iOS beacon tools that help do this, using the open source AltBeacon and Eddystone-UID formats as examples. While detections in the background are slower as you say, you can make your beacon transmit both an iBeacon signal (to wake up your app quickly) and a custom beacon signal (to send whatever custom fields you want) to be detected as soon as it is awoken. This way you get fast detection even if you define your own custom beacon format.
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.
Apologise for the probably use of the wrong word in my question but for the life of me I can't think of the right one.
Anyway, I've been playing about with the Bluetooth Low Energy and I'm trying to create something that is going to use the RSSI signal strength the BLE device emits. For this, I need it to emit its pulse multiple times per second.
Is there a way I can up the amount of times my devices either scan for a signal, or broadcast their signal through code on iOS devices?
No, there is no API for you to change the advertisement speed or radio power.
This aspect is fully controlled by the system. You can only start and stop the advertisement and add some metadata to the packets: device local name, advertised services, etc. Moreover, the contents of the advertisement packets will differ depending on whether your app is in the background or foreground and, additionally, in background it will be slowed down. These effects have been documented in various SO questions and in the header files.
If your clients are iOS applications, then they should use either the RSSI in the advertisement packets (centralManager:didDiscoverPeripheral:advertisementData:RSSI: method) or when connected, the readRSSI method on the peripheral object (just make sure you don't call it too often).
I am trying to understand BLE and GATT in more depth. My interest is in the max achievable number of reads you would able to make per second over the GATT profile.
I am aware of some of the post made on this topic before, for instance:
Bluetooth Low Energy - updating a characteristic value repeatedly
However, I am trying to explain these results looking at the BLE specification.
What is the relationship between connection events and GATT? Does each ATT read/write require a new connection event? If not, is it possible to say anything about how many ATT read/writes can be made per connection event?
Say I want to poll a BLE connected light sensor for a single byte value, what would be the max Hz I could achieve? Would it always be best to set the mininum connection interval as low a possible?
Would I be able to achieve better results using "GATT server notifications? In the BLE spec (Core_v4.0) it says that "The master initiates the beginning of each connection event". Then how are GATT server notifications implemented? I would think that would require the server to initiate a connection event.
Finally, if anybody knows about any specific iOS imposed limitations on the throughput I would be able to achieve when polling a sensor intensively, I would love to hear about it.
I can answer a portion of of those questions...
What is the relationship between connection events and GATT?
They're different levels of the protocol. You handle connections and connection events via HCI. GATT is something you use after you've connected.
Does each ATT read/write require a new connection event?
No. Once you're connected you can do multiple read/write or other GATT commands.
If not, is it possible to say anything about how many ATT read/writes can be made per connection event?
I think the best method is to actually benchmark the speed yourself. However, the whole point of BLE is a reduction in power usage at the expense of speed. If you're concerned about speed that you probably shouldn't be doing it with BLE. The whole point of notifications/indications is so you don't have to poll an attribute but only get a message when a certain event has occurred.
Say I want to poll a BLE connected light sensor for a single byte value, what would be the max Hz I could achieve? Would it always be best to set the mininum connection interval as low a possible?
See above 2 answers.
Then how are GATT server notifications implemented?
Once you've implemented a GATT connection there's 2 way communication going on between the master and slave-device. Either device can send events to the other. In order to use notifications, you set a bit on a particular attribute to say you want notifications on that information. Then, depending on how that notification works, you'll get events sent back to you whenever there's something to report. I have a feeling that a lightbulb wouldn't have any sort of notification unless there's some interface on it besides the BLE connection. I typical application would be something like a thermometer where it would send a notification every time the temperature changed by 1 degree.
Conclusion:
If you're polling attributes you're doing it wrong. But it's possible that you have to do it wrong because the device didn't properly implement notifications in the way you need and you can't modify the device. However, polling will ramp up the battery usage significantly and you'll have loss the benefit of using BLE.