I know that the definition of an iBeacon is a fixed specification of the advertising packet that it is transmitting:
9 bytes iBeacon prefix
16 byte UUID
2 bytes Major
2 bytes Minor
1 byte TX power
That being said, is there anything that would prevent a beacon from both sending out advertising iBeacon packets to wake up a phone's app and also transmit actual data content as part of a BLE packet? Would there be a lot of handshaking required in order to send / transmit additional data?
Is there some other way for a beacon to transmit data? One of my large concerns is spoofing of my beacons to falsify the data I am attempting to collect. I was hoping that being able to transmit some data along with an iBeacon packet would allow me to limit the spoofing.
Is something like that even feasible?
A few possibilities:
You can tack on one extra data byte to the end of the iBeacon transmission before it reaches its max advertisement length. This byte cannot be read by iOS devices, though, because Apple blocks reading raw data of iBeacon adverts. It would work on Android/Mac/Linux.
You can interleave a second advertisenent with mostly data fields and line the two up with a common identifier like the minor. The more bytes you allocate to lining up the advertisements, the fewer you have to use for data. You can't use the mac tobline them up, because that is unreadable in iOS for the iBeacon transmission.
You can make the beacon connectable via GATT, and read data fields with GATT attributes. The beacon will stop advertising, though, when connected. This limits throughput and reliability.
All of these options require you to build a custom BLE beacon that does multiple advertisements. It is not a trivial undertaking.
Related
I am planning to develop a small project with a NRF52 (or other BLE chip if that'd matter). Preliminary, I would like to know, if I can broadcast data without "abusing" the advertising bytes?
Scenario: Two smartphones connect with my device and they enable some notify-characteristic over which i would like to receive data with a potentially high frequency (up to 100Hz maybe) on both devices. (I know 100Hz is already close to the minimum 7,5ms or so that ble supports... just to say i wanna reach that limit basically and be as fast as possible with receiving)
So: if I connect two central devices, will they receive the same notify signal or will I have to send one for each central device, essentially lowering the max frequency at which i can receive data?
In the latter case, is the best way to broadcast ble data to multiple devices via the advertising bytes?
Kind regards, have a good one
When you use GATT notifications over BLE, the notifications are individual per connection. So if you want to send the same notification to two connected clients, the data is duplicated over the air. In general, all GATT traffic is individual per connection.
If you send one packet per 10 ms to two devices, that should be fine. Note though if one packet is lost, it will be resent during the next connection event and hence then two packes will be sent to that device (assuming you produce an additional packet after 10 ms as usual).
You can use advertising instead to broadcast data. Every device that scans can see your data. Data you send in ADV_IND can be seen by an unlimited amount of scanners.
If it's better to use advertisements or GATT to send data to multiple devices depends on a lot of factors. You should experiment what works best for you.
I want to send some sensor data over BLE to multiple nodes.
I thought of changing advertising data at 4Hz. Can it be done?
Yes! It is a common approach to use a BLE beacon packet to advertise sensor data. A few points:
Embedded BLE platforms typically allow advertising at a minimum of 10Hz, and let you change the advertisement between transmissions. I have done this on the Nordic 52x chips, but hopefully STM32 supports it as well.
BLE 4.0 advertising packets are limited to 23 usable data bytes, but you typically need to reserve a few to indicate it is "your" transmission. There are significant further restrictions if you intend to use iOS devices to scan the transmissions. If using Android, Linux, or other embedded system scanners you can use nearly the full 23 bytes.
Keep in mind that anybody in radio range can scan for these advertisements and read the data. Make sure the sensor data are not sensitive enough to warrant a security layer.
Is there any way to retrieve a battery voltage from my iBeacon?
Maybe adding a byte somewhere in the advertising packet to present the value of the battery.
There is no standard way to do this with iBeacon. Other formats like AltBeacon and Eddystone-TLM do include a data byte to transmit the battery level.
Many hardware beacons support interleaving multiple beacon transmissions from the same hardware device, so even if you need iBeacon, you could still transmit the battery level in one of these other formats.
Is there a maximum in specifications,do they start to interfer if many try to connect at the same time?
what are the modes of communication is there a secured mode or something else ?
Maximum packet size ?
can I send an image or a sound using ble ?
There is no limit in the specification. In reality at least around a millisecond must be allocated to serve each connection event. So if you use a 7.5 ms connection interval you could not expect more than at maximum 10 connections without getting dropped packets (and therefore larger latency). Connection setup/scanning will also miss a large amount of packets if the radio is busy handling current connections.
The maximum packet length is 31 bytes for advertisements (up to Bluetooth 4.2). While connected the longest packet length is 27 bytes. Bluetooth 4.2 defines a packet length extension allowing larger packets but far from all implementations support that.
The security that BLE offers is the bonding procedure. After bonding the devices have established a shared secret key which is then used to encrypt and sign all data being sent.
Sending normal-sized images or sounds will take several seconds since the throughput is quite low.
I think you should really read the Bluetooth specification or some summary to get the answer to your questions.
What exactly is a BLE scan response packet?
Since there is almost nothing to be found online, we would like to now this.
Does a scan response packet, respond on a device scan or is it like the advertisement packet sent every x seconds?
A BLE scan response is the packet that is sent by the advertising device (peripheral) upon the reception of scanning requests (i.e. yes, it is a response to a device scan). The scan response usually has more data than the advertising packets. In other words, central devices send scan requests to the advertising device in order to get additional user data through the scan response. Please also note that scan responses are considered to have fixed 'static' data relative to the more dynamic advertising data.
Advertising packets and scan response share the same format, and are transmitted over the same three physical channels (they are both sent as advertising events), but are otherwise two different things.
For more information, I recommend reading about scan response packets in the SIG's core specification found here.
I hope this helps
An important addition to yousif saeed's answer:
According to the Bluetooth 4.x specification, Peripheral devices accepting Scan Requests,
Must advertise this by using a specific Advertising Type value in the protocol header.
Must use advertising intervals of equal or bigger than, at least, 100 ms, so that the Central/Peripheral devices can exchange the Scan Request/Response packets in the time between two consecutive advertising packets (advertising interval).
Keep in mind, also, that depending on your particular hardware platform and Bluetooth Low Energy software stack,
You may find that a peripheral device accepting Scan Requests is non connectable, that is, may be limited to behave as a pure beacon (connection-less).
I was just looking for this information and it is difficult to find good technical resources beyond the basic description.
There is a great few pages on one of the manufacturer's sites that goes into the details of how their hardware interacts with these communications.
The scan response packet consists of:
Device name,
Transmission power,
Beacon ID,
Firmware version,
Battery level
https://support.kontakt.io/hc/en-gb/articles/201492492-iBeacon-advertising-packet-structure
https://support.kontakt.io/hc/en-gb/articles/201493072-Beacon-services
https://support.kontakt.io/hc/en-gb/articles/201492492-iBeacon-advertising-packet-structure
I am not promoting Kontakt.io, but they did a pretty good job of providing this answer in good detail.
Yes it does depend on device scan.
I recently had this experience.
I was working with Nordic device and started sending advertising packets which included scan rsp data. But either I was getting no scan rsp packet or hardly any packet. The issue was I was not scanning from my other nordic device. Once I started scanning from another device, scan rsp packets started coming quickly.