I want to clear of my basics before I Jump into more complicated matter of bluetooth. I have following basic question.
If there is two bluetooth devices(A phone and a bluetooth display). Is it that bluetooth connection is initiated only by the phone.
Suppose there would be lot of bluetooth communication happening from a phone to bluetooth display.Both devices can send messages to any other devices at any time. What is usual design approach of communication. Is it that the phone creates a Socket Connection to the bluetooth display through RFCOMM first time by sending a connect request to the Bluetooth device and this connection is maintained all the time or for every message the Socket connection is made and then socket is closed, after that again reopened and closed for next message.
If the connection is opened till the devices are in nearby range what are the consequences.
What is normal way of communication in case of phone and headset.
Can I get any reference so that i can get some knowledge about that.
1) In general, bluetooth connections can be initiated by either device. For example, with a phone and computer, you could start a connection from either side. With a phone and a display or headset, there may be no input interface on one device, so you would initiate connections from the phone. Devices can also auto-negotiate role switches such that they swap master/slave roles.
2) If you have continuous data to exchange, or require low latency, the connection would typically be left up. If you only have rare messages to exchange, tearing down the connection would save power because the devices are maintaining the connection synchronization by exchanging null packets.
3) You can't maintain a connection with devices out of range. If they can't communicate for some timeout period (on the order of seconds) then they lose sync and kill the connection.
4) Note that phone/headset are not using RFCOMM connections, rather the HSP (headset profile). Connections for isochronous voice data are inherently different than a sporadic data connection like RFCOMM.
5) A good way to see how "real" devices are communicating is to use tools like hcidump, as part of the linux blueZ stack. This lets you fully sniff the protocol messages that happen as you connect devices.
Related
I'm trying to connect to a BTLE device from Linux from C++ with BlueZ.
Connecting to most devices works fine, but there is a special device which times out with 90% probability. From a standard Android smartphone the connection to this particular device works as intended.
For #Emil's advice in my other question (thanks!) I've setup a Link Layer sniffer tool for further investigation.
During the sniff period I tried connecting to the device(Destination) from both device(Good) and device(Bad).
Device(Good) is working perfectly - it connected
Device(Bad) is not working - timed out
Now I have a Link Layer data of both device connection trials and there is one significant difference between their trials:
Device(Good)'s LL Data for its CONNECT_REQ uses 500 for Timeout value (which is 625ms) while Device(Bad)'s LL Data in CONNECT_REQ uses 42 (which is 52.5ms).
I think Device(Destination)'s response is normally (mostly) arriving between those two, ie after 52.5ms and below 625ms, but sometimes it arrives in less than 52.5ms, and then also BlueZ can connect to it finally.
Is there any possibility to change this Timeout property for CONNECT_REQ in BlueZ? Maybe with setsockopt by any chance?
Or this is something hardcoded into kernel, even for bluetooth adapters attached to USB?
We are developing small internet connected device that connects via wifi and does some work. It is controlled via mobile app.
For configuration purposes we use wi-fi module that can work in both STA + AP modes simultaneously via two interfaces wlan0 and wlan1. One of the interfaces works in Master mode. Phone connects to the device via wlan1 and sends command for the device to connect to another network and waits for result. Device in turn connects to another wi-fi network using wlan0 and notifies the phone if connection was successful or not.
But there is one issue. Both interfaces (wlan0 and wlan1) must work on the same channel as we have single hardware module. This causes channel of wlan1 to change in order to match of channel for wlan0.
Here comes the problem. When channel changes phone looses connection with the device. Is there a way to change wi-fi channel but keep connection between the device and mobile phone?
Our wi-fi module is rtl8723bu.
Linux 3.4.103.
Wifi daemons: hostapd v0.8.x_rtw_r7475.20130812_beta, wpa_supplicant v2.3.
UPDATE
Here is more clearly description what is going on on device.
Let's assume that the phone already connected to Device wlan1 interface with essid DeviceAp which is on channel 1. We have a Router with essid RouterAp which is on channel 6. Device interface wlan0 is not configured and not running.
(Step1 on image below).
Then the phone sends a request to the device to connect to RouterAp.
(Step2 on image below).
When wlan0 starts connecting to RouterAp it changes working channel. Because WiFi module can work only on one channel. The channel of wlan1 also changes (maybe in hard way). Therefore Phone lost DeviceAp and starts roaming.
(Step3 on image below).
SO the update question is:
Is there a way to tell the Phone (or other device) about network change? Or perhaps increase the likelihood that the phone is connected back to DeviceAP.
This behavior is very similar to the process of setting up Google Chromecast.
Chromecast also has two wireless interfaces and change the channel, but the Phone does not lose connection with it.
Image:
http://postimg.org/image/soh78vd17/
It`s possible to establish two connections( or more) between Pc and other device? When I try to do that I have got exception: 10048 -> ex.Message = "A connect request was made on an already connected socket xxxxxxxxxxxx:0000110100001000800000805f9b34fb". If not, there is some workaround? I used 32feet libary to wrote application.
i just connected 4 devices (spp) simultanously and transfering data periodically.
so it is definitely possible.
if one device is disconnected the other connection can't get data anymore, but i guess this is just a bug in my code.
it would be very interesting if anyone else has tried this.
I guess its not possible. There can exist one connection between a master and slave. A master can be simultaneously connected to as much as 7 active slaves.
And most probably the other device that you are using might support only one connection.
In your case it is possible to connect up to 7 device to your pc.
This an RFCOMM limitation, not a limitation of the lower levels of the Bluetooth stack. See a workaround described in the 32feet.NET documentation https://32feet.codeplex.com/wikipage?title=General%20Bluetooth%20Data%20Connections
Notes
[1] The one RFCOMM connection is a protocol limitation. TCP/IP has port numbers on source and destination ends and thus can support multiple connections, RFCOMM has only the remote channel number so only can support one connection.
If you need multiple connection and are in control of the 'server' device then have the service listen on two (or more) RFCOMM channels so the client can connect to different channel numbers.
The usual way to access L2CAP is to create an L2CAP socket and simply call connect() on it to connect to the bluetooth device you want to access. This usually works completely fine. However, I'm trying to do this on an ARM device with Linux kernel 3.0 and there appears to be a nasty bug where you can't have multiple L2CAP connections without all of the data coming down which ever channel was created last. (ie if I connect to 2 bluetooth sensors with 2 l2cap sockets, all the notifications for both devices come through the socket open last and nothing comes on the socket open first.) However, if I set the filters right on the HCI socket I can see that the ACL data is coming through with the proper connection handles so I could get the data properly over there.
So... I'd like to change my code to utilize just the HCI socket.
My problem is, I'm not sure how (or even if it's possible). There's a "create logical link command" in HCI that seems like it would create an L2CAP connection, but the arguments make no sense to me. After I make an HCI connection over LE I get back a "connection complete event" that gives me a 2 octet "Connection_Handle". The "create logical link command" takes a 1 octet "Physical_Link_Handle" though.
The "create logic link command" is for AMP controllers and has nothing to do with L2CAP. With LE you automatically have a "connection" through the fixed channels and can simply send ATT commands as ACL packets on CID 4. The ACL packets make use of the connection handle returned fro the HCI LE connection event.
(answer courtesy someone on the #bluez IRC channel; I don't recall who)
In BLE, whenever you establish a connection, the L2CAP is ready to be used.
You don't need to connect or anything else. Once you receive the LE Connection Complete Event, you are ready to go and you may start communicating through L2CAP.
The other commands and data you mention are not LE, they are only for BR/EDR.
In general, two communicate between bluetooth devices, first we perform a bluetooth pairing between two devices and then starts further communication between them.
My problem scenario is simply to transfer a hello packet from one bluetooth device to another bluetooth device.
For this i am planning to use sockets programming technique i.e. RFCOMM sockets.
I got some help about this from http://people.csail.mit.edu/albert/bluez-intro/x502.html
So, my query is do we require bluetooth pairing between two devices before initiating communication with RFCOMM socket connection.
Or does 48 bits device address is only necessary to transfer some data packet from one bluetooth device to other and bluetooth pairing could be avoided.
No, it is not.
Bluetooth device can be in one of the four modes:
Broadcaster
Observer
Peripheral
Central
In broadcaster mode device can only send advertisement messages. This includes name and HwID.
In Observer mode device can only receive advertisement messages.
Peripheral = Broadcaster + can take in connect requests
Central = Observer + can send out connect requests.
If you have an application which does not want to connect use first two modes above.
Please let me know if this addresses your question.