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

[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

[Vidar Berg]

Hello Hardy,

I agree with your summary of the peripheral role. Except it's still not clear to me why you need to change the connection interval for the long range mode. You are not guaranteed 6 packets per connection event even if the interval is long enough. Does it have something to do with how you handle the transfer in your application maybe?

rgrr2 said:

advertisement packets are coming in, but it is not clear (to me), which PHYs the peer is supporting

You can read the this from the ble_gap_evt_adv_report_t struct included with the BLE_GAP_EVT_ADV_REPORT event.

Regards,

Vidar

[rgrr2]

Hello Vidar,

apologies... I would like to reply to your latest post, but unfortunately this is not possible because there is no button to do it.

Anyway: I understood, that on the central side one has to get an advertisement to know the PHY used by the peripheral.

But what if the connection has been created via sd_ble_gap_connect() with a known peripheral so that no advertisements had to be received ahead?

To answer your question: changing the connection interval is a matter of power/speed optimization. Our peripheral tries to send as many packets per event as the central is accepting.  Sometimes the behavior of the central (esp Androids) is not very consistent and we try to offer the central several connection parameters until both sides are happy.

Kind regards

Hardy