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.
Related
I am working on a project that involves Bluetooth Mesh Network (based on BLE) that was standardized with Bluetooth version 5.0. I am searching for a suitable simulator for at least some of the following solutions.
Mesh message delivery (Flooding)
Ability to simulate an environment (Path loss, multipath fading)
Can someone help me find a simulator as the one explained above?
Probably the best easy and cheap option is the nRF Mesh app for Android/iOS devices. It might not be advanced to do full simulation but you'll find most of what you need to get started and then you can tweak things or expand from there manually.
More information is available here:-
nRF Mesh app features
The ultimate Bluetooth mesh tutorial (Part 5)
A developer's guide for proving mesh interoperability
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.
I’m using the custom gatt package found in movesense-device-lib/samples/bin/release/Movesense-custom_gattsvc_app_w_bootloader.zip for my project. I can't create my own package since there's a bug in the mac compiler.
I really need to the service and characteristic UUIDs for ECG (in fact if I could get the services/characteristics of the other features in the package that’d be great too)
There're links to a sites that give the uuid for certain characteristics and services, such as these ones:
GATT Services
GATT Characteristics
Unfortunately, since the movesense package is custom made, it uses different UUIDs. I tried backtracing them by writing a function on my client that pulls an arraylist of the services and the characteristics, but no luck :(
The custom_gattsvc_app is a sample app that shows how to use Movesense CustomGATTService to implement your own (or someone elses) GATT service. The sample shows how to do that by implementing the (partial) "Medical Thermometer" GATT service, nothing else.
To access all of the Movesense API over BLE you'll need to use the movesense-mobile-lib or implement your own protocol over your own GATT service. I'm not aware of any 3rd party ECG GATT service specifications.
The movesense-device-lib release 2.0 will include a sample that provides access to most of the Movesense API services and easy expansion over a simple GATT protocol.
Full Disclosure: I work for the Movesense team
I have read in a couple of places (but nowhere official) that you need to use a smartphone to setup and add devices to a mesh. Is that true? Can you not do it with IR or a NFC? What are my options?
Bluetooth Mesh defines the Provisioner as the device that is able to create a mesh network and add (provision) new nodes into the network.
A Provisioner does not necessarily have to be a smartphone, although that will generally be the case. Provisioning is performed over Bluetooth channels - either over advertising channels (using a new protocol defined by Bluetooth Mesh), or over GATT (to support legacy smartphones that cannot advertise custom AD types).
To provision nodes over the advertising channels (the so-called PB-ADV bearer), the smartphone OS needs to be updated to allow developers to implement the PB-ADV protocol. That is not likely to happen soon enough.
Therefore the best option will be to provision nodes over GATT. The unprovisioned node (e.g., the sensor) will have to include the Mesh Provisioning Service in its GATT Database. The smartphone (as GATT Client) will connect and discover this service, and use its characteristics to exchange Mesh Provisioning PDUs.
You can wait until some companies will develop these smartphone apps, or, if you are in a hurry, you can grab the Mesh specification available on the Bluetooth website and develop a provisioning app yourself. The current smartphones' OS allows you to develop a GATT Provisioner (both on Android and iOS).
In general, a phone/tablet class device is needed for provisioning. IR or NFC can be used for OOB authentication, but the full Bluetooth mesh stack is required to initiate and complete the provisioning process.
A good reference as an introduction to Bluetooth mesh can be downloaded from the bluetooth.com web site Bluetooth mesh Introduction for Developers.
At the moment, the best place to start is the Nordic Mesh SDK that uses the Bluetooth SIG mesh. This has an example (for lighting) where a Bluetooth device itself does the provisioning. There's also a 'Serial' example where, again, a Bluetooth device does the provisioning connected via UART to USB that can be controlled via a desktop/laptop. You could extend the examples so that the provisioning BT device has extra GATT services that open up the provisioning to smartphones.
I understand that Bluetooth profiles consist of other profiles and protocols. What I don't understand is exactly how Bluetooth devices interact with each other. For example, if you take any accessory that implements the A2DP profile and connect it to the iPad then the iPad will stream all audio output to it. This makes me believe that a profile is nothing more than a modular component in a well-defined eco-system. For instance, a web-browser can use any one of your choice of search-engines in the toolbar; would I be correct in saying that the iPad is the equivalent of the browser and the A2DP accessory is the equivalent of the search-engine? Would I also be correct in saying that the use of A2DP is entirely up to the device it's paired with? That is, Apple could have instead chosen (albeit unwisely) to make the iPad output only key-clicks and ring-tones to it, correct? So there's nothing inherent in the A2DP profile that says "All devices using the A2DP profile MUST output all audio to it" right?
I'm not 100% familiar with Bluetooth as a whole. I've been spending some time drafting a profile for BT Low-Energy, so someone might be able to provide insight on standard Bluetooth with a little more detail.
But, from what I understand, the profiles are essentially a large map of connected references. So the A2DP profile will have a list of attributes, or rather, a list of HEX values which point to attributes within the larger profile. These attribute are typically universally available to all profiles, but only implemented by the profile where they are needed. These attributes define some piece of information that is going to be transmitted. This profile needs to be on both device to communicate, because this allows to Bluetooth transmissions to be smaller by only referencing a commonly known definition of the data it is transmitting (rather than defining what the data is in every transmission like some communication types).
So for A2DP, the transmission might be something very simple like '0x1351458 0', which tails the device that whatever that profile attribute is, it's value is 0. So that attribute might be the "play" attribute, so setting to 0 might stop the music.
Again, this is how I understand Bluetooth profiles from the Low-Energy standpoint which tends to be more a transmission of state than actual data, so it might differ a bit with regular Bluetooth.
Bluetooth profiles are specifications of bluetooth protocols that are implemented on the host side in bluetooth protocol stack.
Following link by bluetooth.org will provide basics about bluetooth profiles
https://developer.bluetooth.org/TechnologyOverview/Pages/Profiles.aspx
Bluetooth Profiles are set of standard interoperable guidelines defined by bluetooth.org, to ensure interoperability between different bluetooth devices.
Bluetooth devices claiming to support bluetooth profiles, should get Bluetooth Qualification Board[BQB] certified for interoperability.
You can buy any device supporting A2DP and test with any tablet/computers[which has bluetooth A2DP profile supported].
A2DP is not specific to iPad. It is a generic profile that stands for Advanced Audio Distribution Profile for exchanging Audio between two bluetooth devices.