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.
Related
I am using Bluetooth Mesh technology for a project. The Bluetooth mesh works on flooding, and the message types are defined in the profile. However, I could not find whether I can include a custom payload in the messages to be delivered across the network. Is it possible to do this in Bluetooth Mesh? If yes, please suggest any resources that explain the functionality.
First of all you should visit the Bluetooth SIG. They own and publish all Bluetooth standards. They also maintain a comprehensive list of all specifications including those dealing with 'mesh':
https://www.bluetooth.com/specifications/specs/
And Nordic also provides extensive documentation with examples for its nRF5 SDK for Mesh:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fstruct_sdk%2Fstruct%2Fsdk_mesh_latest.html
Bluetooth Mesh is based on Model interaction. If your application does not fit into available (defined by SIG) models, you can create your own (Vendor) models. In that case you can define opcodes (which should not interfere with opcodes of other messages) and customize transferred data.
More information on how to create you own model, in case you are using Nordic SDKs you can find here: for nRF Connect SDK or for nRF Mesh SDK.
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 experimenting with Bluetooth Low-Energy (BLE) for the purpose of connecting a hardware device to an Android application. My goal is to send a recognizable piece of data to an Android phone.
I am using the keyfob from Texas Instrument's CC2541 Mini-development kit, and am programming it using the IAR Workbench (which I am learning on the fly). My issue is that I cannot figure out what code should be used to send data from the keyfob to the phone.
I understand that this is somewhat vague, but because of the non-disclosure policies of my company I cannot share the code that I am working with. Does anyone have any references to code for the IAR Workbench that will allow the CC2541 to send a piece of data? Right now, I prefer to use GATT if that helps.
Thanks, and please ask me more questions if I need to clarify anything.
Assuming you're working from a pre-existing service profile, there is a function for every service called ServiceName_SetParameter(). Calling that function will change the characteristic value. When the characteristic is read by the phone, it will receive this value. If the characteristic supports notifications, and your phone has registered for notifications on that characteristic, the new value will be transmitted whenever SetParameter is called.
You can implement any proprietary protcol to connect to and interact with your beacon device. It can assume other roles than just the beacon task. It can also listen to and respond to connection attempts thus expanding into a lot more than a regular beacon.
If you study the cc2541 close you realize it is a pretty advanced IO controller that offers a lot of IO signal possibilities. That way you could use the cc2541 as the heart of an IO control application where you measure and control equipment. Mobile apps can then easily connect to your beacon/IO Controller device and interact with the machinery it is hooked up to. As you see, it´s a remarkably versatile system on chip and a cool circuit to learn to program.
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.
I need to connect to a Bluetooth device through virtual COM port created in Windows. It's easy when the port has been already created during manual pairing procedure. But I would like my application to relieve an user from the manual pairing of a device. I would like to present all devices in the range, allow user to chose one, and then create virtual COM port connected with the selected device. I'm not trying to avoid the pairing procedure itself, but rather I would like to invoke it by my application.
I started getting familiar with Microsoft Bluetooth API. And then some doubts arose. I've been wondering what happen if some user would use different (than Microsoft's) Bluetooth stack? Is the Microsoft's API the real Bluetooth API, which have to be implemented by any other Bluetooth stack provider? Or rather each provider has its own API, and the Microsoft's is only one of many other?
Thanks everyone for valuable input. I'd like to summarize what I've found so far. The Microsoft Bluetooth API is not operating system API. Application written against it will not cooperate correctly with any other Bluetooth stack. It seems that applications which are intended to cooperate with multiple stacks need to provide some stack abstraction layer, and stack specific code for all of them.The other solution is to allow user for manual pairing of the Bluetooth device, which eventually create some virtual device in the operating system (e.g., COM port). Then the application can use standard interface of such a device.
I can't speak for the Microsoft Bluetooth API, but there are multiple Bluetooth stacks available for the PC platform (even more for mobile devices).
The underlying API is defined by the Bluetooth Core Spec and so all stacks should be able to interact, in fact it is mandatory that they interop or they cannot use the Bluetooth name and logo.
As to pairing, your going to have a hard time getting devices to pair if they have default security, which requires a pin code.
Things might be simpler in the (near) future, as the Bluetooth standard has introduced a new security model, secure simple pairing, which has a 'just works' mode that requires no Pin code. This is still stronger then the current security, except against Man in the middle attacks. However, it could be a while before you see the chips with this feature in PCs.
If you can change to using .NET :-/ I can recommend our library 32feet.NET.
For explicit pairing there's BluetoothSecurity.PairDevice. We can also create the virtual port for you, for example:
BluetoothClient cli = new BluetoothClient();
BluetoothDeviceInfo[] list = cli.DiscoverDevices();
BluetoothDeviceInfo selected = GetUserToSelectOne(list);
BluetoothSecurity.PairDevice(selected, pin);
// Ask Win32 to create a virtual serial port
selected.SetServiceState(BluetoothService.SerialPort);
However I really don't like virtual serial ports so I always suggest that people use a normal sockets connection using our BluetoothClient class, it will automatically handle a pairing request if required.
On Win32 we support the stacks from Microsoft, Widcomm/Broadcom, and BlueSoleil. On Widcomm there's no support for SetServiceState there yet, and their API has no support for responding to pairing requests. BlueSoleil should support both.
A brief user's guide is at 32feet.NET — User’s Guide, and all the class documentation is available at the main site http://32feet.net, the Widcomm documentation is only in our code repository at the moment.