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

[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

[Kenneth]

Hello,

Vidar has started his vacation. I don't see any specific question here, more of a discussion and you are free to implement this as you best see fit based on your requirements. Just a quick note that even sd_ble_gap_connect() will wait for advertisement to be received before the softdevice will send the connection request packet, I believe that when you call sd_ble_gap_connect() you can also specify which phy to use both for scanning when trying to establish connection and for the connection to be established based on the connection request packet. My general feel on coded phy is that it works reliably well outdoor, but indoor (especially in environment with other 2.4GHz interference) the throughput will be very much influenced by the fact that the risk of interference during packet transmission/reception is 8x that of standard 1Mbps phy. 

Kenneth