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

[charles_fi]

nRF5280, nRFSDK 17.0.1, SoftDevice 7.2.0

The nRF52840 data sheet describes the RADIO->FREQUENCY register this way:

And describes the legal values for it in this table:

But then the ble_dtm.c file has this code:

I don't see unmodulated carrier waves where I expect, and I do not understand how the equation "(m_phys_ch << 1) + 2" turns a channel number into a RADIO->FREQUENCY value correctly.

For example, let's take channel 24, which should be centered at 2470MHz. Clearly, the value "70" should be written to the RADIO->FREQUENCY register. But evaluating the equation "(24 << 1) + 2" gives us the result of "50", which is incorrect. Indeed, my spectrum analyzer shows me waves centered around incorrect MHz spectra when I use the SDK ble_dtm.c code.

I rewrote the code as:

and indeed now I get carrier waves centered around the channel frequency that I expect (e.g. ch24 does give me a wave at 2470MHz, and ch11 does give me a wave at 2405MHz).

Please confirm that this is a bug in the nRF SDK, or help me understand where I went wrong.

Thanks,

Charles

[Jørgen Holmefjord]

Hi,

And describes the legal values for it in this table:

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

[charles_fi]

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

[Jørgen Holmefjord]

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

[charles_fi]

Ahhhhh thanks, that explains the mystery!