Lots of questions.. L2CAP/GATT/GAP, etc

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi, 

  • According to Bluetooth SIG, the 4.1 spec for BLE supports L2CAP programming - Vendors can create profile over L2CAP. (In 4.0 spec, the custom profile was only possible above GATT). Since 20736/37 are designed for 4.1 spec, do they support custom profiles on L2CAP? And if they do is there any example on the SDK 2.2?

  • Can the chip operate without GAP? Or in other words, can we avoid using GAP and GATT?

  • BLE spec lists that the device can have 3 MAC address - public, random and hard. Which ones are supported on the stack. Does it specifically support random MAC address?

  • If a device is advertising, can we only discover the device on GATT layer or is it discoverable on the L2CAP layer?

  • L2CAP supports 23 bytes according to 4.1 spec. How many packets can a device transmit continuously before maxing out?

  • Does Broadcom have a technical document which says what all does it provide from the 4.1 ble specs on their stack?

  • According to the example the interval between two advertisements can be a maximum of 40.96(UINT16). Is this right?

  • Does Broadcom support lazy scan? Any example or documentation is available if any?

  • Does does one find the latency for when a device transmits an advertisement packet and then the scan response data packet? Can we control when we send Scan response?

  • Is controller manager in the ble stack api the way we can control GAP, which is responsible for scanning or this the link management layer?

  • When we use GATT, we can use the cache. If we use any other layer can we use the cache as well(ex. L2CAP)?

  • On GATT level, L2CAP size is 23 bytes, some devices can support more than it. The client or the server may support more than 23 bytes. For this to work the devices need to communicate to check if the other device can support this? Is there a way to do this check?
0 Likes
1 Solution
VictorZ_46
Employee
Employee
5 comments on blog 25 sign-ins 250 likes received

Currently there is no support for L2CAP connection oriented channels over BLE.  It will be added a future version of the SDK.

Public and static random addresses are supported.  If you program the chip with address FFFFFFFFFFFF the stack will generate a random address and will save it in the NVRAM, so the same address will be used forever after.

If you start scanning, you will see advertisements from other devices.  See hci_client for an example how to do it.

By default there are 14 tx buffers.  See speed_test for example.

hello_sensor uses .low_undirect_adv_interval = 1024 slots which is 640 msec.  According to the spec the range is 20 ms to 10.24 sec.

I am not sure what you mean by lazy scan, but all scan parameters are configured in the blecen_cen_cfg structure.  See hello_client for example.  Similar to advertisements when application starts high duty scan (HIGH_SCAN), the stack will perform listen for high_scan_window every high_scan_interval and stay in that mode for high_scan_duration seconds.  After that it will switch to low duty cycle mode for low_scan_duration.  It is up to your application to specify how lazy it is.

No scan response is sent by the chip automatically according to the spec.

Application typically configures the scan/advertisements and chip executes according to the configuration.  You can register to be called few milliseconds before the advertisement event to modify the data if needed, but this is it.

I do not know what cache you are talking about.

There is MTU exchange between connected devices at the time connection is established.  2073X typically supports default MTU of 23 bytes.  There is a way around that though if it is required by your application, but implementation is a bit challenging.  I suggest you develop your app with default MTU and if you hit performance barrier talk to us again.

View solution in original post

1 Reply
VictorZ_46
Employee
Employee
5 comments on blog 25 sign-ins 250 likes received

Currently there is no support for L2CAP connection oriented channels over BLE.  It will be added a future version of the SDK.

Public and static random addresses are supported.  If you program the chip with address FFFFFFFFFFFF the stack will generate a random address and will save it in the NVRAM, so the same address will be used forever after.

If you start scanning, you will see advertisements from other devices.  See hci_client for an example how to do it.

By default there are 14 tx buffers.  See speed_test for example.

hello_sensor uses .low_undirect_adv_interval = 1024 slots which is 640 msec.  According to the spec the range is 20 ms to 10.24 sec.

I am not sure what you mean by lazy scan, but all scan parameters are configured in the blecen_cen_cfg structure.  See hello_client for example.  Similar to advertisements when application starts high duty scan (HIGH_SCAN), the stack will perform listen for high_scan_window every high_scan_interval and stay in that mode for high_scan_duration seconds.  After that it will switch to low duty cycle mode for low_scan_duration.  It is up to your application to specify how lazy it is.

No scan response is sent by the chip automatically according to the spec.

Application typically configures the scan/advertisements and chip executes according to the configuration.  You can register to be called few milliseconds before the advertisement event to modify the data if needed, but this is it.

I do not know what cache you are talking about.

There is MTU exchange between connected devices at the time connection is established.  2073X typically supports default MTU of 23 bytes.  There is a way around that though if it is required by your application, but implementation is a bit challenging.  I suggest you develop your app with default MTU and if you hit performance barrier talk to us again.