I try to understand the BLE pairing procedure via checking the HCI log and reading the Core profile .
now I know something as blow :
1.SMP use the channel 0x0006 in L2CAP.
2.L2CAP has the connectionless\Connection-oriented channel , 0x0006 belongs to the Connection-oriented channel.
3.L2CAP create connection should have the "L2CAP Connection Request/respon".
what I confused is there is no "L2CAP Connection Request/respon" in my HCI logs(more than 10 files).
Is this channel create via the BLE STACK in Bluetooth init step ? so When the SMP wanna use this 0x0006 Channel ,it is already exist ,no need to create .Am i rigtht?
I try to reboot the smart phone \the SDK board ,try to get the HCI log about init step ,but nothing more .
The SMP channel 0x0006 is a "fixed channel".
Per Bluetooth Core specification v5.3, Vol 3 (Host), Part A (L2CAP):
Fixed channels are available as soon as the ACL-U or LE-U logical link is set up. All initialization that is normally performed when a channel is created shall be performed for each of the supported fixed channels when the ACL-U or LE-U logical link is set up. Fixed channels shall only run over ACL-U, APB-U, or LE-U logical links.
So, there is no need to (and not allowed to) send request/response packets that create the channel, since it's already established when the BLE connection is created. The SMP channel 0x0006 uses the "basic mode", so you are therefore not even allowed to use L2CAP_LE_CREDIT_BASED_CONNECTION_REQ for that channel, since that request can only be used for channels in LE Credit Based Flow Control mode. And L2CAP_CONNECTION_REQ can only be used for Bluetooth Classic.
Related
I'm using BTool, together with a TI Launchpad and the nRF Connect mobile app on my Samsung S21. I am curious, what type of services nRF Connect can be used, that send notifications to my TI Launchpad whenever their value is changed. Not periodically. Only after their value is changed.
I tried using a Battery Level service, but I'm not sure on how to "subscribe" to that service (how to enable notifications) from BTool.
Any advice?
According to this BTool User Guide I found the process of enabling notifications is as follows:
In order to enable notifications, the client device must write a value of 0x0001 to the client characteristic configuration descriptor (CCCD) for the particular characteristic. The handle for the CCCD immediately follows the characteristic value’s handle. Therefore, a value of 0x0001 must be written to the “handle + 1”.
The Battery Service you created has the UUID 0x180F and you have to get the handle for this characteristic. One way is described in the part about reading a characteristic by UUID.
To do this, you will first need to click the “Read/Write” tab in BTool. Select the option “Read Using Characteristic UUID” under the”sub-procedure” option in the “Characteristic Read” section at the top of the screen. Enter the UUID (note that the LSB is entered first, and the MSB is entered last) in the “Characteristic UUID” box, and click the “Read” button.
You can now access the CCCD using "handle + 1" as described earlier. To enable the notifications just write 0x0001 to that handle.
I just got a Bluetooth LE/Smart bathroom scales (Model Sanitas SBF 70). I can read data from it using the following command:
gatttool --device=(btaddr) -I
connect
Then when I stand on it, I get multiple notification messages like this:
"Notification handle = 0x002e value: e7 58 01 05 e9"
where the last two bytes are is the mass in 50g increments.
I'd like to integrate this into a few application using a TCP or UDP socket service that broadcasts these messages to any listening clients.
But after some research I have no idea what's the best way to stay connected all the time (the connection times out after a few minutes). Or alternatively to be able to re-establish a connection when the scales is used (I notice lots of activity from 'hcitool lescan' whenever someone steps on the scales).
I don't care what language / library is used. If I can push this to a TCP/UDP socket it will be trivial for other applications to consume the information.
The answer is straightforward: You don't.
Your scale is most likely battery powered. Therefore the Bluetooth communications will only be enabled for a short period of time after having measured your weight. Your application just needs to try connecting to the scale over and over (catch any "unable to connect timeouts") until you step on it. And when connected get the data from it before BLE is shut down again. In pseudo code:
while true:
while not_connected:
try to connect
receive notifications
disconnect
gatttool wrapped by the python module pygatt is perfectly usable to solve this chalenge.
In my case scale data (preceding 30 weights) is transferred after enabling indications of 3 different characteristics.
Is it possible to send some notification messages to the nearby Bluetooth devices without pairing.I have found some protocol for these - OBEX Oject Push. But am not clear whether is is feasible without pairing request .Any demo apps for reference?
Yes and no.
If you are actually talking about connecting but not pairing, then, yes.
If you are talking about no connection at all, then no.
When creating a Bluetooth connection between two or more devices the following steps are taken.
Inquiry – If two Bluetooth devices know absolutely nothing about each other, one must run an inquiry to try to discover the other. One device sends out the inquiry request, and any device listening for such a request will respond with its address, and possibly its name and other information. The closest located device is not necessarily the fastest to respond and any device that hears the call will try to respond.
Paging – Paging is the process of forming a connection between two Bluetooth devices. Before this connection can be initiated, each device needs to know the address of the other (found in the inquiry process).
Connection – After a device has completed the paging process, it enters the connection state. While connected, a device can either be actively participating or it can be put into a low power sleep mode.
• Active Mode – This is the regular connected mode, where the device is actively transmitting or receiving data.
• Sniff Mode – This is a power-saving mode, where the device is less active. It’ll sleep and only listen for transmissions at a set interval (e.g. every 100ms).
• Hold Mode – Hold mode is a temporary, power-saving mode where a device sleeps for a defined period and then returns back to active mode when that interval has passed. The master can command a slave device to hold.
• Park Mode – Park is the deepest of sleep modes. A master can command a slave to “park”, and that slave will become inactive until the master tells it to wake back up.
Two devices can be bonded together through a one-time process called pairing. When two devices are paired, they store each other’s addresses, names and profiles in memory, allowing them to automatically establish a connection as soon as they are in range of each other.
It is not possible to send OPP (or other) communication between two devices before connecting.
It is possible to send communication between two devices after connection but before pairing.
I am developing a USB driver in linux kernel space Where my usb interface as two bulk endpoints (IN and OUT).I am using ONE URB to send and receive data. Can i use the same usb_alloc_urb() for sending and receive data.
I am using the below steps to send and receive data using urb
usb_alloc_urb() ---> created only one's
usb_fill_bulk_urb()---> using usb_sndbulkpipe
usb_sumbit_urb() ----> sumbited successfully
usb_fill_bulk_urb()---> using usb_rcvbulkpipe
usb_submit_urb() -----> In this point i am getting ERROR -16.
Is the above followed steps are correct/possible ?
Thank you
You cannot use the same URB for two transfers at the same time.
To be able to reuse a URB, you must wait until it has been completed (successfully or with an error).
To use full-duplex transfers, you need two URBs.
To get high transfer rates, you must pipeline URBs, i.e., you need even more.
Isochronous endpoints are one way only. But single isochronous IN transmission is described in various sources (eg. here http://www.beyondlogic.org/usbnutshell/usb4.shtml#Isochronous) as one IN token packet (from host to a device) followed by one DATA packet (from a device to the host). So I see communication in both directions here. Is the token packet from the host received by the same IN isochronous endpoint which then sends the data?
What is synchronization for? HERE : http://wiki.osdev.org/Universal_Serial_Bus#Supporting_Isochronous_Transfers we read : "Due to application-specific sampling rates, different hardware clock designs, scheduling policies in the operating system, or even physical anomalies, the host and isochronous device could fall out of synchronization." But how? I understand the sequence of events like this : device fills its outgoing buffer with data, and waits for the token (some interrupt probably). Host sends the token packet, and waits for the data packet, which (I think) should arrive instantly. Sequence is repeated every frame (#F.S.) and everybody is happy. Isn't the token packet synchronizing the reply from the device?
Here http://wiki.osdev.org/Universal_Serial_Bus#SYNC_Field we read : "All USB packets start with a SYNC field which serves, unsurprisingly, as a synchronization mechanism between the receiver and the sender." So once again I ask : why to synchronize isochronous transfers in another manner than this?
All USB transactions are always initiated by the Host. E.g. for an isochronous IN transaction the Host will ask the device for the next piece of data first. This is of course a data flow to the device, but on a lower protocol level (Token Packets). So a kind of control data is send TO the device, but the meaningful data (Data Packts) is only sent FROM the device (IN direction). When you develop software for a device you can often abstract away the Bus Protocol details, because they are handled in hardware (USB device peripheral). The low level messages do not enter an endpoint. Endpoints are on a higher layer.
Consider a USB microphone: It records audio data with a very specific sample rate which is based on the local oscillator of the device. It's only a matter of time that the clock of the Host and the microphone will drift. After a few minutes a gap in the data would appear (or a buffer overflow will occur) because the microphone is recording data at a slightly different speed then the USB is expecting it (from the device's configuration descriptor). So they need some kind of synchronization.
The SYNC field is on the lowest Layer. It is for bit synchronization only and should not be confused with the synchronization for isochronous endpoints (2.)
You might want to take a look at the official USB 2.0 Specification (usb_20.pdf) instead of all the third party wikis which kind of confused you.