In Bluetooth, specifically 4.0 LE (if this changes anything), what is the way to send data both ways, from master to slave and from slave to master?
What kind of protocol is it better to design? Can you please provide an example of an application level protocol that is typically used in this scenario?
In this case, should the peripheral run two services, one used for sending data to the device and another to receive data from the device? (The "device" is the peripheral/slave).
The most forward way of doing this would be to define a custom service which defines the data types and fields and access you need as characteristics, and implement this on both the peripheral and central. If you are looking for a symmetric system, you can implement the same service on both sides. If there is differences in how the two devices access/send data, you can implement two different services, suiting your needs. Either way, you will need both the slave and master peripherals to support both GATT server and GATT client.
Depending on what you want to do, you could either push data using notifications (unconfirmed, you may miss updates on the receiving side) or indications (confirmed, the receiving side will have to acknowledge the push), or you could pull the data using read commands. You could also combine these in various ways, and you could implement access to different data in different ways in your service(s).
I recommend taking a look at the different Bluetooth Low Energy vendors' dev kits and APIs, as well as the different phone/tablet APIs and examples, depending on which platform you aim to develop on/ are familiar with.
Related
I've been pouring over the BT 4.x (LE) spec trying to figure out if this is possible or not (events without pairing/boding).
Does anyone have an insight (and link to the spec preferably) if it's possible?
As Mike Petrichenko commented, GATT communication is definitely possible without pairing. In fact most GATT servers/clients out there function without the need for pairing/bonding. The only exception is when some characteristics require authentication/authorisation in order to read some data (e.g. a medical device with a Heart rate characteristic).
If you want a specific reference to where this is mentioned in the Bluetooth spec, then I recommend looking at the Core Specification version 5.2, Vol 3, Part C, section 10.2 (LE Security Modes):-
The security requirements of a device, a service or a service request
are expressed in terms of a security mode and security level. Each
service or service request may have its own security requirement. The
device may also have a security requirement. A physical connection
between two devices shall operate in only one security mode.
It is then mentioned that LE security mode 1 has the level No security, and many GATT servers/clients work in this level.
You can test this yourself if you have two phones available. You can use the nRF Connect app to run a GATT server on one and a GATT client on the other. You will see that you can browse the GATT table and read data without having to pair.
Below are a few links that contain more information:-
Is pairing/encryption mandatory to allow a peer to write in GATT
Bluetooth Low Energy GATT security levels
How GAP and GATT work
My question is very brief - In the Zephyr documentation, I couldn't find an answer to my question (which surprised me). Is it possible for a GATT Client to connect to more than one GATT Server?
Right now I am using two boards to compute something (one as a server and one as a client). Ideally, the result of the computation should be written to a characteristic on a third device, another GATT server.
You're right I couldn't find this information easily but it is certainly possible to have multiple connections as I've tried this myself before. Many application and products built on Zephyr also rely on this feature. Generally speaking, there is no limit to the number of BLE connections that is imposed by the Bluetooth specification, but the limitation is usually dictated by the hardware. This is somehow mentioned in the Zephyr link below:-
https://docs.zephyrproject.org/latest/guides/bluetooth/overview.html
I hope this helps.
I am trying to write a little Zephyr OS runtime system that uses BLE to communicate between my two nrf52840dk boards. I have spent the past couple of days reading up on BLE and have gotten acquainted with GATT servers/clients.
The API I would preferably have looks something like this:
/* Send a message to conn */
void send(struct bt_conn *conn, void* data, u16_t len);
/* Callback which is invoked when a message is received from conn */
void recv(struct bt_conn *conn, void* data, u16_t len);
What I have managed to do is achieve something similar by limiting my system to two devices, one being a GATT server and one a GATT client.
The server exposes one attribute which the client scans for and subscribes to. The server can 'send' a message to the client by notifying it about a change to the attribute, and it can be sent messages by the client issuing a write request to the attribute.
The client can send messages to the server by writing to the attribute, while it can receive messages by the server notifying it of an update to the subscribed attribute.
I am thinking that primitives such as these ones must exist underneath the GATT layer (in the HCI layer?), but the Zephyr documentation is quite sparse at most places. Following this, I have two questions.
Is my understanding of BLE correct, that most communication between BLE devices happen through such GATT server/client relationships, or through BLE mesh networks?
Any pointers to information regarding where I can read up on writing the more generic API I described above (or if it already exists, pointers to that) would be helpful.
edit: I've accepted Youssifs answer. His answer together with the comments beneath it adequately answers my question.
Is my understanding of BLE correct, that most communication between BLE devices happen through such GATT server/client relationships, or through BLE mesh networks?
You are correct in that most applications out there will be using the GATT server/client relationship. This is because when Bluetooth Low Energy was introduced in 2010 (and later launched with iPhone 4s through CoreBluetooth in 2011), this was the only method of communication. Since then, subsequent releases of BLE introduced newer methods of communication:-
LE L2CAP (introduced in BT v4.1, 2013) where lower level communication channels were used for fast and direct data transfer.
LE Mesh (introduced in 2017) where most of the communication is based on BLE adverts and therefore any device that is on v4.0 can theoretically support it.
The problems with both of these methods are the relative complexity and the slow adoption by vendors. As such, my recommendation is to continue using GATT examples/applications until you're more familiar with BLE and then proceed to using the other methods of communication.
Any pointers to information regarding where I can read up on writing the more generic API I described above (or if it already exists, pointers to that) would be helpful.
You've probably already seen this, but the Getting Started Gudie of Zephyr is quite useful. You can then use the Central HR example on one board and the Peripheral HR example on the other to get two way communication. Once this is done you can start customising your applications to match your needs. A list of all Bluetooth examples can be found here.
Below are further resources on BLE development in Zephyr:-
https://www.novelbits.io/zephyr-getting-started-bluetooth-low-energy-development/
https://devzone.nordicsemi.com/nordic/nrf-connect-sdk-guides/b/getting-started
https://electronut.in/getting-started-with-zephyr-rtos-on-nordic-nrf52832-hackable/
I hope this helps.
This is my first question in Stackoverflow :)
I'm trying to make few modifications to the Ti Sensortag but I have few questions please:
1- is it possible to make the sensortags communicate with each-other without a gateway?
(lets Say I put Sensor1 in bedroom 1 and sensor 2 in bedroom 2 can I make them exchange readings without the need for a gateway?)
2- can I install a micro USB over the interface connector to be able to use a portable battery pack? (photo of the interface connector)
thanks
You'll get better more in depth responses on the TI support forums as Ifor has said.
However, I can tell you the answer to #1... Regular bluetooth allows for things like piconets, but Low Energy does not. With LE you have a client/server (master/slave) connection between two devices only. It may be possible to modify the firmware on the sensortags to allow them to make connections to other sensortags, but then they'd have to give up whatever connection they currently had to do so. The master devices can connect to multiple slave devices, but the slave device can only be connected to one master.
As the sensortags are currently designed, I think they only work as a slave (server) device.
Press releases say that the new 4.1 spec allows for a single BLE device to act in both roles--central and peripheral eliminating the need for a gateway. A 4.1 update is, in theory, possible with 4.0 radio hardware like the SensorTag has. I personally haven't seen an example of this however and SensorTag processing resources may be a limiting factor to a dual role.
The Battery Pack connector breaks out VDD_EXT and GND and the SensorTag hardware schematic is available. Analysis by a hardware design engineer should be able to determine the suitability of a USB source powering option.
http://processors.wiki.ti.com/index.php/SensorTag_User_Guide
Is it possible to implement Bluetooth devices to provide conference rather than one-to-one operation.
Are there any development toolkits that will allow me to configure BT devices in this way, or modifications that can be done to the BT stack or an add-on protocol.
I need to configure several Bluetooth adaptors to simultaneously communicate with one another. I think BT allows up to 10 'pico-nets' but I need specialiced advice.
I would welcome any links to resources, or replies from Bluetooth experts.
Thanks in anticipation.
I've heard of something close to this, called a piconet. Googling "bluetooth piconet" should point you in the right direction.
A master device can be networked in this way with up to 255 slave devices, but only 7 can be active at any one time. This is more of a one-to-many communication than many-to-many, but could potentially be approximated by having the master device act like a network switch.
Update: I just read that slaves in one piconet can participate in another piconet as either a master or slave, forming a "scatternet".