CC2642R: Can't change PHY to CODED

Bonjour Benoit!

On CC26X2, Project_zero and simple_peripheral examples provide a way to change the PHY used based on the RSSI measured. As a result, I assume you are properly changing the PHY but the system changes it again...

I definitely think this auto-PHY update is an interesting feature for most of the applications, however, if you are interesting in removing it in order to lock the PHY used, you can consult the BLE5 Stack User's Guide.

I hope this will help,

Kind regards,

Bonjour Clément,

My custom project is based on Simple peripheral and I disabled auto-PHY negociation for test purpose. I will double check that this functionnality is disabled thanks for the hint.

In ProjectZero I don't find this mecanism. There is RSSI reading but it doesn't lead to PHY change or it is not in the file project_zero.c file. Please note that the project is freshly re-imported and I haven't change anything in it.

Moreover, as explained by your documentation, the initiator of the PHY change should be the only one able to change it back. So if I change the PHY with BTool, only Btool must be able to change it back to another PHY.

Thanks for the help,

Benoit

Hello,

I enabled back the autoPHY in my custom project and I observed the following :

-AutoPHY negociation engaged a PHY change procedure based on RSSI values.

-HCI_BLE_PHY_UPDATE_COMPLETE_EVENT is triggered with SUCCESS status but the value pPUC->rxPhy is always 1 (meaning 1Mbps PHY). I have no idea if the PHY is actually changed or not but the RSSI does not seem to change on PHY change.

Here is a log of my custom board ouput while walking aroung with the BLE central. Notice that since pPUC->rxPhy is always 1 I changed the code to assume that if the status of PHY change command is SUCCESS then the current phy is the requested one.

Note that optimization level of compiler is off to avoid optimization issue. SDK version is 4.10.00.78.

Average RSSI : -32
Average RSSI : -32
Average RSSI : -32
Average RSSI : -32
 phyRq = 6 Conn.rqPhy = 0 Conn.currPhy = 1 failCnt 0 /2Trying CODED S2

PHY Update Status Event: 0x0
PHY Updated to 1M
PHY change succeeded
 phyRq = 1 Conn.rqPhy = 0 Conn.currPhy = 6 failCnt 0 /2Trying 2Mbps

PHY Update Status Event: 0x0
PHY Updated to 1M
PHY change succeeded
Average RSSI : -40
 phyRq = 6 Conn.rqPhy = 0 Conn.currPhy = 1 failCnt 0 /2Trying CODED S2

PHY Update Status Event: 0x0
PHY Updated to 1M
PHY change succeeded
 phyRq = 1 Conn.rqPhy = 0 Conn.currPhy = 6 failCnt 0 /2Trying 2Mbps

PHY Update Status Event: 0x0
PHY Updated to 1M
PHY change succeeded
Average RSSI : -40
Device Disconnected!
Num Conns: 0All devices  Disconnected!
Adv Set 0 Enabled
Adv Set 1 Enabled
Adv Set 0 Disabled
Adv Set 0 disabled after conn 0
Num Conns: 1
Connected to 0x58B10F62CE21Start autoPhyChange
Adv Set 1 Disabled
Average RSSI : 0
Link Param Updated: 0x58B10F62CE21
Average RSSI : 0
Average RSSI : 0
Encryption success
Average RSSI : 0
Average RSSI : 0
 phyRq = 6 Conn.rqPhy = 0 Conn.currPhy = 1 failCnt 0 /2Trying CODED S2

PHY Update Status Event: 0x0
Average RSSI : -45
PHY Updated to 1M
PHY change succeeded
Average RSSI : -47
Average RSSI : -47
Average RSSI : -47
Average RSSI : -49
Average RSSI : -50
 phyRq = 2 Conn.rqPhy = 0 Conn.currPhy = 6 failCnt 0 /2Trying CODED S8

PHY Update Status Event: 0x0
PHY Updated to 1M
PHY change succeeded
Average RSSI : -53

Hello,

I have a similar issue. I am using a CC2642R on a custom board as well. SDK is 3_40_00_02.

My project is based on project zero, but I cherry picked the auto phy update handling from simple peripheral to have a rssi related phy setting for best performance and range.

This works fine regarding HCI_PHY_1_MBPS and HCI_PHY_2_MBPS. I get the HCI_BLE_PHY_UPDATE_COMPLETE_EVENT with status == SUCCESS and rxPhy and txPhy are correct and the same.

But, when it comes to rssi values corresponding to a coded phy setting HCI_PHY_CODED with option LL_PHY_OPT_S2 or LL_PHY_OPT_S8 it does not seem to work.

I get the same behavior like Benoit. HCI_BLE_PHY_UPDATE_COMPLETE_EVENT comes with success and rxPhy and txPhy are equal to 0x03.

What does this value mean? 

I hope someone can help.

Cheers 

Oliver

Hi Oliver,

I think 0x03 stand for PHY_1MBPS or PHY_2MBPS (bitwise or). But I don't know why we get those results.

Regards,

Benoit

Benoit, Olivier,

A few remarks regarding Coded / Non-Coded PHYs:

- The modulation scheme used by BLE (GFSK - Gaussian Frequency Shift Keying) transmits the same power no matter a 0 or a 1 is transmitted. When using the 1M PHY, the receiver determines after 1us if it receives a 1 or a 0. For a 2M PHY, the receiver takes 0.5us, for S4, 4us and for S8, 8us. If it was not clear, the TX Power used by the sender is not modified when using a coded or a non-coded PHY. (Note: this does NOT mean that the power consumption of the device is the same!)
The RSSI measured by the receiver depends on the TxPower used by the transmitter, the antennas’ gains and the environment (including the distance between the devices). The RSSI does NOT depend on the PHY used.
So what is the purpose of changing the PHY? A coded PHY allows a better sensitivity on the receiver’s side (in a very simplistic way, the receiver can filter easily the concurrent signals as it has a longer sampling window).

- The RSSI is not a good way to verify which PHY is used (Note: if the RSSI was modified by changing the PHY, then it would be almost impossible to implement the auto-PHY update based on the RSSI).

- The best way I know to verify which PHY is used is to look at the power profile of the device. Using EnergyTrace (see details here), you will easily see if the device is using a coded or a non-coded PHY.

- Not all the devices allow to use a coded-PHY (1- coded PHY are available only since BLE5, 2- Some systems can disallow PHY update or coded-PHY due to power consumption). The first point is then to verify if both devices can use a coded-PHY (or even if both devices allow to change the PHY). For example, if you are using simple_peripheral the coded PHYs are not allowed by default (cf. function SimplePeripheral_doSetConnPhy())

To finish, regarding Oliver's question, Benoit is right. The value 0x03 corresponds to (LL_PHY_1_MBPS | LL_PHY_2_MBPS).
FYI, we have the following defines:

#define LL_PHY_1_MBPS                                  0x01
#define LL_PHY_2_MBPS                                  0x02
#define LL_PHY_CODED                                   0x04

Best regards,

Clément,

thanks for your detailed reply.

I'm not trying to verify which phy is used based on rssi. I'm trying to select the best phy based on rssi measurement. That is what TI recommends in ble5 examples.

In addition, I followed this manual:

http://software-dl.ti.com/lprf/simplelink_cc26x2_latest/docs/ble5stack/ble_user_guide/html/ble-stack-5.x/phy-coded.html?highlight=hci_phy_use_phy_param#null

I tried this command:

// Set Phy Preference on the current connection. Apply the same value
// for RX and TX.
HCI_LE_SetPhyCmd(connectionHandle, HCI_PHY_USE_PHY_PARAM, HCI_PHY_CODED, HCI_PHY_CODED, 0);

I don''t set a bitmask of phy's. I only set the coded phy. This should force the stack to use the coded phy if supported, or send an error event if not.

According to the documentation there should be a HCI EVENT with status not equal  SUCCESS. But that is not the case. I get always status SUCCESS. So, I guess the coded phy is indeed supported.

The value 0x03 for phy setting still makes no sense to me. Does it mean we are using two phy's at a time? Or is it just the preference of both? If second is right, the event status is confusing.

The link layers of both devices negotiate the phy used based on setting. I can't imagine that it is not possible to read out the result.

Cheers 

Oliver

Clément, Oliver,

Thank you Clément for your answer, indeed RSSI may not be a relevant information to detect PHY change, the problem is we always get a wrong value for current phy on event's callback.

This problem is not due to a BLE4 central. Below is two different logs, the first with a BLE5 central and the second with a BLE4 central. We clearly got an error code in the second case whereas we got a SUCCESS on the first.

First case : BLE5 central
Connected to 0x58B10F62CE21Start autoPhyChange
Adv Set 1 Disabled
Link Param Updated: 0x58B10F62CE21
Average RSSI : 0
Average RSSI : 0
Encryption successGAP_UPDATE_LINK_PARAM_REQ_EVENT:

Average RSSI : 0
Average RSSI : 0
 phyRq = 6 Conn.rqPhy = 0 Conn.currPhy = 1 failCnt 0 /2Trying CODED S2

PHY Update Status Event: 0x0
PHY Change failure (code 0x2a) <--- First two attempts failed (maybe due to connection ?)
PHY request change failed asked 6 got 1
 phyRq = 6 Conn.rqPhy = 6 Conn.currPhy = 1 failCnt 1 /2Trying CODED S2

PHY Update Status Event: 0x0
Average RSSI : -48
PHY Change failure (code 0x2a)
PHY request change failed asked 6 got 1
Link Param Updated: 0x58B10F62CE21GAP_UPDATE_LINK_PARAM_REQ_EVENT:

Average RSSI : -50
Average RSSI : -50INT_ACC index is 1
Average RSSI : -50
 phyRq = 2 Conn.rqPhy = 6 Conn.currPhy = 1 failCnt 2 /2Trying CODED S8

PHY Update Status Event: 0x0
PHY Updated to 1M
PHY change succeeded<---Then other attempts succeed but current PHY is always 1
 phyRq = 6 Conn.rqPhy = 0 Conn.currPhy = 2 failCnt 0 /2Trying CODED S2

PHY Update Status Event: 0x0
PHY Updated to 1M
PHY change succeeded
Average RSSI : -50
 phyRq = 2 Conn.rqPhy = 0 Conn.currPhy = 6 failCnt 0 /2Trying CODED S8

PHY Update Status Event: 0x0
PHY Updated to 1M
PHY change succeeded
 phyRq = 6 Conn.rqPhy = 0 Conn.currPhy = 2 failCnt 0 /2Trying CODED S2

Second case BLE4 central :

Connected to 0x202D078893E0Start autoPhyChange
Adv Set 1 Disabled
Link Param Update Failed 0x7: 0x202D078893E0
Average RSSI : 0
Encryption success.
Average RSSI : 0
 phyRq = 2 Conn.rqPhy = 0 Conn.currPhy = 1 failCnt 0 /2Trying CODED S8

PHY Update Status Event: 0x0
PHY Change failure (code 0x1e) <---- BLE4 central does not support PHY change
PHY request change failed asked 2 got 1
 phyRq = 2 Conn.rqPhy = 2 Conn.currPhy = 1 failCnt 1 /2Trying CODED S8

PHY Update Status Event: 0x0
PHY Change failure (code 0x1e)
PHY request change failed asked 2 got 1.
Average RSSI : -58.
Average RSSI : -60.
Average RSSI : -60.
Average RSSI : -59
Average RSSI : -59
Average RSSI : -59
Average RSSI : -58
Average RSSI : -57
Average RSSI : -57
Average RSSI : -57
Average RSSI : -58
Average RSSI : -58
Average RSSI : -57
Average RSSI : -58

EDIT : I change the RSSI thresholds value, and it works in 2 Mbps. Phy change suceeded, and current PHY returned by event is 2 as expected. I still encounter the issue with CODED phy.

Benoit, Clément,

I did some further testing and took a closer look at the example code. First, I dig into the example code:

if (rssi != LL_RSSI_NOT_AVAILABLE)
        {
          connList[index].rssiArr[connList[index].rssiCntr++] = rssi;
          connList[index].rssiCntr %= SP_MAX_RSSI_STORE_DEPTH;

          int16_t sum_rssi = 0;
          for(uint8_t cnt=0; cnt<SP_MAX_RSSI_STORE_DEPTH; cnt++)
          {
            sum_rssi += connList[index].rssiArr[cnt];
          }
          connList[index].rssiAvg = (uint32_t)(sum_rssi/SP_MAX_RSSI_STORE_DEPTH);

          uint8_t phyRq = SP_PHY_NONE;
          uint8_t phyRqS = SP_PHY_NONE;
          uint8_t phyOpt = LL_PHY_OPT_NONE;

          if(connList[index].phyCngRq == FALSE)
          {
            if((connList[index].rssiAvg >= RSSI_2M_THRSHLD) &&
            (connList[index].currPhy != HCI_PHY_2_MBPS) &&
                 (connList[index].currPhy != SP_PHY_NONE))
            {
              // try to go to higher data rate
              phyRqS = phyRq = HCI_PHY_2_MBPS;
            }
            else if((connList[index].rssiAvg < RSSI_2M_THRSHLD) &&
                    (connList[index].rssiAvg >= RSSI_1M_THRSHLD) &&
                    (connList[index].currPhy != HCI_PHY_1_MBPS) &&
                    (connList[index].currPhy != SP_PHY_NONE))
            {
              // try to go to legacy regular data rate
              phyRqS = phyRq = HCI_PHY_1_MBPS;
            }
            else if((connList[index].rssiAvg >= RSSI_S2_THRSHLD) &&
                    (connList[index].rssiAvg < RSSI_1M_THRSHLD) &&
                    (connList[index].currPhy != SP_PHY_NONE))
            {
              // try to go to lower data rate S=2(500kb/s)
              phyRqS = HCI_PHY_CODED;
              phyOpt = LL_PHY_OPT_S2;
              phyRq = BLE5_CODED_S2_PHY;
            }
            else if(connList[index].rssiAvg < RSSI_S2_THRSHLD )
            {
              // try to go to lowest data rate S=8(125kb/s)
              phyRqS = HCI_PHY_CODED;
              phyOpt = LL_PHY_OPT_S8;
              phyRq = BLE5_CODED_S8_PHY;
            }
            if((phyRq != SP_PHY_NONE) &&
               // First check if the request for this phy change is already not honored then don't request for change
               (((connList[index].rqPhy == phyRq) &&
                 (connList[index].phyRqFailCnt < 2)) ||
                 (connList[index].rqPhy != phyRq)))
            {
              //Initiate PHY change based on RSSI

              SimplePeripheral_setPhy(connList[index].connHandle, 0, phyRqS, phyRqS, phyOpt);

              connList[index].phyCngRq = TRUE;

              // If it a request for different phy than failed request, reset the count
              if(connList[index].rqPhy != phyRq)
              {
                // then reset the request phy counter and requested phy
                connList[index].phyRqFailCnt = 0;
              }

              if(phyOpt == LL_PHY_OPT_NONE)
              {
                connList[index].rqPhy = phyRq;
              }
              else if(phyOpt == LL_PHY_OPT_S2)
              {
                connList[index].rqPhy = BLE5_CODED_S2_PHY;
              }
              else
              {
                connList[index].rqPhy = BLE5_CODED_S8_PHY;
              }

            } // end of if ((phyRq != SP_PHY_NONE) && ...
          } // end of if (connList[index].phyCngRq == FALSE)
        } // end of if (rssi != LL_RSSI_NOT_AVAILABLE)

After each rssi measurement the result is evaluated and depending on thresholds a phy change is may set. But, the expected values of the state machine are a bit confusing. As it works for 1M and 2M phy I explain it wit the coded setting:

              // try to go to lower data rate S=2(500kb/s)
              phyRqS = HCI_PHY_CODED;     //0x04
              phyOpt = LL_PHY_OPT_S2;     //0x01
              phyRq = BLE5_CODED_S2_PHY;  //0x06

phyRqS and phyOpt are the parameter for SimplePeripheral_setPhy function.

phyRq is the expected value for negotiated phy setting after change in HCI_BLE_PHY_UPDATE_COMPLETE_EVENT.

With S8 comes the confusing part:

              // try to go to lowest data rate S=8(125kb/s)
              phyRqS = HCI_PHY_CODED;     //0x04
              phyOpt = LL_PHY_OPT_S8;     //0x02
              phyRq = BLE5_CODED_S8_PHY;  //0x02

The expected value in HCI_BLE_PHY_UPDATE_COMPLETE_EVENT is the same as for 2M phy which makes no sense.

Now it comes to testing. I set up two devices for the test with a distance of approx. 0,5 m. I want to compare the data rates for the different phy settings to verify that a phy change succeeded.

I tested all the phy setting by manipulating the rssi thresholds. During one test there is only one phy setting and it is not changed. Connection parameter are the same as well.

For comparison I read the same data from an EEPROM which is connected via I2C. The table shows the time I measured to read out the data. I repeated every setting 2 times.

The difference would have to be larger per definition but EEPROM access and transmission via i2c is constant dead time in this case.

So, I conclude that phy change is working but the expected values in HCI_BLE_PHY_UPDATE_COMPLETE_EVENT is not right in example code.

Maybe someone can try to reproduce.

Cheers

Oliver

Hi Clemént,

thank you for your investigation. Good to know that switching between PHY's is working. Nevertheless, this should be corrected in example code to avoid that others have the same struggle.

I have one remaining question. If there is only 0x01 for 1M, 0x02 for 2M and  0x03 for coded, how can I read out the used coding scheme (S2 or S8) which was also set with HCI_LE_Set_PHY.

When I switch from coded PHY S2 to coded PHY S8 or the other way around it is both 0x03 in  LE PHY Update Complete event.

Cheers

Oliver

Hi Olivier,

If it was not clear, the symbols to use are the following (this is an extract of hci.h file):

/**
 * @defgroup PHY_UPDATE PHY Update Complete Event
 * @{
 */
#define PHY_UPDATE_COMPLETE_EVENT_1M                   1  //!< Complete event for 1 Mbps
#define PHY_UPDATE_COMPLETE_EVENT_2M                   2  //!< Complete event for 2 Mbps
#define PHY_UPDATE_COMPLETE_EVENT_CODED                3  //!< Complete event for coded phy
/** @} End PHY_UPDATE */

Those values are properly used in the example:

              Display_printf(dispHandle, SP_ROW_STATUS_2, 0,
                             "PHY Updated to %s",
                             (pPUC->rxPhy == PHY_UPDATE_COMPLETE_EVENT_1M) ? "1M" :
                             (pPUC->rxPhy == PHY_UPDATE_COMPLETE_EVENT_2M) ? "2M" :
                             (pPUC->rxPhy == PHY_UPDATE_COMPLETE_EVENT_CODED) ? "CODED" : "Unexpected PHY Value");

That being said, could you suggest me the modification you would like to see in our project example? I will do my best to integrate your suggestion in the next SDK version.

Oliver2112 said:

If there is only 0x01 for 1M, 0x02 for 2M and  0x03 for coded, how can I read out the used coding scheme (S2 or S8) which was also set with HCI_LE_Set_PHY.

The BLE spec defines only one return value for all the coded PHYs. You won't be able to get this information from the  LE PHY Update Complete event.

I hope this will help,

Regards,

Hi Clément,

the symbols were clear, but not the interpretation in LE PHY Update Complete event.

If you take a look at SimplePeripheral_updatePHYStat function from simple peripheral example which is called when complete event fires:

        // LE Events
        case HCI_LE_EVENT_CODE:
        {
          hciEvt_BLEPhyUpdateComplete_t *pPUC =
            (hciEvt_BLEPhyUpdateComplete_t*) pMsg;

          // A Phy Update Has Completed or Failed
          if (pPUC->BLEEventCode == HCI_BLE_PHY_UPDATE_COMPLETE_EVENT)
          {
            SimplePeripheral_updatePHYStat(HCI_BLE_PHY_UPDATE_COMPLETE_EVENT, (uint8_t *)pMsg);
          }
          break;

And inside the function:

/*********************************************************************
* @fn      SimplePeripheral_updatePHYStat
*
* @brief   Update the auto phy update state machine
*
* @param   connHandle - the connection handle
*
* @return  None
*/
static void SimplePeripheral_updatePHYStat(uint16_t eventCode, uint8_t *pMsg)
{
  uint8_t connIndex;

  switch (eventCode)
  {
    case HCI_LE_SET_PHY:
    {
      // Get connection handle from list
      spConnHandleEntry_t *connHandleEntry = (spConnHandleEntry_t *)List_get(&setPhyCommStatList);

      if (connHandleEntry)
      {
        // Get index from connection handle
        connIndex = SimplePeripheral_getConnIndex(connHandleEntry->connHandle);

        ICall_free(connHandleEntry);

        // Is this connection still valid?
        if (connIndex < MAX_NUM_BLE_CONNS)
        {
          hciEvt_CommandStatus_t *pMyMsg = (hciEvt_CommandStatus_t *)pMsg;

          if (pMyMsg->cmdStatus == HCI_ERROR_CODE_UNSUPPORTED_REMOTE_FEATURE)
          {
            // Update the phychange request status for active RSSI tracking connection
            connList[connIndex].phyCngRq = FALSE;
            connList[connIndex].phyRqFailCnt++;
          }
        }
      }
      break;
    }

    // LE Event - a Phy update has completed or failed
    case HCI_BLE_PHY_UPDATE_COMPLETE_EVENT:
    {
      hciEvt_BLEPhyUpdateComplete_t *pPUC =
                                     (hciEvt_BLEPhyUpdateComplete_t*) pMsg;

      if(pPUC)
      {
        // Get index from connection handle
        connIndex = SimplePeripheral_getConnIndex(pPUC->connHandle);

        // Is this connection still valid?
        if (connIndex < MAX_NUM_BLE_CONNS)
        {
          // Update the phychange request status for active RSSI tracking connection
          connList[connIndex].phyCngRq = FALSE;

          if (pPUC->status == SUCCESS)
          {
            connList[connIndex].currPhy = pPUC->rxPhy;
          }
          if(pPUC->rxPhy != connList[connIndex].rqPhy)
          {
            connList[connIndex].phyRqFailCnt++;
          }
          else
          {
            // Reset the request phy counter and requested phy
            connList[connIndex].phyRqFailCnt = 0;
            connList[connIndex].rqPhy = 0;
          }
        }
      }

      break;
    }

    default:
      break;
  } // end of switch (eventCode)
}

As you see, this always fails when a coded PHY is set by increasing connList[connIndex].phyRqFailCnt, because you compare this values:

/**
* @defgroup PHY_2_CODED 2 Mbps & Coded PHY
* @{
*/
#define HCI_PHY_USE_PHY_PARAM         LL_PHY_USE_PHY_PARAM //!< Use Phy Param
#define HCI_PHY_USE_ANY_PHY              LL_PHY_USE_ANY_PHY //!< Use any Phy
#define HCI_PHY_1_MBPS                          LL_PHY_1_MBPS //!< 1 Mbps
#define HCI_PHY_2_MBPS                          LL_PHY_2_MBPS //!< 2 Mbps
#define HCI_PHY_CODED                           LL_PHY_CODED //!< Coded
/** @} End PHY_2_CODED */

to this:

Clément said:

/**
 * @defgroup PHY_UPDATE PHY Update Complete Event
 * @{
 */
#define PHY_UPDATE_COMPLETE_EVENT_1M                   1  //!< Complete event for 1 Mbps
#define PHY_UPDATE_COMPLETE_EVENT_2M                   2  //!< Complete event for 2 Mbps
#define PHY_UPDATE_COMPLETE_EVENT_CODED                3  //!< Complete event for coded phy
/** @} End PHY_UPDATE */

As a result you retry setting coded PHY until your max. number of retrys.

Cheers 

Oliver

Hi Olivier,

Thank you for the details you provided. I really appreciate your feedback.

Best regards,