I'm trying to do something with this HCI module I got, which uses a CSR Bluecore6 chip. I'm very new to this, so I'd just want to make it perform inquiry scan only (i.e. make it discoverable). To do that, do I need to implement a bluetooth stack or do CSR chips already support that? The datasheet of the module isn't very helpful. Since it's a HCI module only, do I need to implement it inside an external MCU or within the chip?
Any other advise on what to expect will be much appreciated!
Thanks
If it is an HCI module then it will only support the standard bluetooth HCI interface and you must provide a stack on your MCU. CSR also provide a stack implementation (http://www.csr.com/products/19/csr-synergy) for most embedded devices.
you don't need a full stack just to perform inquiry / page scan, you can try to connect the module via its HCI interface to a PC or external MCU and send HCI commands to setup the scans, there are few PC tools lie the hciconfig tool on Linux
Related
I seem to understand it is possible to customize HCI communication with custom commands (OGF==0x3f), but I wasn't able to find specific info about how to register such commands with BlueZ stack and, in general, specifics on how to handle them.
Can someone point me in the right direction?
A bit of background (ask if more is needed):
I have a fairly standard Yocto-based Linux installation I can control.
BLE is provided by a Nordic nRF52832.
Communication is via standard UART (btattach -S 460800 -B /dev/ttyHS0).
Since nRF is doing also "other stuff" and should report to main SoC some non-bluetooth data over the same channel (the only channel I have between the two processors) I need to multiplex.
It seemed adding custom frames is the simplest way, but I need details on how to proceed.
I need information mainly on the host/Linux side as I have nRF side "more under control".
I would like to have a discussion about modifying Bluetooth stack and thinking about what are the important factors that should be considered in general. I have proposed some solutions related to the IP for Bluetooth and now I am in the step to decide which one is more suitable to implement. My different solutions could be implemented on top of GATT or as an adaptation layer on top of L2CAP or on top of Link Layer. My questions are
is there any difference in the energy consumption if the solution is implemented on the top of the Link layer or on top of, for example, L2CAP?
is the Bluetooth stack implementation open source? is the firmware of LL open source?
what else should I consider for the selection of the layer positions?
Is operating system important? why?
The Bluetooth HCI Commands and Events are interoperable; Only the vendor defined(proprietary) HCI commands and Events are not. Top of the HCI layer is called Host. Bottom of the HCI is called Controller.
For Example: BlueZ (Initated by Qualcomm and maintained by Intel now) stack is usually present on Linux. But the Bluetooth Controller might be from Broadcom. They are interoperable until the HCI commands follow the Bluetooth Specifications.
Both L2CAP and GATT are layers above HCI. The Power Consumption always is dependent on Application. Radio Modem and the CPU Core are the most power consuming part of the Bluetooth Communication. The CPU core needs to put the Radio IP to sleep whenever it is not needed. There needs to be an Idle Thread which monitors the application activity and put the Radio to sleep and wakeup.
Most of the Bluetooth Protocol are Finite State Machines and can be implemented using State (Event-driven) design pattern.
Do not give the memory management overhead to applications; it needs to be taken care by the Bluetooth stack.
There are couple of Open source BLE stacks as mentioned by #Youssif here.
I dont understand your 4th Question though.
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 am new to BLE/Bluetooth programmming. As known,BLE/Bluetooth is an entire module.Recently I found that, the NimBLE provides the Host Stack or Controller part of Bluetooth.https://github.com/apache/mynewt-core . Here they mention that it supports the mix and match of any host stack with any controller.
So, is it that the HCI layer(through which the host stack interacts) and the Controller (lower bluetooth layer) implementation of all the modules same or is it vendor specific?
If I choosse a host stack from the NimBLE, does the implementation of HCI allow me to operate with any vendor's controller or is that the HCI layer should be implemented with vendor specifications and dependent on the controller.
I assumed that the controller part of the Bluetooth /BLE module has the basic RF and communication section,which will be the same for all modules for its interoperability. I am sorry if the question is trivial.
Any host stack with a hci interface should work with any hci controller, as long as they both have support for the same transport method (UART, USB etc.)
Sometimes, in particular for usb you also need a specific host driver that opens up the transport interface for the particular device. For UART some vendors requires some vendor specific setup packets being sent over UART that configures baud rate etc before hci can start.
Also the host and controller should have a common feature set. For example you can't do much with a host that only supports Bluetooth classic and a controller that only supports BLE.
Some hci controllers implement custom vendor commands to offer extra features over the standard commands, such as for example set custom public Bluetooth device address. A host must also support these commands in order to make use of them.
I have been asked to figure out how to achieve bluetooth communication through an off-the-shelf dongle (in this case a dongle utilizing the Broadcom BCM2045 chip) using the FTDI Vinculum 2 (VNC2) USB controller. I have custom firmware written for the VNC2 to communicate with a generic USB device with the VNC2 acting as the host, and I can successfully read the VID and PID from the dongle as well as the USB device class, subclass, and protocol. I can also send data to the dongle using the bulk data endpoint and I believe the device is receiving though I have no way to tell at the moment.
So I believe I can communicate with the dongle, the problem is I have no idea WHAT to communicate to it in order to set it up in discoverable mode or to pair it with another discoverable device, nor how to actually transmit data through the wireless link once it is paired. I don't even know if there exists a standard communication protocol for this type of thing or if every device will be different. I have a vague understanding of the bluetooth protocol stack and it is my understanding that I won't be required to fully understand that as it should be implemented in the dongle on one end and in the android smartphone that we hope to connect to on the other end. Like I said, I can currently send data to the bulk endpoint, is it true that this endpoint is only for data transfer over the wireless link and I will need to connect to a different endpoint in order to send setup/configuration messages to the dongle?
In short, I need to know what data to send over the USB bus to control any generic bluetooth dongle if possible or at least one specific bluetooth dongle. I have a USB port sniffer but the complexity of the output while using the dongle to communicate is staggering and I doubt I'll ever figure it out.
Thank you in advance.
Bluetooth dongles communicate with host software stack using HCI (host control interface), which is defined in the Bluetooth spec. For reference, you can look at source code for the open source BlueZ stack (standard linux stack). You could run BlueZ on linux talking to your USB dongle, and use hcidump to capture actual packets going across HCI. You can also check out hcitool and hciconfig for performing specific actions.