My question is : what is the best method to drive a bluetooth module(BTM-331 as an example) over UART or SPI? I am asking this in the following context.
I have some analog sensors connected to a uP. The uP sends this data over spi to another uP who has also a bluetooth module. Because I talk with the sensors via SPI is ok to talk with the Bluetooth module with spi or uart is better?
I am pretty sure that even if you want to use it with SPI, you can't. I've used other BTM modules and the SPI on them is used for programming the module. Communication with it is possible through UART and (most of the times) USB.
Looking at the BTM 331 (description here) and it does say that USB and UART are the interfaces used.
Other than that it is fairly simple to use, you send data to it and the data goes to whoever the module is connected to. That is the least you can do with it but it is more than enough for most people.
Related
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 developing a project using Arduino to send a message to Raspberry Pi using an APC220 Radio Communication Module.
The Raspberry Pi can't receive serial message by using USB connect to APC220. I want to know how to use APC220 in Raspberry Pi?
The APC220 has a TTL UART interface which you can connect directly to the RPi TTL UART pins on the GPIO header - you do not need the USB-Serial converter (though that should work too if it is a standard CDC/ACM device - though this suggests that there may be issues).
A note of caution however, the RPi GPIO pins use 3.3Volt logic, the APC220 datasheet is not clear on the TTL level used, but the specified supply range is 3.3 to 5.5 volts so it seems likely that it is 3.3V - best measure it to be certain. You can probably use the RPi GPIO headers's 3.3V supply pin to power the ACM220, then you will be sure to be safe. If the ACM220 level is too high, the quick-and-dirty solution is to use current limiting resistors in-line to protect the RPi (10KOhm should be enough, but don't hold me responsible; you should know what you are doing before proceeding).
The UART device on the Pi is /dev/ttyAMA0.
See here for details of serial I/O on the Pi.
22 Feb 2012 Update
The discussion here suggests that to make the TTL<->USB adapter work on Raspberry Pi, you need to disconnect the EN signal - the discussion links back to the manufacturer documentation, which gives that advice in the troubleshooting section. Since that makes the device appear as a USB serial, and you won't have to reconfigure the on-chip serial or build a connector that may be simpler.
A number of bluetooth Arduino shields (Bluefruit EZ-link, SparkFun Bluetooth Silver) support DTR/RTS and have special out pin to wire. How do they work? Does it require special drivers (linux f.e.)? Can any bluetooth receiver be used or modified to provide DTR/RTS? Since setting DTR/RTS is vendor-specific does it depend on transmitter side or receiver (bluetooth shield) only?
The only idea is that special USB drivers needed that send special AT commands to make BT receiver know actual DTR/RTS value.
The documentation of Bluetooth SPP (https://developer.bluetooth.org/TechnologyOverview/Documents/SPP_SPEC.pdf) states in section 4.1 RS232 Control Signals that "all devices are required to send information on all changes in RS232 control signals".
And since Bluefruit EZ-link is not using any special drivers on the side of the computer, it must be that the standard BT virtual serial port drivers that manage the ports created for the BT connection to Arduino handle the control signals properly and send them over to the BT shield connected to Arduino. Hence no work should be needed on the side of the computer, and it only depends on the receiver: whether it has the control signals accessible on any of the output pins and operates them as it should, or not (as usually is the case, unfortunately).
I am looking for connecting to ADAFRUIT RFID PN532 readers to one arduino,
I think its possible since I2C was for that, but how can i modify the code (Which is already in RFID ADAFRUIT LIBRARY) two access through the both readers at one instance ?
No, you can't connect two Adafruit PN532 shields on the same I2C bus. The problem is that you can't change the peripheral address of the PN532. Thus, both PN532 NFC chips would respond to the same address and you can't control which of the two shields you communicate with.
However, you may be able to separate the two boards
by using an I2C multiplexer that switches between the two boards, or
by using the SPI option of the PN532 shields. In SPI mode you have an additional chip-select PIN that you could wire to separate PINs of the Adruino. You could then address a specific PN532 shield using those chip-select lines. However, you would need to port the PN532 library to SPI communication.
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.