Vendor Specific Macros

[moudi599]

Hi @cvinayak , I would like to inquire about the macros defined in the lll_vendor.h file. Specifically, how can I calculate the values for these macros if I need to adapt the code to run on a vendor-specific chip?
For example:

• EVENT_OVERHEAD_XTAL_US
• EVENT_OVERHEAD_START_US
• EVENT_OVERHEAD_END_US
• EVENT_RX_TX_TURNAROUND(phy)

[cvinayak]

These are not calculated but vendor defined constants. These defines and their use is very specific to vendor implementation of their Lower Link Layer.

1. Time required for crystal oscillator to settle, again it is very vendor specific design, your SoC may not see or have a dependency on starting a crystal osciallator.
2. CPU overhead time required to start radio transmissions
3. CPU overhead time after stopping/close of radio transmissions
4. Minimum time required to switch from Tx to Rx or Rx to Tx.

[moudi599]

@cvinayak, i have the function that is responsible for switching the channels is taking 4.3ms, in what macro do i add this value?

[cvinayak]

Bluetooth Low Energy requires a minimum as low as 150 us when switching channels, PHY and/or when transmitting or receiving consecutively on same channel/PHY. There is no configurable macro, as these minimum requirements are Bluetooth specification defined.

[moudi599]

@cvinayak , Im testing on fpga, and the time required for the adi for setting the channel at a certain frequency takes 4.3ms "void lll_chan_set(uint32_t chan)", and this is problematic. Is there a workaround we can do in order to fix this issue?
Do we update the vendor specific macros in lll_vendor.h file or is there another solution? What do you suggest?

[cvinayak]

4.3 ms would be acceptable for only supporting Legacy Advertising/Scanning/ACL connections, i.e. Bluetooth Low Energy v4.x; where a radio event only uses a single channel. EVENT_OVERHEAD_START_US is the define that covers the CPU usage overhead for preparation of radio event.

[moudi599]

@cvinayak what is the maximum time for this function that the standard expects?
Why 4.3ms is not acceptable in case of extended, and it is acceptable in legacy ?
What are the limitations, and are these related to scanner only or scanner and advertiser?