Could anyone clarify a bit about Bluetooth mesh gateways' implementations. I wonder to know possible ways of Bluetooth mesh gateway implementations. How is it possible right now?
If I have a SoM (for simplification it could be a Raspberry Pi board) with Linux, which uses BlueZ stack underhood, and I want to control Bluetooth mesh network from it. Is it possible to directly control Bluetooth mesh nodes, sending packets to them and receiving packets from them throught Bluetooth mesh? Should be the gateway a part of Bluetooth mesh network as a separate node? It seems that nRF Mesh mobile app from Nordic employes a specific opportunity to control devices via PB-GATT packet, connecting to a Bluetooth mesh node with Proxy feature. A mobile device connects to the node using Bluetooth LE and encapsulates Bluetooth mesh packets, sending through this node, and not directrly, using Bluetooth mesh advertising packets. So, could anyone clarify, is it possible to control Bluetooth mesh networks from such kind of device with Linux? And if yes, where could I look to understand, how it's possible? And if no, which options do we have to control Bluetooth mesh network from the gateway? Do we need to connect a microcontroller (like nRF52840 or ESP32) via UART/SPI to our host MCU and write a custom firmware for it to control Bluetooth mesh network, using this microcontroller as a proxy between gateway and Bluetooth mesh network? Or could we control the Bluetooth mesh network, connecting to a arbitrary Bluetooth mesh node with Proxy feature through Bluetooth LE and control the the network, encapsulating packets, as it nRF Mesh mobile app does?
How do companies realize their Bluetooth mesh gateways? How do they control the mesh network from them if BlueZ doesn't support a native Bluetooth mesh controlling (only provisioning)?
Thank you in advance for any assistance with understanding such the details and any recommendations. It would great to hear others' thoughts about this problem.
Related
I have a device that can only be controlled by bluetooth on a specific phone. Would it be possible to use a second phone to act as a relay or proxy close enough to connect via bluetooth to the device, but kind of feign the connection with the first phone over the network?
You'd want to make a mesh network.
https://www.bluetooth.com/blog/introducing-bluetooth-mesh-networking/
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.
My knowledge in both bluetooth beacons and Arduino is limited at this point.
This is for an indoor positioning system I'm thinking to develop. Is it possible to create an Arduino board where the BT module receives a BT beacon ping with the Beacon ID, and then relays this data to a Wifi module on the same board, to then send it out to a server/local server of some sort?
Is this feasible? Or is it even possible the receive the ID of the beacon using Arduino?
I've attached an image of what I was thinking of:
Yes, this is absolutely possible. I have done the same with a Raspberry Pi. I am not an expert on programming the Arduino but I know for sure that both parts (beacon detection and decoding) and calling a web service over WiFi are possible with the Arduino.
My question is very basic.I need to know where does all Bluetooth profile such HID, HFP or HSP loaded in Bluetooth stack? Is it in Host layer or in Bluetooth Hardware Chipset such as USB dongle/module or in both Host and Chipset Side?
According to my understanding, we can implement Bluetooth profiles on Host side using packages like BlueZ but at same time Bluetooth chipset which is connected to Host should need some sort of firmware and logic(like CSVD, A-law ) inside its chipset.
A quote found in BlueZ Android package doc: "Wideband Speech support in HFP it is required that BT chip assumes mSBC codec". This means Host layer can implement that Profile only if BT chipset provides the low-level support like mSBC.
My Answer is like this: " We can build any Bluetooth Profile say 'X' on Host layer if BT chipset is equipped with underlining Low-level firmware which support the Profile 'X'".Please agree or disagree with my understanding.
PFA diagram of my understanding
Position of profile and its low-level firmware
I need to select a USB Bluetooth dongle compatible to Raspberry Pi and customize the HID and HFP using BlueZ.
Advance Thanks to all Bright minds!
There are multiple ways how Bluetooth functionality is implemented in a system based on how much is implemented in the controller and host.
Everything in the controller - App, Upper stack, may or may not HCI(lower and upper stacks communicate through HCI commands and events), Lower stack. Example: Most of Bluetooth Mouse, Keyboard etc, where a single controller is responsible for everything (Bluetooth, RTOS/scheduler, Controlling LED's in the device, etc)
App in Host and lower and upper part of stack in controller. May or may not implement HCI in controller.
Example: Where we use a dedicated Bluetooth chip and integrate it with the Device. Here device will transmit application data to the Dedicated Bluetooth chip. All the Bluetooth protocol related things will be done from BT controller/chip. If you are using an HC-05 module with Arduino module, Arduino will transfer the serial data to the HC-05 module.
App and upper stack in host and lower stack in the controller. Bluez, Bluedroid and all other stacks in Operating systems are of this type. This will communicate with the controller with HCI commands and events.
Example: Mobile phones, Computers, TV with Bluetooth etc (Devices having a powerful Application processor)
So lets assume you are asking about the 3rd type. In this case your assumption is correct. Here all profiles are implemented in the host only. But protocols/codec needed to support them will be implemented in the controller(either firmware or hardware block). For example GAP(For BR-EDR) is implemented in the host but encryption and decryption algorithms are implemented in the controller as Firmware or hardware blocks. For A2DP profiles audio codec/decoders will be implemented in the controller. BT chip then transfers this audio data to host with I2S or other protocols. For BLE Security manager profile, encryption/decryption algorithm is implemented in the host itself, But whitelist, auto connection etc, will be implemented in the controller.
My Answer is like this: " We can build any Bluetooth Profile say 'X' on Host layer if BT chipset is equipped with underlining Low-level firmware which supports the Profile 'X'".Please agree or disagree with my understanding.
For BlueZ use case this is correct. You need to use the controller with the required hardware capabilities(Firmware + hardware resources).
For the scenarios 1 and 2 the profiles and supporting protocols will be implemented in the controller.
I am finding out about BLE on the Internet. I don't understand why everybody use GATT server for the device, such as KIT. And use GATT client for the application on mobile?
Can you explain for me?
Thank you very much!
The roles in Bluetooth are Central and Peripheral. Typically the computer/mobile device will have the central role and the Bluetooth device (let's say a heart monitor) will be the peripheral.
The central will initiate a connection to the peripheral. If you were to think of it in client/server terms, the heart rate monitor is the server (it serves heart rate data) and the mobile application is the client (it is receiving the data) but as I said, this isn't the right terminology for BLE.
BLE devices often have limited or no user interface capability while the mobile device has a touch screen - so it is much easier to discover and connect to a peripheral from a mobile device acting as a central than if the roles were reversed.