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.
Related
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.
This is my first question in Stackoverflow :)
I'm trying to make few modifications to the Ti Sensortag but I have few questions please:
1- is it possible to make the sensortags communicate with each-other without a gateway?
(lets Say I put Sensor1 in bedroom 1 and sensor 2 in bedroom 2 can I make them exchange readings without the need for a gateway?)
2- can I install a micro USB over the interface connector to be able to use a portable battery pack? (photo of the interface connector)
thanks
You'll get better more in depth responses on the TI support forums as Ifor has said.
However, I can tell you the answer to #1... Regular bluetooth allows for things like piconets, but Low Energy does not. With LE you have a client/server (master/slave) connection between two devices only. It may be possible to modify the firmware on the sensortags to allow them to make connections to other sensortags, but then they'd have to give up whatever connection they currently had to do so. The master devices can connect to multiple slave devices, but the slave device can only be connected to one master.
As the sensortags are currently designed, I think they only work as a slave (server) device.
Press releases say that the new 4.1 spec allows for a single BLE device to act in both roles--central and peripheral eliminating the need for a gateway. A 4.1 update is, in theory, possible with 4.0 radio hardware like the SensorTag has. I personally haven't seen an example of this however and SensorTag processing resources may be a limiting factor to a dual role.
The Battery Pack connector breaks out VDD_EXT and GND and the SensorTag hardware schematic is available. Analysis by a hardware design engineer should be able to determine the suitability of a USB source powering option.
http://processors.wiki.ti.com/index.php/SensorTag_User_Guide
How is bluetooth low energy implemented at a device driver level in linux?
Is there a new bluetooth stack code for every new bluetooth version ?
Bluez is the stack for Linux Bluetooth. New version of Bluetooth have resulted in changes in the code, but it's not a complete rewrite or anything drastic like that. Newer versions of Bluetooth are typically extensions of the existing protocol with the exception of Low Energy. Low Energy is completely supported at the kernel level in Linux, but there aren't a lot of convenience libraries for higher level interaction with LE.
Due to the incompleteness of Bluez with LE I've had to interact with the kernel code directly in order to implement functionality with LE. Also, I had to use older kernels that aren't supported by Bluez 5.x and had to use Bluez 4.x.
Already Tim and jhonnash have provided comprehensive information to your question. However, I would like to add one more information from Android Mobile point of view.
New version of Android uses Bluedroid as Bluetooth stack. This is quite different from Bluez.
Bluez has functionality distributed both in user space and kernel space. All the protocols like RFCOMM, HCI and L2CAP are implemented at kernel level and Profiles are implemented at User space. As Tim mentioned, to support Low energy, Bluez has to provide support at kernel level as well as at user space. This some times get difficult to track and understand. Any new changes may require modification in kernel as well as in user space code.
On the other hand, Bluedroid has some advantage over Bluez. Bluedroid has implemented its complete functionality at user space. Due to which any new functionality only needs to be added at user level code. No dependency on Kernel code.
Also, to answer your question of "Is there a new bluetooth stack code for every new bluetooth version ?" No complete rewrite is required for new version of Bluetooth as Bluetooth new versions are backward compatible, so only those portion of codes are added to the already existing stack which is new.
Regards
As your question is not completly clear that's why I also try to give all the possible protocols available to access bluetooth low enery stack for linux.
In UHID Driver "HoG (HID over GATT/Bluetooth-Low-Energy): GATT is a Bluetooth protocol implemented in user-space. When user-space opens an LE (low-energy) connection to a Bluetooth device, the device can advertise HID capabilities via GATT."
As GATT service is properly defined in this link.
There can be other protocols than GATT to access the Low-energy devices. HID Over GATT implementation is done in this manner.
I'm looking to implement the Bluetooth protocol over a physical Wi-Fi based transport, if that makes sense.
Basically my phone has Bluetooth, and my laptop has a Wi-Fi card (802.11a/b/g).
I know that Wi-Fi operates over the range 2.412 GHz - 2.472 GHz, and that Bluetooth operates over the range 2.402 GHz - 2.480 GHz.
I couldn't help but notice the overlap here. So my questions are:
What sort of low-level APIs would I need (preferably in C, on Windows) in order to send a signal out at certain frequencies on the Wi-Fi card?
Would I be able to implement a Bluetooth stack on top of this?
So basically, can I transmit Bluetooth using my Wi-Fi card as essentially a radio transmitter?
Thanks
Implementing the Bluetooth protocol over a physical Wi-Fi based transport does make sense!
Bluetooth high speed (v3.0) defines the possibility to use alternate MAC/PHY layers, known as AMP feature. The L2CAP and higher layer protocols from Bluetooth can be transmitted over a Wi-Fi MAC/PHY layer rather than a Bluetooth MAC/PHY layer with a resulting higher throughput. Some products are on the marked supporting this - look for 'Bluetooth High Speed', AMP or Bluetooth v3.0 support.
No, you can't do this. Bluetooth devices are typically wrapped up all in one chip. Plus, they use completely different modulation techniques. No low-level anything is going to allow you to transmit anything different, unless you are flashing the device. Even then, it may not get you much closer.
Bluetooth Modulation Information:
http://www.palowireless.com/infotooth/tutorial/radio.asp and http://classes.engr.oregonstate.edu/eecs/spring2003/ece44x/groups/g9/jon_gillen/white_paper_jon.pdf
About the only thing you can share between WiFi and Bluetooth devices is the antenna. (Assuming only one device is using it at a time... don't blast 32mW into the receiver of the other radio!) The radio itself is all wrapped up into the same chip. The same is generally true for WiFi.
Bluetooth and Wifi have different phy layer protocols and thats what is coded into their chips, hence you can't use one chip to transmit packets of the other protocol.
Moreover most of the chip vendors, do not expose any RF logic.
Technically yes but there are some things to consider such as the pre existing coding on the chip and if the chip can support Bluetooth coding as well as wifi coding, I mean if you have two separate wifi chips go ahead and try but be warned I tried and nearly killed my computer because of preexisting copyright protection coding on other parts of my pc that prevented any programs on the chip from starting until I reset the chip to factory defalts.
Does anyone know how a bluetooth device could pick up the discoverable devices' device IDs in range?
I am ideally looking for the simplest solution that involves the smallest implimentation of the bluetooth protocols.
A starting point would be good, I just wish to create a device that can store all the device ids of nearby bluetooth devices with minimal power consumption, preferably just using radio frequencies and not SDP and whatever else.
If you can't help me with this, please can you help me find good reading material for low level bluetooth (step by step) communication. The reading online is so high level that I cant work out what is actually sent, when.
Laalto nailed the answer from the Bluetooth spec/stack POV, but your question implies your looking for a stand-alone Bluetooth device - not just a laptop app scanning surrounding devices.
I can only speak for the BT chips that the company I work for manufactures (Cambridge Silicon Radio - CSR) but our chips can do that pretty much out of the box. Our chips have an on-board Virtual Machine sandbox that allows access to the firmware functions and Bluetooth stack of the chip. You can easily write a C code app to run in the virtual machine sandbox, on chip, that periodically scans for discoverable devices around, grab their ids and then download them when connected via USB or Serial, or maybe over BT when a device connects to the listener directly.
www.csr.com and www.csrsupport.com for chips, dev-kits, design references, etc.. etc...
You probably want a module with the extra HW (UARTs, USB etc...) as well as just the chip but you could implement this with something the size of a BlueTooth USB or probably smaller.
It would really help to know more about what your trying to achieve, why you want something that just scans the surrounding bluetooth devices and how big the device needs to be.
Sorry if this sounds like advertising. For balance: Broadcom make BT chips too!
The Bluetooth specs from http://www.bluetooth.org are a good starting place for low-level information. You need an account to access the specs, but you can create one for free.
Basically what you need to do is to go into Inquiry mode periodically and grab the response packets as they arrive. The more time you spend in Inquiry mode, the more likely you will discover devices in range: discoverable devices enter the Inquiry Scan mode only relatively rarely; it takes some time (10.24s at least with older Bluetooth versions) to scan all the possible frequencies in the Inquiry/Inquiry Scan frequency hopping schemes. And even then you can have suboptimal radio conditions.
For implementation I suggest you at least start with existing Bluetooth libraries such as BlueZ and do not attempt to create your own from scratch.