Revert back to Coded PHY connection when 2M is not possible because of distance.

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

Simonr — Wed, 15 Dec 2021 11:25:15 GMT

No, I don't think the Coded PHY should have reduced range because you switch between 2MBPS and Coded PHY. You will need to make sure that the Coded PHY side have enough time to transmit its data between every time it switches between 2MBPS and Coded PHY, but as soon as it is in Coded PHY, it shouldn't be hindered by its own radio.

Best regards,

Simon

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

JasonGeo — Wed, 15 Dec 2021 00:44:00 GMT

Thank you Simon, at least now we have more understanding why we don't see the extended range possible with Coded PHY.

One more thing, in our setup, we have this nRF52840 DK siting in between 2 other DKs communicating back and forth between them. This middle DK establishes 2M connection with one DK and Coded PHY with the other DK.

Do you think as a result of this setup/configuration, we get reduced range as well with the Coded PHY link since the radio on the middle DK is shared/multiplexed between talking on 2M to one and Coded PHY to the other?

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

Simonr — Tue, 14 Dec 2021 10:17:58 GMT

I'm sorry you have trouble with the DevZone. You can try deleting your browser cookies to see if that helps with the loading times of DevZone pages.

This other DK or 52 device (on top of the 840 DK) also doing BLE transmissions is indeed likely to affect the range you'll be able to achieve over Coded PHY, as they transmit on similar frequencies they're bound to affect each others performance I'm afraid. I don't think the data length will affect your range, just the transmission time between each event, since Coded PHY transmissions take ~8 times longer than transmissions on the other PHYs.

Best regards,

Simon

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

JasonGeo — Mon, 13 Dec 2021 07:33:53 GMT

Hi Simon, Thanks for coming back.

Sorry for the long silence. I've got some problem with this website. It takes forever to load this page and just realised I need to close my browser and reopen it for it to work for some strange reason.

Will try to get some sniffer trace for you. Isn't the code I shown at the top the advertising initialization?

We went out to the open field and conducted the Nordic long range test below.

https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/testing-long-range-coded-phy-with-nordic-solution-it-simply-works-922075585

We managed to get CodedPHY adv at 475m, which is better than what we could with our firmware at 200m.

One thing I forgot to mentioned is that in addition to the nRF52840 DK, we also have a nRF52DK board stacked on top of it propagating Bluetooth 4.2 radio protocol. Will that affect/decrease the range of Coded PHY on the 52840 DK?

Also comparing the bluetooth parameters we have with the Nordic long range example, we are using datalength of 251 and the example datalength is 27.
Do you know if these bluetooth parameters have an effect on the range as well?

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

Simonr — Mon, 06 Dec 2021 10:13:47 GMT

A timeout would point to the connection not communicating for a while, either due to poor reception or just that the application doesn't do anything. Since you're using the Sniffer, I assume you can see there that the devices indeed are communicating over the Coded PHY before doing this sd_ble_gap_phy_update() but I really think you should be able to see successful transmissions on the Coded PHY for more than 200m. Can you show me your advertising initialization or upload your sniffer trace so I can take a look at it?

Best regards,

Simon

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

JasonGeo — Wed, 01 Dec 2021 02:06:09 GMT

Hi Simon,

[quote userid="75734" url="~/f/nordic-q-a/81951/revert-back-to-coded-phy-connection-when-2m-is-not-possible-because-of-distance/341255#341255"]Are you able to see the disconnect reason between the two devices when disconnecting in Coded PHY? [/quote]

The reason is HCI status code is 0x08 Connection Timeout.

[quote userid="75734" url="~/f/nordic-q-a/81951/revert-back-to-coded-phy-connection-when-2m-is-not-possible-because-of-distance/341255#341255"]If you have a connection running on the Coded PHY I agree that you should be able to do a sd_ble_gap_phy_update(), but it might fail, or disconnect right away when the devices are too far apart to sustain a connection on the 2MBPS PHY.[/quote]

Thanks for the confirmation, however I have yet to make the update fail / disconnect right away.

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

Simonr — Tue, 30 Nov 2021 11:52:52 GMT

I think the L2CAP fragment CRC errors indicate lower sensitivity and thus more packets failing to reach their destination correctly, but as long as you still get the data you're transmitting as expected this shouldn't be anything to worry about.

When the devices are connected in Coded PHY I agree that you should be able to sustain a connection over more than 200 meters. Are you able to see the disconnect reason between the two devices when disconnecting in Coded PHY? I think we need to find the reason for the disconnect to determine why you're not able to attain longer ranges with Coded PHY than 2MBPS PHY.

If you have a connection running on the Coded PHY I agree that you should be able to do a sd_ble_gap_phy_update(), but it might fail, or disconnect right away when the devices are too far apart to sustain a connection on the 2MBPS PHY.

Best regards,

Simon

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

JasonGeo — Tue, 30 Nov 2021 07:55:24 GMT

Hi Simon,

I've setup the nRF Sniffer in the office and verified that we are advertising in coded PHY and then successfully updated the PHY mode to 2Mbps on connection. All subsequent transactions are in 2Mbps.

I do noticed too as the distance increases while connected on 2M, I saw a lot more L2CAP Fragment with the CRC Error flag set. Does that mean something I need to take note of?

Thereafter I went and do more range testing this time in an open area. Same setup as before, advertising in Coded PHY, on succesful connection update PHY to 2Mbps.

Findings,

I am able to connect on coded PHY and update to 2Mbps every single time up to a distance of around 200 metres. As I then walked further, the boards disconnected and I am not able to reconnect again until I walked back into range i.e. 200 metres.

I then modified my code to only adv and connect on Coded PHY, NO UPDATE of PHY to 2 Mbps. I observed the same results as before! I thought I will be able to get couple of hundreds metres more than 2 Mbps but No.

Can you please help me with this last question. If we can connect on Coded PHY adv, we can always update to 2Mbps regardless of the distance (say 1 Km) since we both agree sd_ble_gap_phy_update() function takes place in the current PHY which is Coded yes? And if on successful update to 2Mbps (PHY PHY_UPDATE event trig), because the distance is now too great for 2Mbps to support, a disconnection will result instaneously? or will it not?

Thanks Simon.

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

Simonr — Fri, 26 Nov 2021 09:23:08 GMT

I think the easiest way to make sure what PHY is used is to either print in a log what PHY is currently used, or to use a sniffer device to catch the packets on the air and see what PHY it is sent over. I'm only aware of the Ellisys sniffers that support sniffing over the Coded PHY, but you could use the nRF Sniffer to detect any activity on the 2MBPS PHY at least. You can also choose the advertising device so you don't catch a lot of random BLE activity as well.

You can also only use 2MBPS to connect and check what range you are able to achieve, as I don't know how noisy your test environment is. Even though I don't think you'll be able to reach 100m in a noisy environment even with 8dBm TX power.

Best regards,

Simon

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

JasonGeo — Fri, 26 Nov 2021 01:43:52 GMT

Thanks Simon,

Will try to do some more testing with the distance as suggested.

I am abit concern now if I did indeed connect on 2MBPS at 100 metres. Maybe it was still on Coded PHY!

A side note, we have the Tx power set to 8dBm, a high one. Not sure if it says something.

Just to confirm if the Central initiate the PHY update, do we have to confirm on BOTH the peripheral and central side that they both received the BLE_GAP_EVT_PHY_UPDATE event before we can be sure that the connection link is indeed updated to 2 MBPS?

Any other means to check for current PHY status?

Because currently, I only handle that event in the peripheral, not the central.

Is it still possible that we connect on 2MBPS only to disconnect almost instantaneously because of poor reception or interference?

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

Simonr — Thu, 25 Nov 2021 10:10:48 GMT

100 meters in a noisy environment as you describe, does indeed sound like too far away for a 2MBPS PHY connection, I would think you need to get as close as 20 meters to get a good connection on the 2MBPS PHY. sd_ble_gap_phy_update() is used to initiate or respond to a PHY update procedure. It will always generate a BLE_GAP_EVT_PHY_UPDATE event if executed successfully. Yes, it will stay on the current PHY within this function, then generate a PHY_UPDATE event (if successful) which will cause the devices to move to the new PHY.

/**@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_NOT_SUPPORTED Unsupported PHYs supplied to the call.
* @retval ::NRF_ERROR_INVALID_STATE No link has been established.
* @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));

[quote user="JasonGeo"]always connect in Coded PHY and if RSSI value is strong (which means devices are close to each other) trigger a PHY update to switch to 2M[/quote]

Yes, that should work as well.

Best regards,

Simon

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

JasonGeo — Thu, 25 Nov 2021 01:28:28 GMT

Hi Simon,

The distance is approximately 100 metres. Note that this is conducted on a noisy street with buildings on either sides of the road. One of the board is laying flat on the walk steps hence the reception might not be that great.

Yes, I saw from the logging that PHY is updated to 2MBPS.

Thanks for the confirmation on the code.

[quote userid="111111" url="~/f/nordic-q-a/81951/revert-back-to-coded-phy-connection-when-2m-is-not-possible-because-of-distance/340445#340445"]Correct me if I am wrong, but I think the "handshake" between central and peripheral is still taking place on Coded PHY when sd_ble_gap_phy_update() is taking place and when they are both updated to 2M, because of the distance is too far for 2M to support, the devices would disconnect after a short interval, say between 1 to 5 seconds? Shoudl this be the expected observation?[/quote]

Can you help to confirm if this is the case?

[quote userid="75734" url="~/f/nordic-q-a/81951/revert-back-to-coded-phy-connection-when-2m-is-not-possible-because-of-distance/340242#340242"]You can make the central device check the RSSI (Received Signal Strength Indicator) of the peripheral and when it's under a certain value you can trig a PHY update to switch to the Coded PHY.[/quote]

I think for my use case, it would be more of always connect in Coded PHY and if RSSI value is strong (which means devices are close to each other) trigger a PHY update to switch to 2M. Will that work?

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

Simonr — Wed, 24 Nov 2021 13:14:48 GMT

Hi again

What is the distance you're seeing between the two devices exactly? Are you able to see the MTU/PHY update in logging or something to make sure you actually move to the 2MBPS PHY? Your advertising parameters seem to be correct, so I would think it advertises on the Coded PHY at least.

Best regards,

Simon

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

JasonGeo — Wed, 24 Nov 2021 03:22:24 GMT

Hi Simon,

Thanks for coming back!

The SDK version is nRF5_SDK_15.2.0

Yes, one DK is acting as a central and the other is advertising and connecting to it.

I am surprised too that I don't get the extra range Coded PHY provides. As mentioned, whenever I got connected on Coded PHY mode, the central will ask for PHY mode change to 2M via sd_ble_gap_phy_update().

Correct me if I am wrong, but I think the "handshake" between central and peripheral is still taking place on Coded PHY when sd_ble_gap_phy_update() is taking place and when they are both updated to 2M, because of the distance is too far for 2M to support, the devices would disconnect after a short interval, say between 1 to 5 seconds? Shoudl this be the expected observation?

I've inherited the code base from a contractor and is still understanding it. Advertising code is shown below.

CBleAdvertiser::CBleAdvertiser()
{
	memset(&m_AdvData, 0, sizeof(m_AdvData));
    memset(&m_AdvParams, 0, sizeof(m_AdvParams));

	m_AdvParams.p_peer_addr     = NULL;    // Undirected advertisement.
    m_AdvParams.filter_policy   = BLE_GAP_ADV_FP_ANY;
    m_AdvParams.duration        = 0;       // Never time out.
	m_AdvParams.primary_phy 	= BLE_GAP_PHY_1MBPS;
	m_AdvParams.secondary_phy 	= BLE_GAP_PHY_1MBPS;

    m_AdvData.name_type = BLE_ADVDATA_FULL_NAME;
    m_AdvData.flags = BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE;
}

void CBleAdvertiser::SetPhyMode(AdvMode_t _mode)
{
	m_AdvMode = _mode;
	switch (m_AdvMode) {
		case ADV_1MBPS:
			m_AdvParams.primary_phy 	= BLE_GAP_PHY_1MBPS;
			m_AdvParams.secondary_phy 	= BLE_GAP_PHY_1MBPS;
			break;
		case ADV_2MBPS:
			m_AdvParams.primary_phy 	= BLE_GAP_PHY_2MBPS;
			m_AdvParams.secondary_phy 	= BLE_GAP_PHY_2MBPS;
			break;
		case ADV_CODED:
			m_AdvParams.primary_phy 	= BLE_GAP_PHY_CODED;
			m_AdvParams.secondary_phy 	= BLE_GAP_PHY_CODED;
			break;
		default:
			m_AdvParams.primary_phy 	= BLE_GAP_PHY_1MBPS;
			m_AdvParams.secondary_phy 	= BLE_GAP_PHY_1MBPS;
			break;
	}

	if (m_AdvParams.properties.type == BLE_GAP_ADV_TYPE_EXTENDED_CONNECTABLE_NONSCANNABLE_UNDIRECTED
		|| m_AdvParams.properties.type == BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED)
	{  // Connectable
		EnableConnectableAdvertisement(true);
	}
	else
	{  // NonConnectable
		EnableConnectableAdvertisement(false);
	}
}

void CBleAdvertiser::EnableConnectableAdvertisement(bool _enable)
{
	if (m_AdvMode == ADV_CODED)
	{
		m_AdvParams.properties.type = _enable ? BLE_GAP_ADV_TYPE_EXTENDED_CONNECTABLE_NONSCANNABLE_UNDIRECTED : BLE_GAP_ADV_TYPE_EXTENDED_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;
	} 
	else 
	{
		m_AdvParams.properties.type = _enable ? BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED : BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED;
	}
}

void CBleAdvertiser::SetAdvertisementInterval(uint32_t _interval)
{
	m_AdvParams.interval = MSEC_TO_UNITS(_interval, UNIT_0_625_MS);
}

bool CBleAdvertiser::SetDeviceName(const char * _device_name)
{
	ble_gap_conn_sec_mode_t sec_mode;
	BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);
    	
	uint32_t err_code = sd_ble_gap_device_name_set(&sec_mode, (const uint8_t *)_device_name, strlen(_device_name));
	APP_ERROR_CHECK(err_code);
    
	return err_code == NRF_SUCCESS;
}

void CBleAdvertiser::SetCompanyId(uint16_t _company_id)
{
	m_ManufData.company_identifier = _company_id;	
}


CBleAdvertiser::Me().SetPhyMode(CBleAdvertiser::ADV_CODED);
CBleAdvertiser::Me().EnableConnectableAdvertisement(true);
CBleAdvertiser::Me().SetAdvertisementInterval(300);
CBleAdvertiser::Me().SetDeviceName(BLE_MESH_NODE_NAME);
CBleAdvertiser::Me().SetCompanyId(0xFFFE);



bool CBleAdvertiser::Configure()
{
	static uint8_t enc_advdata[BLE_GAP_ADV_SET_DATA_SIZE_MAX];  // Buffer for storing an encoded advertising set.
	static ble_gap_adv_data_t adv_data =
	{
	    .adv_data =
	    {
	        .p_data = enc_advdata,
	        .len    = BLE_GAP_ADV_SET_DATA_SIZE_MAX
	    },
	    .scan_rsp_data =
	    {
	        .p_data = NULL,
	        .len    = 0
	    }
	};

    if(m_AdvParams.interval == 0)
	{
    	m_AdvParams.interval = MSEC_TO_UNITS(100, UNIT_0_625_MS);
	}

	uint32_t err_code = ble_advdata_encode((const ble_advdata_t *)&m_AdvData, adv_data.adv_data.p_data, &adv_data.adv_data.len);
    APP_ERROR_CHECK(err_code);

    err_code = sd_ble_gap_adv_set_configure(&m_Handle, &adv_data, &m_AdvParams);

    if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_INVALID_STATE) && (err_code != BLE_ERROR_INVALID_ADV_HANDLE))
    {
        APP_ERROR_CHECK(err_code);
    }

    return true;
}

bool CBleAdvertiser::StartAdvertisement()
{
    ret_code_t err_code = sd_ble_gap_adv_start(m_Handle, APP_BLE_CONN_CFG_TAG);
    if(err_code != NRF_SUCCESS)
    {
    	LOG("Error start adv %u", err_code);
    }
	return ( err_code == NRF_SUCCESS );
}



void UpdateAdvPacket()
{
	CBleAdvertiser::Me().StopAdvertisement();
	CBleAdvertiser::Me().SetManufacturerData((const void *)&m_AdvManufactureData, sizeof(m_AdvManufactureData));
	CBleAdvertiser::Me().Configure();
	CBleAdvertiser::Me().SetTxPower(CBle::Txp8dBm);
	bool ret = CBleAdvertiser::Me().StartAdvertisement();
	ASSERT(ret);
}

Thank you for the suggestions on triggering the PHY update. I wouldn't have thought about them if you did not mention them!

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

Simonr — Tue, 23 Nov 2021 07:43:58 GMT

What SDK version are you using here? I assume one of the nRF52840 DKs are acting as a central, and the other is advertising and connecting to it, correct? It sounds strange that you don't see a range difference between when connected in Coded PHY and the 2MBPS PHY I must say. Can you show me how you set up Coded PHY advertising in your application?

There is no "automatic" way to switch the PHY when the connection starts having issues, so you'll have to find a way to do a MTU/PHY update at some point. Here are a few suggestions:

You can make the central device check the RSSI (Received Signal Strength Indicator) of the peripheral and when it's under a certain value you can trig a PHY update to switch to the Coded PHY.
If your central device starts losing packets from the peripheral and gets corrupt data, you can make that trig a PHY update to switch to the Coded PHY
Upon a disconnection caused by HCI_CONNECTION_TIMEOUT for example (indicating that the connection timed out due to poor reception or no activity) you can trig a reconnect that sets the connection to Coded PHY.

I don't think there are any error codes caused by a device being out of range, as it would give the same behavior as a device with poor reception or a lot of interference.

Best regards,

Simon

RE: Revert back to Coded PHY connection when 2M is not possible because of distance.

JasonGeo — Mon, 22 Nov 2021 08:41:59 GMT

Also is there a disconnected reason status code (HCI_STATUS_CODE) associated with distance being out of range?