This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

RSSI meter wildly ineffective

The nRF 52840 RSSI "meter" is not usable.

I tested in an RF (2.4Ghz) quiet neighborhood. Using a reference receiver, I measured RSSI variance around +/-3 dB (95% confidence interval) from each of 5 transmitters; this is in line with expectation. Noise was below -99 at all times during the 1 hour test. I positioned a nRF 52840 20 cm away from the reference measurement station. The Nordic RSSI values did not exhibit a Gaussian noise curve at all, but instead reported three strong modes at -79, -65, and -58; each with incredibly small tails. Binning the results according to proximity to these modes revealed a variance of 0.2 dB (95%), which is more precise than noise will allow. From this evidence I gather three important facts: a more distant node can have a higher RSSI, the RSSI cannot be averaged to reduce "noise" as the values are nonlinear and modal, and therefore there is no way to estimate relative signal strength from the relative signal strength indicator. I used 5 transmitters during this test and observed similar behavior from each, both reasonable values from my reference receiver and unreasonable values from the Nordic chip. RSSI does not work as intended. Please document this behavior, consider disabling the API for this part, and further document which nRF parts actually work.

Please tell me what part I have to replace in my next board design to achieve usable RSSI?

  • Hi again Cody, 

    I got the response from our stack team, quoted here: 

    There is no such option to retrieve channel of a given advertising report. It is also not possible to scan on a given set of channels. 
    There are plans to give the functionalities on our softdevice into NCS but we don't have the timeline for the features you are requesting yet. 
  • Hello ,

    Thank you for your response.

    Both of those options are correct, on a Thingy91/nRF Connect based platform we are using the nRF52840 in BLE HCI mode where we are scanning for devices, we are curious if we can perform the following:
    1) For a scan result, determine what channel it was discovered on (37,38,39)
    2) Configure the scanner to scan only on a specific channel (ie. 39)

    In the mean time please let us know how do you measure RSSI? by using the rssi value in the call back bt_le_scan_cb_t ? 

    - Correct

    I was doing some research of my own yesterday and came across this thread, https://devzone.nordicsemi.com/f/nordic-q-a/69099/ncs-bt_le_scan_start-api-is-limited-to-report-phy-and-adv-detail, where  points out that you can register a callback using the function, bt_le_scan_cb_register in order to receive a struct with significantly more information than using the following callback type in conjunction with bt_le_scan_start in zephyr/include/bluetooth/bluetooth.h:

    bt_le_scan_cb_t(const bt_addr_le_t *addr, s8_t rssi, u8_t adv_type, struct net_buf_simple *buf)

    The struct received with the callback passed in to bt_le_scan_cb_register has the following form:
    /** LE advertisement packet information */
    struct bt_le_scan_recv_info {
    	/** @brief Advertiser LE address and type.
    	 *
    	 *  If advertiser is anonymous then this address will be
    	 *  @ref BT_ADDR_LE_ANY.
    	 */
    	const bt_addr_le_t *addr;
    
    	/** Advertising Set Identifier. */
    	u8_t sid;
    
    	/** Strength of advertiser signal. */
    	s8_t rssi;
    
    	/** Transmit power of the advertiser. */
    	s8_t tx_power;
    
    	/** Advertising packet type. */
    	u8_t adv_type;
    
    	/** Advertising packet properties. */
    	u16_t adv_props;
    
    	/** Primary advertising channel PHY. */
    	u8_t primary_phy;
    
    	/** Secondary advertising channel PHY. */
    	u8_t secondary_phy;
    };


    This struct contains primary phy channel and secondary phy channel, is there something I am missing here?

    Update: Took some time to implement this and it looks like the primary_phy field is always reporting a "1".
  • Hi Cody, 

    primary_phy and secondary_phy are the info about the modulation on the PHY layer. So it can be either 1Mbps, 2Mbps, CODED PHY 125kbps or CODED PHY 500kbps. It's not related to the 3 advertising channels that we are discussing here. 

  • Bummer, so it sounds like this is only possible in the nRF5 SDK and not the nRF Connect SDK?

  • Correct, unfortunately it's not supported on nRF Connect right now. Limiting your advertising packet to one channel is currently the only option. Another option is to handle the scanning directly from the radio. We do that on our nRF5 for Mesh SDK. 

Related