Advertising in CODED PHY using primary channels only

RE: Advertising in CODED PHY using primary channels only

Yves Oesch — Tue, 23 Jan 2024 13:55:24 GMT

Hi Hung,

thanks a lot for all the explanations. It is now clear to me. I could run the examples radio_test, radio/transmitter and radio/receiver. They provide valuable information. For me you can close this ticket.

RE: Advertising in CODED PHY using primary channels only

Hung Bui — Wed, 17 Jan 2024 13:37:40 GMT

Hi Yves,
I assume you have control over both sides of the connection. You may want to consider using proprietary instead of BLE in that case. For example you can use the radio test example with with 125kbps LE modulation (Ble_LR125Kbit mode) .You will need to enable USE_MORE_RADIO_MODES.

If you want to stick with BLE advertising, and want to do it in bare metal, I think it's possible. A few years back I did some test to run BLE mesh (which use BLE ADV in bare metal) in CODED PHY. You can take a look here:

RE: change phy in mesh
They are very old code. You may want to extract the code from the exact SDK used in the ticket.

RE: Advertising in CODED PHY using primary channels only

Yves Oesch — Wed, 17 Jan 2024 13:10:29 GMT

Hi Hung,

Thanks a lot for your answer. Indeed it confirms what I was about to conclude and feared: It's not possible to focus on CODED PHY only for simple advertising.

I don't need a real compatibility with BLE for the application I am developing. I only need to transmit very few bytes. Indeed what I need is a repetitive broadcast transmission (similar to an advertisement) using as few energy as possible, but I'd like to profit from the extended range offered by the 125 kbps CODED PHY. So I don't need all the bells and whistles of a full BLE stack. Extended advertisement looks like a waste of power for my simple case.

Now I wonder if there is any "bare metal" possibility to use the nRF52840 (or later to be ported on nRF52811) , i.e without the limitations of the SD140 or Zephyr. Any idea, pointer, literature or example how to use Nordic's nRF52 radio chips with a lower level API?

RE: Advertising in CODED PHY using primary channels only

Hung Bui — Wed, 17 Jan 2024 10:39:18 GMT

Hi Yves,

I think the GBard which is based on Gemini AI may have some miss information and may need some upgrade.

We have no plan to support the feature as it's not allowed by the spec.

Here is the response from my ChatGPT 4 to the question of "Does Nordic softdevice support advertising in CODED PHY using classic advertising?"

If you're referring to using CODED PHY with the classic advertising scheme (i.e., the original BLE advertising method), this might be constrained by the BLE specification and the capabilities of the SoftDevice. It's more common to use CODED PHY with extended advertising due to the enhancements in Bluetooth 5.0 and later versions.

For the most accurate and current information, I recommend consulting the latest Nordic Semiconductor documentation for the specific SoftDevice version you are interested in, or contacting their technical support. Nordic regularly updates their SoftDevice with new features and capabilities, so they would provide the most reliable information on what is currently supported.

I did a follow up question about how it's constrained in the Bluetooth spec and got these info:

Primary Advertisement Channels and PHYs: In Bluetooth 5.0, advertising on the primary channels (channels 37, 38, and 39) can be done using different advertising packets (PDUs). However, for the legacy advertisement PDUs, they can only be sent on the original LE 1M PHY. The only primary advertisement PDU that can be sent on a PHY other than the 1M PHY is the ADV_EXT_IND, which is an extended advertisement indicator. This means that for classic advertising, which uses the primary advertisement channels, the use of Coded PHY is limited to extended advertisements only.

I think it's a proper answer. It's not allowed by the Bluetooth spec to do classic advertising in CODED PHY as you can find at page 2690 (v5.4) here:

ADV_IND can only be used in LE 1M not LE CODED.
Note that ADV_EXT_IND can be sent in both LE1M and LE CODED , but the ADV_EXT_IND doesn't include any data, it only the indication that there will be follow up packets in the data channel (extended advertising).