Skip to content

Conversation

jia200x
Copy link
Member

@jia200x jia200x commented Jul 31, 2020

Contribution description

This PR fixes the offset for the RSSI calculation of CC2538 radios and removes an RFCORE_ASSERT that checks that the internal RSSI value is greater than the sensitivity.

The latter produced crashes while testing #14655 when measured values of RSSI were below the RX sensitivity (-97 dBm).

Also according to the Reference Manual, section 23.10.3, the actual power of the reception is calculated with the RSSI register and the RSSI offset (-73).

Testing procedure

Check the RSSI values when receiving data.

Issues/PRs references

Fixes the crash in #14655

@jia200x jia200x requested review from maribu and PeterKietzmann July 31, 2020 15:02
@jia200x jia200x requested review from fjmolinas and smlng as code owners July 31, 2020 15:02
@PeterKietzmann PeterKietzmann added Area: drivers Area: Device drivers Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) labels Jul 31, 2020
@maribu
Copy link
Member

maribu commented Jul 31, 2020

Also according to the Reference Manual, section 23.10.3, the actual power of the reception is calculated with the RSSI register and the RSSI offset (-73).

In that section no offset is given, it says "For example, with an offset of 73 [...]". It also says "See the datasheet for the correct offset value to use."...

To me, it is not clear what the correct value now actually is.

@PeterKietzmann
Copy link
Member

The datasheet (Sect. 5.12 RSSI/CCA Characteristics) gives an RSSI/CCA offset of 73dBm and the formula to calculate RealRSSI= Registervalue– offset. We do that here using CC2538_RSSI_OFFSET (=-73dBm) already. ACK from my side

@PeterKietzmann PeterKietzmann added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Aug 2, 2020
@PeterKietzmann
Copy link
Member

How can RFCORE_ASSERT crash the program (in #14655)? Unfortunately it is not documented, but to me is seems to enable a debug massage and return the function with an error, nothing more than that (see here and here). Regardless of that, removal of the assertion seems valid to me.

I ran some tests using examples/default on an nrf52840dk and a remote-reva locally.

  • txtsend nrf52840dk -> remote-reva (sending with 0dBm).
  • change txpower on nrf52840dk to -20dBm.
  • txtsend nrf52840dk -> remote-reva (repeatedly).

master

  • remote-reva receives packets with RSSI of 21 (@ 0dBm sending)
PKTDUMP: data received:
~~ SNIP  0 - size:   5 byte, type: NETTYPE_UNDEF (0)
00000000  68  65  6C  6C  6F
~~ SNIP  1 - size:  18 byte, type: NETTYPE_NETIF (-1)
if_pid: 3  rssi: 21  lqi: 233
flags: 0x0
src_l2addr: 1B:A5
dst_l2addr: 00:12:4B:00:06:15:A0:04
~~ PKT    -  2 snips, total size:  23 byte
  • remote-reva receives packets with RSSI of -1 (@ -20dBm sending) and prints assertion
RFCORE_ASSERT(rssi_val > CC2538_RF_SENSITIVITY) failed at line 353 in _recv()!
  RFCORE_SFR_RFERRF = 0x00
PKTDUMP: data received:
~~ SNIP  0 - size:   5 byte, type: NETTYPE_UNDEF (0)
00000000  68  65  6C  6C  6F
~~ SNIP  1 - size:  18 byte, type: NETTYPE_NETIF (-1)
if_pid: 3  rssi: -1  lqi: 233
flags: 0x0
src_l2addr: 1B:A5
dst_l2addr: 00:12:4B:00:06:15:A0:04
~~ PKT    -  2 snips, total size:  23 byte

this PR

  • remote-reva receives packets with RSSI of -75 (@ 0dBm sending)
    -> much more reasonable range!
PKTDUMP: data received:
~~ SNIP  0 - size:   5 byte, type: NETTYPE_UNDEF (0)
00000000  68  65  6C  6C  6F
~~ SNIP  1 - size:  18 byte, type: NETTYPE_NETIF (-1)
if_pid: 3  rssi: -75  lqi: 229
flags: 0x0
src_l2addr: 1B:A5
dst_l2addr: 00:12:4B:00:06:15:A0:04
~~ PKT    -  2 snips, total size:  23 byte
  • remote-reva receives packets with RSSI of -97 (@ -20dBm sending) and does not print assertion
PKTDUMP: data received:
~~ SNIP  0 - size:   5 byte, type: NETTYPE_UNDEF (0)
00000000  68  65  6C  6C  6F
~~ SNIP  1 - size:  18 byte, type: NETTYPE_NETIF (-1)
if_pid: 3  rssi: -97  lqi: 229
flags: 0x0
src_l2addr: 1B:A5
dst_l2addr: 00:12:4B:00:06:15:A0:04
~~ PKT    -  2 snips, total size:  23 byte

Copy link
Member

@PeterKietzmann PeterKietzmann left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although I'm not sure this PR fixes the crash in #14655, my ACK holds for this change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: drivers Area: Device drivers CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants