nRFSDK BLE DTM CARRIER_TEST RADIO->FREQUENCY assignment doesn't make sense?

RE: nRFSDK BLE DTM CARRIER_TEST RADIO->FREQUENCY assignment doesn't make sense?

charles_fi — Wed, 18 Dec 2024 13:58:34 GMT

Ahhhhh thanks, that explains the mystery!

RE: nRFSDK BLE DTM CARRIER_TEST RADIO->FREQUENCY assignment doesn't make sense?

Jørgen Holmefjord — Wed, 18 Dec 2024 13:47:58 GMT

Hi Charles,

If you look in the DTM specifications (Bluetooth Core, Volume 6, Part F), this reference to the channel in the same way:

This mean that the channels in DTM does not follow the placement of BLE channels (37-39 placed within other channels), but reference the channels directly in order from 0-39, where channel 0 is 2402MHz and channel 39 is 2480.

Best regards,
Jørgen

RE: nRFSDK BLE DTM CARRIER_TEST RADIO->FREQUENCY assignment doesn't make sense?

charles_fi — Thu, 12 Dec 2024 14:43:35 GMT

Hi Jørgen-

Thanks for pointing me in the right direction! I am testing BLE, but unfortunately I'm still confused by the original nRF5 SDK calculation being done in ble_dtm.c:

NRF_RADIO->FREQUENCY    = (m_phys_ch << 1) + 2;

"m_phys_ch" gets the channel ID from the 16-bit DTM CARRIER_TEST command's "freq" field bits. So, there's no transformation there from what I can see- if "freq" is set to 17, then "m_phys_ch" is set to 17.

Here's the table from your response (linked at Bluetooth Smart and the Nordic's Softdevices - Part 1 GAP Advertising )

The code "(m_phys_ch << 1) + 2" multiplies the channel by 2 and adds 2 to it, so it's equivalent to a math formula "f(x) = 2x + 2". Let's try it with some values from this table:

f(4)  = (2 *  4) + 2 = 10 -> 2410MHz, but ch4 is at 2412MHz.
f(36) = (2 * 36) + 2 = 72 -> 2472MHz, but ch36 is at 2478MHz.
f(17) = (2 * 17) + 2 = 36 -> 2436MHz, but ch17 is at 2440MHz.
f(0)  = (2 *  0) + 2 =  2 -> 2402MHz, but ch0 is at 2404MHz.

So, all of these calculations seem wrong by 2-6MHz in the BLE spectrum as well, depending on which "side" of the channel 38 spectrum they're on.

I don't think it's possible to accurately map a channel to a specific frequency using a simple "bias and scale" approach because the advertising channel indices make the range discontinuous. Wouldn't you need something like this instead?

int freq(int ch) {
	switch (ch) {
	  case 37: return 2;  // ch37 = 2402MHz
	  case 38: return 26; // ch38 = 2426MHz
	  case 39: return 80; // ch39 = 2480MHz
	  default: break;
	}

    // ch0 starts at 2404, so bias by 4.
    // 2MHz between channel centers, so multiply by 2.
    // An additional 2MHz gap accounts for ch37 if ch > 10
	return 4 + (ch * 2) + ((ch > 10) * 2);
}

Best,

Charles

RE: nRFSDK BLE DTM CARRIER_TEST RADIO->FREQUENCY assignment doesn't make sense?

Jørgen Holmefjord — Thu, 12 Dec 2024 12:57:53 GMT

Hi,

[quote user=""]And describes the legal values for it in this table:[/quote]

This table lists channels supported when using the radio IEEE 802.15.4 mode. IEEE 802.15.4 mode is not used for Bluetooth Low Energy, but are used for other protocols like Thread and Zigbee.

The Bluetooth Low Energy specifications defines 40 channels (0-39) located from 2402 MHz to 2480 MHz, 2 MHz apart (see figure in this blog post).

Direct Test Mode is defined in the Bluetooth Core specifications and is only intended for testing/verifying Bluetooth Low Energy operations.

If you intend to use IEEE 802.15.4 mode with another protocol (Thread/Zigbee or proprietary), you can use the Radio Test firmware (nRF Connect SDK / nRF5 SDK), which allows you to set radio mode (data_rate) and correct channels (start_channel) for both BLE and IEEE 802.15.4 mode.

Best regards,
Jørgen