- 
                Notifications
    You must be signed in to change notification settings 
- Fork 8.2k
Add sending multiple CTE with periodic advertising chains #36585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add sending multiple CTE with periodic advertising chains #36585
Conversation
7c9e001    to
    b94bb38      
    Compare
  
            
          
                tests/bluetooth/df/connectionless_cte_chains/src/test_add_cte_to_chain.h
              
                Outdated
          
            Show resolved
            Hide resolved
        
      b94bb38    to
    a513436      
    Compare
  
    | @Thalley all comments were addressed. I've to add a commit to clean up  | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few minor comments, otherwise LGTM
        
          
                subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio_df.c
              
                Outdated
          
            Show resolved
            Hide resolved
        
      a513436    to
    2157b01      
    Compare
  
    | Added changes requested by @Thalley. | 
        
          
                subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio_internal.h
              
                Outdated
          
            Show resolved
            Hide resolved
        
      2157b01    to
    644f043      
    Compare
  
    | @Thalley Two comments were not addresses. The one with  | 
644f043    to
    015c9be      
    Compare
  
    015c9be    to
    4e86bb1      
    Compare
  
    | Rebased on laters main. 
 | 
| @cvinayak @andrzej-kaczmarek @Thalley could you take a look? | 
        
          
                subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio_internal.h
              
                Outdated
          
            Show resolved
            Hide resolved
        
              
          
                subsys/bluetooth/controller/ll_sw/nordic/hal/nrf5/radio/radio_internal.h
              
                Outdated
          
            Show resolved
            Hide resolved
        
      …hain Add possiblity to configure maximum number of PDUs with Constant Tone Extension in a single periodic advertising chain. Signed-off-by: Piotr Pryga <[email protected]>
Amount of memory allocated for advertising PDUs (including periodic advertising) depends on two factors: - maximum advertising data length - maximum number of CTE in a periodic advertising chain. Maximum advertising data length is divided by maximum size of a single fragment (number of payload bytes that single advertising PDU may hold) to get required number of fragments. Actual number of PDUs allocated for advertising is maximum of acutal number of advertising payload fragments and maximum number of CTEs. Signed-off-by: Piotr Pryga <[email protected]>
Transmission of Constant Tone Extension is done after END event triggered by radio. To correctly switch from TX to TX (back 2 back TX) after transmission of CTE PHYEND event must be used instead of END event. The commit provides required function that allows LLL to correctly setup radio to do back to back switch of TX when CTE transmission is enabled. The radio_switch_complete_and_phy_end_b2b_tx cannot be implemented in radio.c source file. It will fail build of unit tests targeted for NRFBSIM simulator board. There is no RADIO_SHORTS_PHYEND_DISABLE_Msk macro defined in bsim_hw_models module. Signed-off-by: Piotr Pryga <[email protected]>
Add const qualifier in radio API related with setting antenna switch pattern. Signed-off-by: Piotr Pryga <[email protected]>
…sync Configuration of CTE for transmission is stored in extra_date member of a lll_adv_sync object. PDUs in periodic advertising chain share the same CTE configuration, so there is single instance of the extra_data. To configure CTE transmission for every PDU in periodic advertising chain a new function was introduced to peek extra_data instance without peeking new PDU. Signed-off-by: Piotr Pryga <[email protected]>
4e86bb1    to
    31f4803      
    Compare
  
    Add configuration of CTE for periodic advertising chain transmission. The commit provides configuration of radio in prepare stage and in handle of Tx ISR. CTE is configured only for PDUs that have cte_info field in extended advertising header. During prepare of periodic advertising event there are updated aux_ptr fields in extended advertising header in other PDUs from a periodic advertising chain. aux_ptr offset value also depends on CTE length. CTE configuration is always the same for every PDU in periodic advertising chain. CTE may be added to requested number of PDUs in periodic advertising chain. Although it is possible that there are PDUs that don't have CTE. PDUs that have CTE are alsways at the beginning of a periodic advertising chain. Signed-off-by: Piotr Pryga <[email protected]>
Some functions, provided to handle changing content of periodic advertising PDUs, were defined as static. Code responsible for handling direction finding updates periodic advertising PDUs also. For that purposes, those functions were mede globally accessible. Signed-off-by: Piotr Pryga <[email protected]>
…place Enabling or disabling transmission of Constant Tone Extension with periodic advertising PDUs requires update of a PDU content. CTE_INFO field of periodic advertising PDU must be filled with appropriate data. That operation may be done for periodic advertising PDU (or chain of PDUs) filled with other payload that wasn't enqueued towards LLL. In that situation PDUs are updated in place, to avoid increase of memory consumption. The commit changes ull_adv_sync_pdu_set_clear function to make possible update of the advertising PDU in place. Signed-off-by: Piotr Pryga <[email protected]>
31f4803    to
    9978a98      
    Compare
  
    There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only a minor suggestion, otherwise LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very minor change requests, otherwise looks good to me. (Have not tested on target).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove initialization and place is close to its first reference.
Like in the case of ter_hdr_prev place it in else clause of the if at line 902 (this will avoid double assignment, i.e. the current initializer and then inside if clause)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
iirc, structs can only be initialized when declared, so if we remove the initialization here, we'd need to a memset later or set the individual fields to 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change to memset increases FLASH size by 16 bytes in comparison to current version. Unfortunately I haven't got J-Trace to measure it during execution. I'm leaving it as it is implemented to avoid increase of FLASH size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The header is 1 byte, use memset and compiler will optimize it to *((uint8_t *)&ter_hdr_prev) = 0U; which is what was done in the original code, with memset and use of initializer we are at the mercy of the toolchain to assign the one byte.
9978a98    to
    04f2a2e      
    Compare
  
    …chain Direction finding functionality allows to send a number of periodic advertising PDUs in a chain that have CTE. ll_df_set_cl_cte_tx_enable function was changed to update periodic advertising chain to include cte_info field. If the chain is too short, there is less PDUs in the chain than requested number of CTEs, the function will add new empty PDUs to the chain end. Signed-off-by: Piotr Pryga <[email protected]>
To check if advertising PDU is empty we can compare its length to 1. To avoid use of magic number, the commit provides a macro for that purpose. Signed-off-by: Piotr Pryga <[email protected]>
Add release of chained PDUs by lll_adv_pdu_and_extra_data_- latest_get function. It is requier to release unused PDUs from a chain to avoid PDUs leakage. It maight happen when chained PDUs were used by Direction Finding, then lll_adv_pdu_and_extra_data_lates_get is used instead of lll_adv_pdu_lates_get. Signed-off-by: Piotr Pryga <[email protected]>
Direction finding functionality allows to send a number of periodic advertising PDUs in a chain that have CTE. Disable sending CTE requiers additional steps while removing cte_info from periodic advertising chains. Removal of cte_info fields may be just delete of that filed from extended advertising header. In case the PDUs are empty PDUs created just to transport CTE. Those PDUs should be removed from a periodic advertising chain. Signed-off-by: Piotr Pryga <[email protected]>
Bluetooth host may request to send more than one CTE in connectionless mode. That is relized by periodic advertising chained PDUs. To check correctness of implementation of such functionality new unit tests were added. Signed-off-by: Piotr Pryga <[email protected]>
Remove compilation warning about adv_sync_pdu_ad_data_set function that is defined but not used. Signed-off-by: Piotr Pryga <[email protected]>
04f2a2e    to
    2010fd1      
    Compare
  
    | Applied changes requested by @cvinayak. Code was tested by  | 
The PR enhances support for connectionless direction finding with possibility to transmit more than single PDU including CTE.
The multiple CTEs are transmitted with periodic advertising PDUs chain.
If the number of available PDUs in a periodic advertising chain is enough then CTE is just added to requested number of PDUs.
If the number of available PDUs in a chain is lower than number of requested CTEs, then the chain is extended with empty AUX_CHAIN_IND PDUs.
The PR is based on PR: #31875
It may be merged after the base PR is merged to main.