Backwards compatibility for BLE4 for CODED PHY advertising?

[Luke.L]

I am wondering whether it is possible to maintain backwards compatibility for BL4 while also taking advantage of the BLE5 LR CODED PHY?

I am guessing I could scan in AUTO_PHY for one interval cycle before switching to CODED PHY, but how would that affect Bonding afterwards?

If it is possible, could we scan in both AUTO_PHY and CODED PHY?

[AndreasF]

Hi.

Are you talking about advertising og scanning?

You should be able to switch between BLE_GAP_PHY_1MBPS and BLE_GAP_PHY_CODED.

You have to update the scan_phy in the ble_gap_scan_params_t struct for scanning, and update the primary_phy or secondary_phy for the ble_gap_adv_params_t struct for advertising.

I also think that you have to start/stop scanning/advertising.

Best regards,

Andreas

[Luke.L]

Hi AndreasF

Thanks for the reply, I am talking about both. I am guessing I will need to stop/start scanning/advertising? Are there any caveats to such a solution? What about the alternating PHY as mention in that above link?

[AndreasF]

Hi.

If you are in a connection, you could use the SoftDevice API sd_ble_gap_phy_update() to change between the PHY's.

/**@brief Initiate or respond to a PHY Update Procedure
 *
 * @details   This function is used to initiate or respond to a PHY Update Procedure. It will always
 *            generate a @ref BLE_GAP_EVT_PHY_UPDATE event if successfully executed.
 *            If this function is used to initiate a PHY Update procedure and the only option
 *            provided in @ref ble_gap_phys_t::tx_phys and @ref ble_gap_phys_t::rx_phys is the
 *            currently active PHYs in the respective directions, the SoftDevice will generate a
 *            @ref BLE_GAP_EVT_PHY_UPDATE with the current PHYs set and will not initiate the
 *            procedure in the Link Layer.
 *
 *            If @ref ble_gap_phys_t::tx_phys or @ref ble_gap_phys_t::rx_phys is @ref BLE_GAP_PHY_AUTO,
 *            then the stack will select PHYs based on the peer's PHY preferences and the local link
 *            configuration. The PHY Update procedure will for this case result in a PHY combination
 *            that respects the time constraints configured with @ref sd_ble_cfg_set and the current
 *            link layer data length.
 *
 *            When acting as a central, the SoftDevice will select the fastest common PHY in each direction.
 *
 *            If the peer does not support the PHY Update Procedure, then the resulting
 *            @ref BLE_GAP_EVT_PHY_UPDATE event will have a status set to
 *            @ref BLE_HCI_UNSUPPORTED_REMOTE_FEATURE.
 *
 *            If the PHY procedure was rejected by the peer due to a procedure collision, the status
 *            will be @ref BLE_HCI_STATUS_CODE_LMP_ERROR_TRANSACTION_COLLISION or
 *            @ref BLE_HCI_DIFFERENT_TRANSACTION_COLLISION.
 *            If the peer responds to the PHY Update procedure with invalid parameters, the status
 *            will be @ref BLE_HCI_STATUS_CODE_INVALID_LMP_PARAMETERS.
 *            If the PHY procedure was rejected by the peer for a different reason, the status will
 *            contain the reason as specified by the peer.
 *
 * @events
 * @event{@ref BLE_GAP_EVT_PHY_UPDATE, Result of the PHY Update Procedure.}
 * @endevents
 *
 * @mscs
 * @mmsc{@ref BLE_GAP_CENTRAL_PHY_UPDATE}
 * @mmsc{@ref BLE_GAP_PERIPHERAL_PHY_UPDATE}
 * @endmscs
 *
 * @param[in] conn_handle   Connection handle to indicate the connection for which the PHY Update is requested.
 * @param[in] p_gap_phys    Pointer to PHY structure.
 *
 * @retval ::NRF_SUCCESS Successfully requested a PHY Update.
 * @retval ::NRF_ERROR_INVALID_ADDR Invalid pointer supplied.
 * @retval ::BLE_ERROR_INVALID_CONN_HANDLE Invalid connection handle supplied.
 * @retval ::NRF_ERROR_INVALID_PARAM Invalid parameter(s) supplied.
 * @retval ::NRF_ERROR_INVALID_STATE No link has been established.
 * @retval ::NRF_ERROR_RESOURCES The connection event length configured for this link is not sufficient for the combination of
 *                               @ref ble_gap_phys_t::tx_phys, @ref ble_gap_phys_t::rx_phys, and @ref ble_gap_data_length_params_t.
 *                               The connection event length is configured with @ref BLE_CONN_CFG_GAP using @ref sd_ble_cfg_set.
 * @retval ::NRF_ERROR_BUSY Procedure is already in progress or not allowed at this time. Process pending events and wait for the pending procedure to complete and retry.
 *
 */
SVCALL(SD_BLE_GAP_PHY_UPDATE, uint32_t, sd_ble_gap_phy_update(uint16_t conn_handle, ble_gap_phys_t const *p_gap_phys));

If you are not in a connection, you could do as I said in my previous reply.

For advertising, there are as I said two PHY's in the ble_gap_adv_params_t struct, primary and secondary. The different between these two is that the secondary PHY is the PHY the connection will be established on.

Please keep in mind that for scanning on two different PHY's, the scan window should be less than (scan interval/2).

Best regards,

Andreas