I was wondering in order to have mesh in the Bluetooth, should it be supported by the physical layer or it is related to the higher layers? in particular, what factors should be considered for the physical layer in order that It supports mesh topology?
Bluetooth Mesh uses the same Bluetooth Low Energy Advertisement packets. It uses the same 2.4 GHz Spectrum and GFSK Modulation scheme. Only the higher level layers may change depending on the software architecture. On the Physical layer, it uses the same Bluetooth Low Energy PHY. So, it uses the ADV channels 37, 38 and 39 for communication between nodes.
If a chip or device has Bluetooth v4.0 and above, it can support Bluetooth Mesh.
It needs one of the PHY to be supported (i.e) LE 1M, LE 2M, LE Coded PHY. Some chip vendors may not fully support all the PHYs. Bluetooth Mesh was introduced prior to Bluetooth v5.0 and hence some devices which support Bluetooth Mesh might not support all the Bluetooth v5.0 features. But Bluetooth Specifications does not restrict in using specific PHY.
The Bluetooth Mesh Specifications says it supports GAP AD Types and Mesh Beacon AD Types specified in the Core Specifications. So, If the device supports secondary advertising(BLE v5.0 and above), then most likely, the device is able to support all the AD Types.
Related
i want to know the fundamental difference between BLE and Classic Bluetooth and why exactly is BLE low power?
There are quite a few differences between Bluetooth Classic and Bluetooth Low Energy including:
Classic Bluetooth operates on 79 frequency channels, whereas BLE uses only 40.
Classic Bluetooth has a higher throughput than BLE, although the gap is becoming narrower with newer versions of BLE.
A classic Bluetooth device can only be connected to 7 other devices, there is no theoretical maximum to BLE.
The two use different mechanisms for broadcasting/connection. Classic only devices cannot find or connect to BLE only devices and vice versa.
The list goes on beyond the above to the point that it is more common to assume that they are two protocols only sharing a few technical similarities and the same standardisation body (The Bluetooth SIG).
As to what makes BLE low power, this lies in the duty cycle of the protocol. BLE devices sleep for most of the time they are not in operation, and only wake up to send bursts of data and then go back to sleep. Of course this depends on the use case; if an application continuously sends BLE data then there will be fewer sleep intervals and therefore the power consumption will match that of classic Bluetooth.
For more references regarding this question, please see the list below:
4 Key Differences between Classic Bluetooth and BLE
The difference between Classic Bluetooth and BLE
Bluetooth vs Bluetooth Low Energy (BLE)
Bluetooth vs BLE
Can a Bluetooth LE powered device discover a classic Bluetooth device and vice-versa?
I hope this helps.
I can't find a proper answer on the Internet.
The Bluetooth Basic Rate / Enhanced Data Rate (BR/EDR) appeared with the 2.0 Bluetooth Core Specification to improve data rate transfers. The Bluetooth Low Energy (BLE) appeared with the 4.0 Bluetooth Core Specification to improve consumption in the IoT field. Yet, to make those two modes work together (BLE & BR/EDR) you had to use a "Smart Ready" module (or dual-mode specific module).
Today, we have the Bluetooth 5. I don't quite understand if, when I browse Bluetooth 5 SoC on the market, the BR/EDR is implemented natively. For the BLE mode, it is. From a general FAQ :
Is the low energy feature of Bluetooth a part of Bluetooth 5.0?
Yes, Bluetooth with low energy functionality, introduced in Bluetooth 4.0, is a feature within Bluetooth Core Specification version 5.0. In fact, the new features and benefits of Bluetooth 5.0 are designed specifically for Bluetooth with low energy functionality.
But for the BR/EDR mode, the Bluetooth 5 Core Specification states (p323, Vol : 2 Core System Package [BR/EDR Controller Volume]) :
Two modulation modes are defined. A mandatory mode, called Basic Rate, uses a shaped [...]. An optional mode, called Enhanced Data Rate, uses PSK modulation [...].
So, from the Core Specification, the EDR mode is optional. Yet, I can't find any SoC or module (BT5 compliant) that has this EDR mode, like it doesn't exist anymore but everyone exhibit high data transfers (more than EDR used to be with previous version).
So, is the EDR implemented natively in BT5 (as the BLE is) even if the Core Specification states it as optional ?
Where am I wrong ?
Thanks !
"Most" things in the Bluetooth Core specification are optional. You can have a BT5-compliant Bluetooth Classic chip that doesn't have any LE functionality and you can have a BT5-compliant BLE chip that doesn't have any Bluetooth classic features.
To check whether a particular Bluetooth chip supports a specific feature, just look it up at https://launchstudio.bluetooth.com/Listings/Search.
As mentioned above, lots of things Bluetooth are optional, and the nomenclature is confusing and changeable.
Bluetooth Smart Ready describes modules that can do both Smart (ie LE) as well as classic. If you are looking for a Bluetooth Smart Ready module, we've successfully used the Silicon Labs (acquired Bluegiga) BT121 module in a couple of products where we needed SPP with high speed and range (BR/EDR).
Hope that helps!
Best Regards, Dave
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.
What I want to ask is - Will a BLE device be able to answer calls, play music, etc... or that Bluetooth 4.0 is intended for a kind of NFC alternative?
Bluetooth Low Energy is part of the Bluetooth 4.0 specification. Bluetooth 4.0 includes Classic Bluetooth, Bluetooth Low Energy and Bluetooth High Speed.
Bluetooth Low Energy (BLE) uses a different radio protocol with fewer, wider channels and a lower transmission rate and power than Bluetooth Classic (although it uses the same frequencies) and most importantly it implements a different set of profiles.
Classic Bluetooth has profiles such as Serial Port Profile (SPP) and Handsfree Profile (HFP) while the most commonly used profile in BLE is the Generic Attribute profile (GATT). This profile allows for the transfer of small amounts of data at relatively low speeds and is not suitable high-bandwidth time-critical applications such as audio streaming.
Dual-mode Bluetooth chipsets that support Classic Bluetooth and BLE are available although often they can only operate in one mode at a time. Many BLE chipsets are BLE only, however as it reduces cost and complexity.
The short answer is that BLE can't support the classic Bluetooth functions you described.
Bluetooth 4.0 has all backwards compatibility with it's older versions.
BLE is a form of connect using low energy technology.
BLE = Bluetooth Low energy.
They are different technologies with different proposes. BLE tend to be used in heart rate monitors, bike computers, medicinal applications and etc. Whenever the power supply is limited.
BLE intent is not for headsets and similar devices. That's why you see on phone specifications Bluetooh 4.0 + BLE (or LE). Bluetooh is a technology, BLE is a 'protocol of communication'
I searched on bluetooth.com , bluetooth.org but I didn't find any explanation about Bluetooth Smart Ready Device being low energy.
I know Bluetooth Smart Ready is dual mode. (Backward compatible)
My question is When Bluetooth Smart Ready is connected to older Bluetooth device, is it still in low energy mode or does it require more power(like older Bluetooth Devices) ?
Short answer: no it is not in low energy mode because it is not using the low energy subset of Bluetooth v4.0.
Long answer: Bluetooth v4.0 defines two types of transceivers:
Dual-Mode Devices (aka Smart Ready Devices): Dual mode devices include all the features of standard Bluetooth v4.0 (Classic Bluetooth + Bluetooth High Speed + Bluetooth Low Energy); BLE functionality is integrated into the existing Bluetooth controller. Dual mode devices, such as PCs and Mobile phones, can utilize the full package versions of the technology running side by side.
Single-mode Devices (aka Bluetooth Smart): single mode devices
implement the low energy protocol stack only. The single mode devices
benefit from the low power consumption and low cost of implementation
provided by v4.0. Therefore, the devices are cheaper and consume
less power than dual mode devices.
Hope this helps.
Bluetooth Smart means Bluetooth 4.0. The only common in Bluetooth Smart and the older versions is the frequency range.The communications is vastly different, requiring different radio hardware too.
So if a device is dual mode, it can either use the low energy, or the standard communication. And because of this, in standard mode, the energy consumption is the same as with the standard devices.
No, When a backwards compatible Dual Mode/Smart Ready device is connecting and transmitting on Bluetooth 2.1, 3.0 or EDR it is not Low Energy.
What makes low energy low energy is the short burst transmissions, packet size and the way the processing works. Being Dual Mode / Smart Ready just combines the necessary chips and antenna into one package for ease of manufacturing and design.
Bluetooth Smart Ready = Dual Mode, i.e. it can switch between BR/EDR (Classic) and BLE.
For BLE, it is first and foremost the protocol that makes it "low energy", i.e. low consumption.
So, when the Smart Ready device works in BLE mode, it is low energy. When it works in Classic mode, it is not low energy.