I am looking for a comparison of the Zephyr vs SoftDevice for BLE applications. There is a lot of talk on the internet about it, but nothing concrete. Has anyone used both stacks on the same SOC for the same app and can talk about the differences?
I am not sure if you mean the differnce between Zephyr and nRF Connect SDK (i.e. network core) or if you mean Zephyr vs Nordic SDK (i.e. Writing applications in Zephyr RTOS vs normal C applications) but I'll try to cover all scenarios. I've been using nordic devices for over a decade now and this is my input regarding the difference:-
Nordic SDK with SoftDevice
This is Nordic Semiconductor's proprietary software development kit (SDK) that includes a SoftDevice (a pre-compiled binary that implements the Bluetooth Low Energy stack) and a set of libraries for programming the nRF devices. The Nordic SDK with SoftDevice provides a high-level, easy-to-use API for Bluetooth development on the a variety of nordic devices including the nRF51 and nRF52. It also includes additional features, such as power management, security, and device management. The SDK + SoftDevice is what Nordic first released with their chips all the way back when they started BLE development. You can find out more about Nordic's SDK and softdevice in this very comprehensive guide by Nordic.
Pure Zephyr RTOS
Zephyr is an open-source RTOS that supports a wide range of hardware platforms (including Nordic's nRF devices). It is based on a small kernel that is designed for embedded systems. The beauty of the Zephyr OS is that it is open source and also includes all the modern-day RTOS functionalities such as multi-threading, interrupt servicing, memory allocation and more. Furthermore it has numerous libraries and applications for many embedded chips and external hardware (full list of supported HW can be found here). You can find out more in Zephyr's documentation here.
Some nordic devices such as the nRF51 and nRF52 now allow you to write applications in either Zephyr RTOS or using the previously mentioned SDK+softdevice. However, active development on the SDK+softdevice has stopped and Nordic have fully migrated to using Zephyr RTOS + nRF Connect SDK (the final option below).
When using Zephyr with nRF devices, you have one of two options: 1) Softdevice Controller, and 2) Zephyr BLE controller. Option (1) will be described in the section below. Option (2) is a full open source BLE controller which includes both the upper and lower implementation to make it possible to support multiple HW platforms. In other words, one of the main advantages of using this option is that you can switch from an nordic device to another BLE device with minimal changes to your application. You can find more about this here.
nRF Connect SDK based on Zephyr and using Nordic's SoftDevice
Finally, the nRF Connect SDK is a software development kit based on the open-source Zephyr RTOS (described above), but with some additions from Nordic. These additions include more documentation, libraries (e.g. Firmware Over the Air Upgrade - FOTA, and CryptoCell libraries), and generally more support from Nordic. This SDK also includes Nordic's own softdevice, which is tried and tested and qualified via Nordic. You can find more about nordic's nRF Connect SDK here.
To conclude, if I had to give a final recommendation, I would say go for nRF Connect SDK (especially if you are sure that you will use nRF for the lifetime of your product) - as this way you'll end up getting all of the advantages of using the Zephyr RTOS plus the advantages of having Nordic's reliable software and libraries. On the other hand if your goal is to have your application fully open sourced or if you think you might migrate to another HW platform in the future, "pure" Zephyr RTOS
is the better option. The old Nordic SDK + softdevice isn't a consideration given that it is now outdated and support for it has effectively stopped.
Some other useful links:-
nRF Connect SDK vs (vanilla) Zephyr
nRF Connect SDK (Zephyr) vs standalone nRF5 SDK
Zephyr tutorial: BLE development
nRF Connect SDK BLE tutorial part 1
BLE with Zephyr on an NRF52
Related
I made a little heart rate monitor app with Unity, but trying to ship it to Windows, the bluetooth part isn't cross platform.
Are there existing cross platform (mac/windows, linux too would be nice but not a dealbreaker) bluetooth solutions?
Unfortunately there isn't a "pure" cross-platform solution where you can write one application that works across multiple platforms. This is because the underlying stack for different OSes/platforms is different because the hardware is different for them. The closest thing to a cross-platform solution might be Xamarin as theoretically you can write an application that works for Android/iOS/Windows. Have a look at the links below:-
Developing Cross-platform BLE Apps
ble.net: cross platform BLE library
BLE on Xamarin Cross-platform
The smart BLE Guide: Add BLE to your app with Qt and Flego
Initially I built the Zephyr bluetooth application for native linux and run it in conjunction with Bluez on a BLE controller.I understand that in this, Linux OS and Bluez are used along with Zephyr host stack.
Now, I have flashed bluetooth application from Zephyr stack (samples/bluetooth/beacon)to NXP board successfully. Here there is no bluez used.
For this case, I have a few basic understanding questions:
1. Is the OS functionality also embedded in the bin file that is created after application is compiled. I mean I understand bluetooth stack is Zephyr, but which OS is used on board ?
2. Also, is there any functionality similar to hcitool in Bluez in Zephyr bluetooth stack?
3. Is there any functionality like btmon or hcidump?
To answer your questions:-
Zephyr is an OS itself - it is a Real-Time Operating System (RTOS)
that runs on top of many different types of hardware, just like how
Linux is an operating system that runs on top of many different
hardware. Zephyr is mainly written in C and under the hood talks
directly to the specific processor using its registers and the
vendor's stack. You can find a list of all supported boards
here.
Not identical to hcitool, but there is an hci layer example that
allows you to send raw hci commands. You can find more details on
this here and here. At the end of the day, you may not
need to use hci because it is a low layer and you can probably
achieve the same functionality through higher leve API. All Zephyr's
Bluetooth examples can be found here.
Again, nothing like btmon on Linux how you can see the raw HCI
packets for each command, but Zephyr does support different
Bluetooth logging options depending on the hardware used. More
information on this can be found here.
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
I am trying to identify which android phones support Bluetooth Low Energy and I am a bit confused on whether or not a device with BTv4.0+ is BLE compatible.
To be more precise, I am looking at the device Samsung Galaxy J5. According to http://www.gsmarena.com/samsung_galaxy_j5-7184.php, the bluetooth version is 4.1 but it doesn't mention anything about BLE.
According to the bluetooth specification:
"Bluetooth Low Energy (LE) (also called Bluetooth Smart or Version 4.0+ of the Bluetooth specification) is the power- and application-friendly version of Bluetooth that was built for the Internet of Things (IoT).". According to this I would presume that 4.0+ is BLE.
However if you see the specs of Samsung Galaxy S6 (http://www.gsmarena.com/samsung_galaxy_s6-6849.php) it mentions that it supports both BTv4.1 and BLE. It therefore distinguishes the two BT specifications.
Any information would be very helpful
Edit
Additional reference information for interested parties:
from bluetooth.org: Two flavors of Bluetooth The two most prevalent implementations of the specification are Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR), which was adopted as version 2.0/2.1, and Bluetooth with low energy (LE), which was adopted as version 4.0/4.1/4.2. Each implementation has different use cases and each implementation uses a different chipset to meet essential hardware requirements. Dual-mode chipsets are also available for applications that include both use cases. - See more at: https://www.bluetooth.com/specifications/bluetooth-core-specification#sthash.7X7IrtWy.dpuf
Instead of relying on gsmarena with unreliable information, you can refer to Bluetooth SIG's official information.
Based on this Bluetooth SIG's announcement and this one, BLE is a core specification of Bluetooth 4.0. Bluetooth 4.1 and 4.2 also adopt this core specification.
However, all this still depends on whether the manufacturers implement the firmware. To keep track of all this, Bluetooth SIG maintains a list of devices currently supporting any profile (for example GATT).
This crossed my mind myself as I saw it as a pointless advancement until I saw the low energy bLE (bluetooth low energy) side of it. In my pastime I tinker with various electronics and with various BLE 4.x modules and their pro's and cons are HUGE.
All in all, BLE is better as Bluetooth pretty much is battery drain on the most robust of phones.
I found a nice little writeup (pretty simple yet comprehensive) here: http://www.argenox.com/bluetooth-low-energy-ble-v4-0-development/library/a-guide-to-selecting-a-bluetooth-chipset/
Do cut my answer short, as the bag you linked shows it as being "NFC" compatible, then yet, it's BLE 4.x. (That's Near Field Communication i.e. similar to your your contactless bank card). The v4.1, A2DP which you mention is how one "audio device talks to another" via bluetooth. (dvanced Audio Distribution Profile).
If you're really bored, there's a long list of other profiles (other than A2D):
https://en.wikipedia.org/wiki/List_of_Bluetooth_profiles
Hope this helps!
Happy bluetoothing!
I am going to have a project that can get data from devices that support Health Device Profile(HDP) in Windows.
I find Bluez but it is only available in Linux. Is there any alternative in Windows? Thank You
There are multiple suppliers of Bluetooth stack for desktop Windows. The only one that I know supports HDP directly is Toshiba (though I've no experience with it). So, instead once can add the HDP support outside of the stack software. However, HDP[1] uses the L2CAP protocol which is lower level that RFCOMM protocol that most apps use, and unfortunately Microsoft's Bluetooth stack does not provide a user-level L2CAP API. I started work on a driver to allow user-mode access to the kernel-level API (provided by MSFT in Vista and later) but never finished it. For the other main stacks BlueSoleil doesn't provide a L2CAP API, but Widcomm does.
[1] http://www.alanjmcf.me.uk/comms/bluetooth/Bluetooth%20Profiles%20and%2032feet.NET.html#_Toc266869895