I want two BLE devices to connect to each other, and exchange data bi-directionally.
These devices are exactly equivalent - this is basically a serial cable between two peers.
There is not one 'store of data', or hierarchy between the two.
Both ends basically transmit data to each other (there is no polling for 'read' data), and no acknowledgement is required.
BLE documentation refers to the Characteristic Properties as:
A Client can send data to the server with 'write'
A Server uses a 'notify' characteristic (which the Client subscribes to)
So basically I have just one question:
Can I just have one Characteristic, with two properties
'Notify' (writing to Client) and
'Write' (writing to Server)
That the Peripheral advertises, and this will enable two-way write behavior?
First a few things to make everything clear, in case somebody wonders:
BLE has the concept of Central and Peripheral. Peripherals advertise their presence. Centrals scan and discover peripherals which they then connect to. Once the connection is created, these link layer roles do not really matter in terms of GATT and L2CAP Connection oriented channels, which are both used to transfer data.
Every device (including centrals) supporting connections over BLE must have a GATT server. While it is far more common that the peripheral only uses the GATT server role, it can act as GATT client. Centrals can also act as GATT servers. Furthermore, the both GATT roles can be supported simultaneously. Both sides can for example expose an identical GATT server characteristic with the write property. Not sure if this is a common approach though.
Now, back to your question. You can definitely have one characteristic both having the "write" and "notify" capabilities. When you write, I would suggest using "Write without response" since that has better throughput than "Write with response", since it does not require an acknowledgement between every write. Over the link layer, all kinds of packets are still sent "reliably", meaning there will be no packet drops unless the whole connection drops.
I would however suggest you to have one characteristic per direction. The reason is that some Bluetooth stacks can not in a thread-safe way both send and receive data on one single characteristic, due to the API design structure. In particular, Android's API has one method to set data on a characteristic and another method to send the current data of a characteristic. If a notification arrives in between these calls (where the bluetooth stack internally assigns the new data to the characteristic), the write operation will send the data that was just notified, instead of the intended data.
You could also check out L2CAP Connection oriented channels (introduced in Bluetooth v4.2) which is a good way to transfer raw data byte packets, when the GATT structure is not appropriate.
Related
My goal is this: I have a bunch of sensors out in a field connected in a sort of P2P network. On one side of the field I have a device that provides a BLE server to bridge data between a controller (phone or laptop) and all the devices out in the field.
One of the requirements is a sort of network visualization and management service. The gotcha with this is that there are a variable number of devices out in the field.
I have a plan to have the bridge device send a broadcast out to the network to get all the devices connected. My only problem is that I'm relatively new to BLE and GATT in general and I'm not certain what the standard is for showing a list of data with a dynamic length.
Is there such a standard? Do any of you have any tips to help me wrap my head around how to organize this into a GATT?
Thanks for your help
To the best of my knowledge, BLE and GATT don't have any best practice or pattern that would fit your requirement. So you have to roll your own.
An option would be to implement a request–response protocol: The controller sends a request to the BLE server (e.g. requesting the data for sensor 17) and the server responds with the data.
In GATT terms, the server provides a service with two characteristics:
The request characteristic (writable)
The response characteristic (readable with notifications)
For communication with the server, the controller connects to the server and activates notifications for the response characteristics. Then it writes the request to the request characteristic and waits for an update on the response characteristic.
As BLE has a low bandwidth, you should use a compact, binary protocol (and not JSON or XML).
I have a remote sensor that talks to the world via a low bandwidth TCP connection over GSM. It can often be in a location with extremely patchy GSM connectivity though. At the moment, the remote sensor waits for a GPRS network and then initiates a TCP connection with the server and then listens for commands (which are only a dozen or so bytes every hour or so)
Is an SMS more or less likely to get through to the remote sensor than being able complete a TCP connection? I guess I'm wondering how likely it is that a network signal strength is sufficient for SMS but not for TCP.
Using standard text messaging services for M2M is good idea if you can fit your data in 140 bytes. For short transmissions, opening an GPRS/1xRTT (2G) IP session, transmitting the data to a server and closing the session is less efficient and more likely to go wrong than sending an SMS.
As a side note, you can also use SMS (MT-SMS) to bring IoT device online (mechanism called "Shoulder-Taps" ).
Compared to data (or voice), SMS use only the signaling part of the mobile network. It's a quite cheap operation in terms of network resources reservation so you'll more likely get through with an SMS than with a data connection in a weak signal environment. One additional advantage is much lower power consumption of your terminal which might be important for M2M context.
As stated by #Jarek previously, you need to be able to pack your data into 140 bytes or to forge "long" SMSes which are kind of concatenation of "simple" 140-bytes SMSes
Say I have a BLE device that is both a server(has info) and a peripheral(needs to access outside info), that upon receiving or generating it's own data has to share with other Server/Peripherals in it's vicinity.
Would it be beneficial that I only attempt to connect to the devices through BLE when their is data to be transfered "even though it periodically connects to each server sequentially to see if it can" or would it be better to keep connections simultaneously use callbacks to determine when connected and simply transfer data when required to(through from what i understand the devices that I use can only process on gatt operation at a time meaning having 4 connections to quickly transfer data is irrelevant).
In other words is it beneficial to continually reconnect and disconnect a peripheral and server or simply have a connection to as many servers as I need(even though apparently I can only perform one gatt operation at a time i.e 1 characteristic read/wright).
balanced requirements.
If possible, instead of reading to see if there's data available, I would stay in connection with the devices and have them use Bluetooth notifications to communicate data when it becomes available.
Alternatively you could consider having the Peripherals advertise only when they have data to invite the Central mode device to connect. It would need to be periodically scanning to detect this however.
Advantages/disadvantages depend on your priorities and the nature of the two types of device.
FYI you're mixing terminology a little btw. When discovering devices you have a GAP Peripheral which advertises and a GAP Central which scans. After the Central connects to the Peripheral connect you have a GATT Client and a GATT Server. Usually the GAP Peripheral becomes the GATT Server but it does not need to be this way. The GAP Peripheral can just as easily become the GATT Client. It's the GATT Server that has the state data in an attribute table in the form of Services, Characteristics and Descriptors.
As I understand, BLE indications are a reliable communications method. How do you know if your indications was not communicated. I am writing code for the peripheral/server and currently when I send a notifications, I get a manual response from the central. I read that if I use indications, the acknowledges take place in the L2CAP layer automatically and communications is therefore faster, but how does my embedded controller know the Bluetooth module was not successful at getting the packet across the link? We are using the Microchip RN4030 Bluetooth module.
Let's make things clear.
The BLE stack looks roughly like the following. The stack has these layers in this order:
Link Layer
HCI (if controller and host are separated)
L2CAP
ATT
GATT
Application
The Link Layer is a reliable protocol in the sense that all packets are protected by a CRC and every packet is acknowledged by the receiving device. If a packet is not acknowledged, it is resent until an acknowledge is received. There can also only be one outstanding packet, which means no reordering of packets are possible. Acknowledges are normally not being presented to upper layers.
The HCI layer is the communication protocol between the controller and the host.
The L2CAP layer does almost nothing if you use the standard MTU size of 23. It has a length header and a type code ("channel") which indicates what type of packet is being sent (usually ATT).
On the ATT level, there are two types of packets that are sent from the server that are not sent as a response to a client request. Those are notifications and indications. Sending one notification or indication has the same "performance" since the type is just a tag of a packet that's sent over the lower layers. The differences are listed below:
Indications:
When an indication packet is sent to the client, the client must acknowledge the packet by sending a confirmation packet when it has received the indication packet. Even if the indication packet is invalid, a confirmation shall be sent back.
Upper layers are not involved sending back the confirmation.
The server may not send a new indication until it has received a confirmation from the previous one.
The only time you won't receive a confirmation after an indication is if the link is dropped (you should then get a disconnected event), or there is some bug in some of the BLE stacks.
After the app has sent an indication, most BLE stack confirms to the app that that a confirmation has been received by the client as that the indication operation has completed.
Notifications:
No ATT layer acknowledges are sent.
"Commands and notifications that are received but cannot be processed, due to buffer overflows or other reasons, shall be discarded. Therefore, those PDUs must be considered to be unreliable." However I have never noticed an implementation actually following this rule, i.e. all notifications are delivered to the application. Or I've never hit the max buffer size.
The GATT layer is mostly a definition of how the attribute protocol should be used and defines a DB structure of characteristics.
Implications
According to my opinion, there are several flaws or issues with the BLE standard. There are two things that might make indications useless and unreliable in practice:
There are no way to send back an error response instead of a confirmation.
The fact that it is the ATT layer that sends back the confirmation directly when it has received the indication, and not the app when it has successfully handled the indication.
This means that if for example, some bug or other issue causing that the BLE stack couldn't send the indication to the app, or your app crashed, or your app found your value to be invalid, there is no way your peripheral can aware of that. Since it got the confirmation it thinks everything is fine.
I can't understand why they defined indications this way. Since the app doesn't send the confirmation but a lower layer does, there seems to be no point at all in having an ATT layer acknowledge instead of just using the Link Layer acknowledge. Both are just acknowledges that the packet has been received halfway of its destination.
If we draw a parallel to a HTTP POST and internet, we could consider the Link Layer acknowledge as when the network card of the destination receives the request and the ATT confirmation as a confirmation that the TCP stack received the packet. You have no way of knowing that your web server software actually did receive your request, and it processed it with success.
The fact that notifications are allowed to be dropped by the receiver is also bad. Normally notifications are used if the peripheral wants to stream a lot of data to the central and then you don't want dropped packets. They should have designed the flow control so that the Link Layer stopped acknowledge incoming packets instead until the app are ready to process the next notifications. This is even already implemented at the LL + HCI + Host layers.
Windows
One interesting thing about at least the Windows BLE stack is, if it receives indications faster than the app processes them it starts to drop the indications as well, even though only notifications should be allowed to be dropped due to "buffer overflows or other reasons". It buffers at most 512 indications in my tests.
That said
Just use notifications and if you want some kind of confirmation, let the client send a write packet when it has received your data and successed processing it.
Reading the docs, i have built 2 apps that connects 2 iDevices using BLE.
One device is Central, and the other is Peripheral.
The Central is looking for the Peripheral , and when find it, explore its services and characteristics, than connect to the relevant characteristic.
When an update is come from that characteristic i want to respond with data from the central to the peripheral .
Question is , do i have to switch from central to peripheral at one side and vise versa at the other side , in order to respond ? means, if i wants to make a simple chat, they always have to switch?
if yes- that makes it a problem to chat because there is a possibility that both devices went to peripheral and are trying to send messages at the same time.
So, if there is a way to make a bi-directional communication, how would one perform that, and any links with tutorials about that would be great . thanx.
The BLE communication is bi-directional already.
Central -> Peripheral: write a characteristic.
Peripheral has to have a writable characteristic.
The Central can write that characteristic this way sending the data.
Central <- Peripheral: update the value of the characteristic that the central has subscribed to.
Peripheral has to have a dynamic characteristic that it updates the value of.
The Central subscribes for notifications/indications on that characteristic.
The Peripheral updates the value of the characteristic which in turn sends a notification with the updated value to the Central.
To see how it works, check out the BTLE Transfer demo. You should spend some time studying the way it operates. The Core Bluetooth Programming Guide also has great examples to get a deeper understanding.