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.
Related
I have a BLE device that doesn't respond to SCAN_REQ and am working it out with the vendor independently per https://github.com/espressif/esp-idf/issues/10660.
When I use Nordic nRD Connect iphone app as a client I can see that device in the scan list and can connect to it. However, when I use a different client, a python Windows one, that client doesn't show the device in its scan list and doesn't connect to it if I specify the exact address.
My question is, are BLE 4 devices required to respond to SCAN_REQ requests to be discoverable and connectable or is it just optional response to provide additional advertisement data?
EDIT, I believe that Emil's answer below (thanks) refers to this quote
Yes, it's required to reply with a scan response. That is defined in Bluetooth Core v5.3, Vol 6 Part B (Link Layer), section 4.4.2.3, using the word "shall".
There is one exception though. There is a Filter Accept List in the controller which can contain addresses of centrals allowed to scan and/or connect. There are four combinations the host can set (advertising filter policy) that control if this list shall be used for filtering incoming SCAN_REQ and CONNECT_IND packets, respectively. If you don't use this filtering mechanism, then the device must send a scan response to every scan request.
There are two possible approaches to scanning—Passive Scanning or Active Scanning.
Passive Scanning is when Scanners receive advertising packets and process the contents.
In the case of Active Scanning, however, a device may decide it wants to know more about an advertising device and respond to the initial advertising packet by sending a Scan Request GAP protocol data unit (PDU). This basically means ‘Tell me more.’ The device receiving the Scan Request can send back a Scan Response PDU with more information, once again in the form of a collection of AD types.
The above has been extracted from: https://www.bluetooth.com/blog/advertising-works-part-1/ [the emphasis mine].
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.
https://developer.android.com/about/versions/10/features#bluetooth-le-coc
Android 10 has the BLE CoC, and it will enable apps to transfer larger data streams. So What's the max throughput of BLE CoC.
Is it better than BLE with Data Length Extension(DLE)?
CoC has nothing to do with LE Length Extension (it's like asking if WebSockets are faster than IPv6). It is just a more convenient way of sending a stream of data than for example with GATT. You will get more or less the same throughput as with GATT notifications/write without response.
An actually good thing with CoC is that the remote device can decrease the incoming throughput if it is not capable of handling the incoming data in time using the Credit system. With GATT notifications or write without response that is not possible and if you follow the GATT standard strictly packets will be dropped if they can't be handled in time.
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.
I'm currently building an application that is intended to run on an embedded system hooked up to a cellular data card. I've been made aware of some low-data plans from several carriers, and our application only generates about 5 bytes/second, lending itself to such plans.
However, I can't seem to figure out if the TCP/IP header overhead (about 40 bytes, give or take) is included in the calculation for data usage. Since I need real-time data, I've disabled Nagle's algorithm. This means for each 5 byte burst I send out, I'm sending out a new header. If TCP/IP headers are factored into the data usage pricing, it will dwarf the amount of data I'm sending.
I can't answer definitively, but I would assume they must. Otherwise this could be exploited by adding extra data to the headers. With TCP you send a 40 byte packet and then you receive a 40 byte acknowledgement packet. You could try using UDP instead of TCP so that you don't have to waste data with the acknowledgement packets.
According to an email from Sprint network engineering, "Any data that goes through our network, including network Header [sic.] would be billed or count towards your plan."