BLE Coded PHY: how to determine used data rate

[rgrr2]

Hello,

I'm trying to determine the actual used data rate for the coded PHY but cannot find the corresponding API / data structure / enums.

Am I missing something?  Can someone give me a pointer?

Regards

Hardy

[Vidar Berg]

Hello Hardy,

As you have noticed, there event struct does not include any fields which tell what the actual data rate is. The Softdevice doesn't support sending with s=2 encoding (500 kbit/s) so it's only when you receive data that it may see this data rate. It is s=8 (125 kbit/s) otherwise.

Regards,

Vidar

[rgrr2]

Hello Vidar,

thanks for response.  I thought S=2 has been introduced in S140 6.0.0?  So I guess I'm wrong.

One more point: how to determine, if PHY_CODED is really used?  Is there an API for querying the used PHY?

Thanks & regards

Hardy

[Vidar Berg]

Hello Hardy,

I guess you could say s=2 support was introduced in this release since it did add support for receiving packets with this encoding. There is no Softdevice API to query what PHY is currently in use, but this should be easy to monitor from the app. The connection will always be established with the same PHY used by the advertiser, and the PHY can't be updated without triggering the BLE_GAP_PHY_UPDATE event (PHY Update Procedure).

Regards,

Vidar

[rgrr2]

Hello Vidar,

concerning the used PHY: if one offers a PHY via primary/secondary_phy in the adv params one does not automatically know which PHY is being used, right?

Problem here are the connection parameters, the device offers the central which could lead to impossible combinations.  E.g. 6 packets/event on a 12ms connection interval if PHY_CODED has been selected.

How to "code" around?

Kind regards

Hardy

[Vidar Berg]

Hello Hardy,

The connection is always established with the same PHY depending on how the advertiser is configured. The initiator will use your secondary_phy to initiate the connection if you do extended advertising. The primary phy is used otherwise.

rgrr2 said:

Problem here are the connection parameters, the device offers the central which could lead to impossible combinations.  E.g. 6 packets/event on a 12ms connection interval if PHY_CODED has been selected.

Do you want to have a longer interval if coded PHY is used? Please note that the number of packets you can send per connection event (i.e. even length) is not a connection paramter like the interval is. The number of packets you can send depends on what the central support, max. event length on the peripheral, and packet loss (event will end early if there is packet loss).

Kind regards,

Vidar

[rgrr2]

Hello Vidar,

as far as I understood, one can specify multiply PHYs for the secondary.  So used PHY is not clear.

Number of packets is a connection optimization which I would like to set to 6 (central supports this) if 1MBps PHY is used and to two if PHY_CODED is used.

Also the connection interval has to be set accordingly, especially if you have power constraints, so that a maximum of 10ms radio time is allowed in a certain interval.

So... how to determine used PHY?

Thanks & kind regards

Hardy

[Vidar Berg]

Hello Hardy,

Do you have an existing application that switches between multiple PHYs? You can't specify multiple secondary PHYs for a single adv. set nor does the softdevice support configuration of multiple sets.

I would recommend you try the nRF Sniffer for Bluetooth LE if you want to check what happens on-air.

Kind regards,

Vidar

[rgrr2]

Hello Vidar,

sorry... I guess I mixed up several things. I also meant the central in this case.

For the peripheral the procedure is to my understanding as follows:

• primary_phy in adv is just used to distribute some data via advertisements
• secondary_phy is used to connect (if extended advertising is used)
• so it is clear with which PHY the connection is being established
• after that, PHY can be changed via sd_ble_gap_phy_update()
• the peer side application is informed about the PHY update request via the event BLE_GAP_EVT_PHY_UPDATE_REQUEST and BLE_GAP_EVT_PHY_UPDATE
• at the moment only S=8 is supported for PHY_CODED, so a PHY_CODED connection has always 125kbit/s
• with this information, the connection can be further optimized, e.g. setting connection period, packets/event etc.

So no problem here.

But for the central:

• in the scan_params scan_phys is the bitmap which I mixed up in the post before
• in scan_phys one can set e.g. 1MBit and Coded
• advertisement packets are coming in, but it is not clear (to me), which PHYs the peer is supporting
• call to sd_ble_gap_connect() has to specify all PHYs selected in scan_phys above to get a connection
• the central does not really know about the PHY being used.  Right?

For your understanding: there is already a working application which uses 1MBit and we are currently discussing how to introduce PHY_CODED etc.

Thanks for your support & regards

Hardy