I have a use case, and i want to use BLE to accomplish the use case, i don't know if BLE support my use case and the way to do that.
Sensor Tag- is small device that works on coin battery and contains BLE.
Use-case: I want to connect the Sensor Tag to smartphone and unpack data.
1- The connection must be just to my smartphone app, i don't want any other app's to connect to the Sensor Tag and unpack data.
2- Each packet of data must be ACK, the smartphone get packet 1 and send it to the server, the server return ACK to the smartphone, the smartphone send ACK to the Sensor Tag, then the Sensor Tag will sends packet 2...
3- In order to force the Sensor Tag not send data in airplanes, the Sensor Tag must just listen at first, if he heard something from my android app, then he will sends connection request.
First questions: did the BLE support my use case? All, some(which ones), none?
Second question: How can i establish the use case?
Thanks.
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.
I have a single BLE beacon and I try to connect to it with multiple Android phones in order to get the RSSI, and see who is the closest to it.
But, just after the first phone connect to the beacon (via a BluetoothGatt), the beacon never appears from the scan again in the scan results of the other phones, so they cannot connect to it too.
The only solution I see is to scan without connection and get the RSSI from the scan result, but I don't think that is an elegant solution.
Is there a way to have multiple connection to a single BLE beacon and get the RSSI ?
Thank you
It's up to the BLE device to decide if it supports more than one connection. If it only wants to support one connection, it can be programmed to stop advertising when a connection is established. From a client perspective, there's not much you can do about that. If you can modify the firmware in the beacon, you can add support for multiple connections.
Otherwise there is nothing wrong with using the rssi in the advertising packet (although you can't make use of BLE security (pairing / bonding)).
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.