This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RSSI value for the eZ430 Chronos Development Platform

Other Parts Discussed in Thread: SIMPLICITI

I could use some assistance acquiring a valid RSSI reading using the eZ430 Chronos development platform.  I have tried the ReadSingleReg(RSSI) and MRFI_Rssi() functions, however, both return a seemingly random number between 190 and 205 that don’t seem to be correlated with the received signal strength.  I get the same readings whether I am 1 ft away from the RF access point or 100 ft away when the signal is about to drop out.  I have tried both the bluerobin stack (during heartbeat receive mode) and SimpliciTI stack (during sync mode).

 

I realize I need to interpret the value as a 2’s compliment number and correct for a base RSSI offset.  My question isn’t about interpreting the value, its about correctly getting a valid raw RSSI value in the first place.  A value that fluctuates by only 15 counts (out of a possible 256) is of no use, especially when it doesn’t seem to be correlated with the received signal strength.

 

I have seen blog references to the use of RSSI for other MSP430 platforms (e.g. eZ430-RF2500), but none seem like they are appropriate for the eZ430 Chronos platform.  I have also seen other blog references to the fact that the RSSI and LQI values should be added to the end of the receive buffer, however, this doesn’t seem to be happening in my case.

 

Am I using the RSSI functions in the wrong context?  Is the radio system on the eZ430 Chronos platform not properly configured to give valid RSSI readings?  A code snippet specific to the eZ430 Chronos platform would be of great help.

 

Thanks in advance.

  • IIRC, the RSSI value is only valid immediately after receiving a packet and before sending data. But that's just a distant memory from a thread I read long ago.

  • The RF2500 sensor monitor code uses the RSSI values reported in each packet received from an end device. Maybe you could use that value? Just look in the SimpliciTI packet description and pull out the RSSI value from each packet.

    ioctlRadioSiginfo_t sigInfo;

    And from a workshop I attended:

    FCS - Radio appended bytes - CRC checksum (Tx), RSSI, LQI and CRC status (Rx)

    And here is an ioctl call you can try

    • Function description: Performs I/O Control
    • Function call: smplStatus_t SMPL_Ioctl(ioctlObject_t obj, ioctlAction_t act, void *val)
    • Function: 
    – Accesses the I/O Control Interface to the SimpliciTI Stack and the MRFI Layer

    • Arguments Passed: 
    – Object of IOCTL type
    • IOCTL_OBJ_FREQ
    • IOCTL_OBJ_CRYPTKEY
    • IOCTL_OBJ_RAW_IO
    • IOCTL_OBJ_RADIO
    • IOCTL_OBJ_AP_JOIN
    • IOCTL_OBJ_ADDR
    • IOCTL_OBJ_CONNOBJ
    • IOCTL_OBJ_FWVER
    • IOCTL_OBJ_PROTOVER

    – Pointer to a value defined by the object type

    – Action of IOCTL type
    • IOCTL_ACT_SET
    • IOCTL_ACT_GET
    • IOCTL_ACT_READ
    • IOCTL_ACT_WRITE
    • IOCTL_ACT_RADIO_SLEEP
    • IOCTL_ACT_RADIO_AWAKE
    • IOCTL_ACT_RADIO_SIGINFO
    • IOCTL_ACT_RADIO_RSSI
    • IOCTL_ACT_RADIO_RXON
    • IOCTL_ACT_RADIO_RXIDLE
    • IOCTL_ACT_ON
    • IOCTL_ACT_OFF
    • IOCTL_ACT_SCAN
    • IOCTL_ACT_DELETE

    • Argument Returned: smplStatus_t codes
    – SMPL_SUCCESS: Operation successful.
    – SMPL_BAD_PARAM: ioctl object or ioctl action illegal.

    IOCTL_ACT_RADIO_RSSI
    1. rssi_t rssiInfo;
    2. SMPL_Ioctl(IOCTL_OBJ_RADIO, IOCTL_ACT_RSSI, (void *)& rssiInfo)
    3. Get current RSSI value

     

    SMPL_Ioctl(IOCTL_OBJ_RADIO, IOCTL_ACT_RADIO_SIGINFO, (void *)&sigInfo);

    transmitData( i, (signed char)sigInfo.sigInfo.rssi, (char*)msg );

     

**Attention** This is a public forum