search

contiki-os / contiki

The official git repository for Contiki, the open source OS for the Internet of Things
http://www.contiki-os.org/
Other
3.71k stars 2.58k forks source link

cc2650 rssi measurement #1341

Closed schuschu closed 7 years ago

schuschu commented 8 years ago

There seems to be an issue with the get_rssi command in IEEE mode.

In particular, when I read the RSSI noise (i.e., in absence of packet transmissions) the first time, the module returns a value around -101 dBm, which is reasonable.

However, if the same command is repeated afterwards, for example if I include the NETSTACK_RADIO.get_value(RADIO_PARAM_RSSI, ...) command in a broadcast callback, the returned value is always -128 dBm.

It seems the issue can be corrected by adding a short delay before the rf_core_send_cmd. I tested the script below and it seems to correct the issue.

... memset(&cmd, 0x00, sizeof(cmd)); cmd.commandNo = CMD_GET_RSSI; rssi = RF_CMD_CCA_REQ_RSSI_UNKNOWN;

clock_delay_usec(500); <-----

if(rf_core_send_cmd((uint32_t)&cmd, &cmd_status) == RF_CORE_CMD_OK) { ...

bkozak-scanimetrics commented 8 years ago

First, a few things to note:

  1. RF_CMD_CCA_REQ_RSSI_UNKNOWN == -128
  2. The RF_CMD_CCA_REQ_RSSI_UNKNOWN is meant to signify an invalid reading. See the CC26xx TRM for details.
  3. When the get_cca_info() function (which works in a similar way to get_rssi()) sees RF_CMD_CCA_REQ_RSSI_UNKNOWN it simply tries the command again.

As for the delay you added fixing the problem, in my own testing I've found that RSSI (and CCA) readings will often fail (and return -128) or otherwise give an incorrect reading (but not return -128) if you call them too soon after the radio turns on. With ContikiMAC, I think that there tends to be enough delay that this doesn't cause too may issues.

Could this be what you are seeing?

g-oikonomou commented 8 years ago

The RSSI reading is available a number of symbol periods after entering RX, not immediately. Traditionally TI chips have had a bit in some register that one could inspect to determine whether the RSSI reading is valid. This is e.g. RSSISTAT.RSSI_VALID for the CC2538.

Unfortunately for CC13xx, CC26xx we don't have access to a register of this nature so what we can do is send CMD_GET_RSSI repeatedly until we get a valid reading.

I'm flagging this as a bug.

g-oikonomou commented 8 years ago

Also applies to the prop mode driver. Should be fixed in #1348, please let me know if you come across further problems.