I need to advertise 2 different sets of data, 31 bytes each. It doesn't look possible when I look at the core specification v4.0.
What I understand when looking a bit further, beacons can be advertised in 3 different channels : 37, 38, 39. LE Set Advertising Parameters Command makes it possible to choose a specific channel as well as all at once.
Is it possible to advertise different data in different channels ?
If it is not possible, the only solution I remain with is changing the advertisement data periodically using LE Set Advertising Data Command.
I would be glad to see a bit insight on performance, stability and power consumption.
Yes, your device can act as several BLE beacons as long as you periodically change the advertising payload. Your suggestion of using LE Set Advertising Data Command is my recommended approach and you don't need to change the advertising channel for this purpose.
In other words, what you can do on your device is set up a timer, and then as soon as the timer expires, you can switch to a different set of BLE data that is being advertised, which will create the affect of your device acting as multiple beacons.
Please see the following links which may be helpful to your question as well:-
Can BLE devices act as beacons
advertise custom service uuid with bluez 5.4x
Linux BlueZ custom Manufacturing Scan Response Data
Bluez BLE peripheral advertise custom characteristic with ADV data
I hope this helps.
Related
We're designing a Bluetooth LE peripheral that implements some primary GATT service and needs to advertise the existence of the service as well as a few bytes of data related to the service. The device is intended to connect to arbitrary consumer smartphones (therefore mostly Android and iOS). We use a 16-bit service UUID and plan to advertise the related data via the advertising data type 0x16 (Service Data - 16 bit UUID). Due to the limited size of the advertising PDU, we'd like to avoid any additional advertising data, most notably we'd like to avoid advertising the same UUID also via data type 0x03 (Complete List of 16-bit UUIDs).
As the device should be used with consumer smartphones, compatibility is a major concern and therefore the compliance with relevant standards is as well. A critical aspect seems to be that the smartphone OSes should be able to do efficient filtering for devices advertising our service, so the app may run and listen in the background.
A safe approach would be to advertise both, 'service data' as well as 'complete list of UUIDs', because all OSes are certainly able to filter for UUIDs advertised in the latter, but this would exceed the size of the advertising PDU. We could also configure the mobile's BLE scanner to return all BLE devices nearby, without any filtering and do the filtering in our own code, but this wouldn't be efficient and wouldn't allow to run in the background.
We did some testing with different smartphones (Android and iPhones, older and newer ones) and at the first glance filtering for service UUIDs when only the service data type is advertised, seems to work just fine. However, we couldn't find any documentation (neither for Android nor for iOS) that definitely states that this is a supported scenario, so we can't be sure that it works on all phones and also in the future.
The Apple Accessory Design Guidelines section 36.4 refers to the Bluetooth Core Specification Supplement, Part A and states the following:
The advertising data sent by the accessory should contain at least the following information as described in the Bluetooth Core Specification Supplement, Part A:
Flags
TX Power Level
Local Name
Services
[...]
The primary services should always be advertised in the advertising PDU.
However, this doesn't make clear which kind of advertising data type should be used and the same is true for the Android documentation.
With this context my questions are:
Is it a good idea to advertise the primary GATT service solely via the 'service data' data type?
Would this even comply to the Bluetooth Core Specification?
Is there any documentation for Android and iOS that makes clear, whether this is a supported scenario from the OS standpoint (I actually don't mean the OS source code)?
Are there any Android (>= 5.0) or iOS (>= 11) devices that would not be able to filter for service UUIDs advertised via the 'service data' data type?
What is the best practice in such a case, given the limited size of the advertising PDU?
Thank you for your thoughts!
I am pretty new to IoT and BLE. What I want to achieve is to write on GATT characteristic of at least 100 peripheral devices simultaneously or in a very short period of time(i.e. less than 100ms). Currently my peripherals are Ble nano (nRF51822) with custom GATT service running on them. I am using my Mac as central BLE. I am using Node.js and noble to implement the central. I want to know if such thing is possible at all and if possible, please link me to an example code. :)
You should note that Bluetooth chips for computers are usually (quite arbitrarily) limited to only a few simultaneous connections. Common values are between 3 and 14. Even if you connect a few at a time, send the characteristic value, disconnect and then connect next devices it would be impossible to do this within 100 ms. If you want to send the same data to everyone you should instead let your computer advertise and the nrf devices scan. That way you broadcast the data instead.
I couldn't find a clear explanation what is Bluetooth le multi advertising.
For example, in Specification of the Bluetooth System, I see only
description of BLE advertising but not multi advertising.
What the difference between BLE advertising and multi advertising?
Thanks
LE Multi advertising refers to a specific offload (non bluetooth specification) feature that has been implemented in the Android releases by Google, starting from the L release.
What multi advertising means is, that your Android phone or a device with Android stack, can enable multiple advertisement trains at the same time. For instance, one specific app can set certain advertisement data (example supported services etc.), advertisement parameters and enable advertisement, and so can N number of other apps, on the same device.
At the hardware level (or physical layer), these advertisement trains are interleaved between the three advertisement channels (37, 38, 39) and thus your phone behaves as multiple peripheral devices at the same time. All these advertisement trains also have a separate Random private address, so they are seen distinctly by the remote scanner.
Bluetooth Smart has two ways of communicating. The first one is using advertisements, where a BLE peripheral device broadcasts packets to every device around it. The receiving device can then act on this information or connect to receive more information. The second way to communicate is to receive packets using a connection, where both the peripheral and central send packets. We will focus on advertisement for several reasons:
You can’t create a connection between two devices without using advertisements. Defining the data and format of advertisement packets is usually the first thing you work on when developing a BLE device.
A large number of BLE products sleep most of the time, waking up only to advertise and connect when needed. This means advertisements have a big impact on power consumption.
Users want responsive products, and the advertising interval is critical in quick connections.
Advertising is by design unidirectional. A Central device can’t send any data to the Peripheral device without a connection. But a single peripheral can advertise to multiple masters in the area.
ref:http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-ble-advertising-primer/
Let's say I want to start transmitting advertising packets from a Blueooth 4 module attached to a Raspberry Pi. I am planning to use BlueZ library for the same. Have a basic questions regarding the same -
How much memory does a typical Bluetooth device contains (is it standard or something that can change from vendor to vendor) ? In both the cases, does the advertisement has to be 27 bytes (iBeacon) and 28 bytes (Altbeacon and URIBeacon) or can it be extended to any number limited by bluetooth memory size or any other guidelines? Wish to understand a little bit about this topic.
Thanks in advance!
Device memory is not what limits the Bluetooth LE advertisement size. The limitation is imposed by the Bluetooth 4.0 Core specification, which allows for a maximum of 28 bytes in a manufacturer advertisement PDU (including the one-byte PDU length field).
While you can't transmit more data in a single advertisement, it is possible to send more data using other techniques including:
Interleaving multiple advertisements from the same transmitter. You can differentiate these advertisements with a "type" byte, and then use this to stitch them together with the receiving device. Disadvantage: complex implementation.
Using a scan response packet to send additional data. Disadvantage: scan responses may not arrive in a timely manner.
Provide a connectable GATT service that can be used to fetch additional data. Disadvantage: once connected, advertising stops.
Use a web service to look up additional data based on a unique identifier in the advertisement. Disadvantage: It won't work with out an internet connection.
I have a little hw with a BLE module that communicates with an iOS device.
I would like to perform a discovery using iBeacon (so using iBeacon advertisement packets) and - obviously - connection (and data exchange) using CoreBluetooth, but there are some issues.
Before describing the issues, I have to tell you that I need to provide these information in discovery phase:
Serial number (needed for internal purposes) - 6 characters and 10
numbers.
A "hw version" to specify what type of product it is (each product
uses a different protocol).
The problem I have is basically how to perform the discovery phase and then connect to a particular discovered object:
A. In the iBeacon adv packet, I should use UUID field for serial
number and major/minor field for the hw version, but if I do so, the
devices will be basically not discoverable (iBeacon SDK for iOS
needs to know the UUID to look for before starting the monitoring
phase, so it cannot be different for every device).
B. In iOS, the iBeacon features are available through CoreLocation libraries,
the standard BLE features are instead available through CoreBluetooth.
If I use an iBeacon advertisement packet, the objects discovered by
CoreBluetooth libraries do not see any information of the package
(so, the problem is: "How do I know which is the object with serial
XYZ?").
I realized that a possible solution for my problem would be advertising both iBeacon and standard BLE packages, in a "round robin way" let's say.
I tried it (I advertised for 500msec the iBeacon Package and for 500msec the standard BLE one) and Standard BLE seems to be ok.
I still need to investigate more about how iBeacon discovery reacts to this, but as said it could be a solution.
OPTION 1: If you want to use an iBeacon advertisement, forget about encoding any info directly in the ProximityUUID. As you mention, you need to know this up front in iOS. Instead, make a lookup table to convert the iBeacon identifiers to Hardware Number / Serial Number. Like this:
Proximity UUID Major Minor HW/N S/N
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10001 0001 abcdef0000000001
2F234454-CF6D-4A0F-ADF2-F4911BA9FFA6 10001 10002 0001 abcdef0000000002
This system would let you have 65536*65536 different serial numbers for a single UUID. You would need to store this table server-side and have a web service to look up the Hardware Number and Serial Number based on the UUID/Major/Minor.
My company offers a cloud service at http://www.proximitykit.com that lets you do exactly this. You can even use our web service API to programmatically add items to your lookup table. (It will probably be big.)
OPTION 2: Since you need CoreBluetooth after a connection is established, you might consider using CoreBluetooth for the whole thing. Your advertisement would be identical for all hardware types, but after connecting, the first data transfer to iOS from the device would contain the hardware number and serial number. You could then adjust the communication as needed based on the hardware number.