Is it possible to send a signal to an iBeacon in the form of a scan request to let the beacon know their advertising packet was heard?
This way we could turn on an LED whenever the beacon detects that some other device heard it.
Bluetooth LE advertisements, including beacon advertisements are one way. There is no standard mechanism to acknowledge receipt.
The typical alternative to do what you want is to actually connect to the beacon using a GATT Service. This can let it know you heard the advertisement. The disadvantage is that connections stop advertising, so you need to make it short lived.
Another alternative is to make the beacon also scan for other advertisements around it. You could then echo the same advertisement back to it (with a change in the beacon type bytes to differentiate it) but because advertisement delivery is not guaranteed, you would certainly need to send the response back many times to maki it reliable.
None of these solution s are standard. All would require a custom beacon.
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.
As described, BLE Scanner can not know the advertising channel.
How to get BLE advertising channel index number
But, in the link below, at first graph,
the Initiator send the CONNECT_REQ to the Advertiser through Ch.38 which is used to send ADV_IND.
it is something like that the Initiator knows which the advertising channel is used.
https://microchipdeveloper.com/wireless:ble-link-layer-connections
Can Scanner know the advertising channel?
The scanner of course knows which advertising channel is being used. It's just that it's not part of the Bluetooth Specification to expose this information to an application using the Bluetooth stack. In particular, the HCI events for advertisements do not contain such a field. It is possible though that some embedded devices can expose this info to the application, if they have defined a custom API for this.
I'm doing a security analysis project on an IoT device that uses an unencrypted BLE connection (with ATT protocol) and I want to spoof an individual BLE packet with the source address of an already connected device. Is there some tool or API that would allow me to do this easily? I've already tried gatttool and spooftooph but they seem to be connection based and don't allow you to send out single packets with modified fields (as far as I could tell).
You will need some hardware where you can access the radio peripheral directly. What you basically need to do is to find or write a ble sniffer firmware, with the modification that it at a given moment sends a packet on the connection it is currently listening to. But note that the signal strength must be stronger than the original device's signal so it doesn't interfere.
The only open source project I'm aware of is Ubertooth. You will also be able to do this with an nRF52 but then you need to write your own sniffer firmware since Nordic Semiconductor's is closed source.
I can't comment on Emils reply yet, < 50 rep:
Nordic Semis nRF Sniffer v2 needs only the nRF52DK and wireshark to work as a general BLE sniffer. At 40$ it's not that expensive. I know for a fact they will release a new dongle soon that will sell for ~10-15 bucks if you can wait a a month or two.
How do I implement notification in BLE?
I have a smartphone, and every hour it will send notification to all nearby BLE devices (smartwatch, RFduino, etc) for time synchronization purpose.
Other devices are server now (since it provides data), and smartphone is the client that collect the data.
Could I piggyback into the advertisement packages? For example, the smartphone always broadcast an advertisement packet to annoucement its presence (that's how other devices can find it). Can I modify that packet to be a time sync?
In order to send notifications or advertisements, your smartphone has to act as a server, which also means that in order to be able to receive notifications or scan for advertisements, your peripheral devices must act as clients.
This can be a bit tricky, because if two devices act as client and server, they may not simultaneously fulfil the other role. You need to switch roles whenever needed, which is an open field for all kinds of problems.
Also, I am not convinced that it is really the optimal choice to let the smartphone regularly notify all devices in the vicinity. Each of the devices that wants to receive the notification has to be connected with the device in order to receive the notification, and this connection has to be already active when the notification is sent in order to really get the correct time. So all these devices need to connect in advance to the expected notification time, and hold up the connection until the notification has come.
It might be better to just advertise the current time, but remember that you can't connect to the smartphone as a server while it is advertising, because the link layer may not be in scanning and advertising mode at the same time, and you may also not be connected when advertising for a similar reason.
If you want to do it that way, you can include the time information in the advertising data. See the Supplement to the Bluetooth Core Specification v6, Part A for further information on the structure of the advertising data. You could put it in the manufacturer specific data.
However, another option would be to write the time directly to the device using a write request. You can define your own service and characteristics. You can include a "time synch necessary" information in the advertisement data of the servers, and when the smartphone evaluates the advertisement, it can connect to the corresponding device and send the time directly.
The advantage of this procedure is that time is only updated if you really need it on the device, and that you do not have to switch client/server roles, because the device in server role may advertise as normal, and the smartphone can always stay in client role.
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.