EmbeddedRelated.com
Forums
Memfault Beyond the Launch

I have problem extracting the RSSI value. Could anyone give me a hint about how you achieved it.The IDE I use is IAR in C language.The following are pictures of my problems.

The problem is that the RSSI value(before offset) shown on the realterm is weird. RSSI value is -20 (small) while there is no bit errors(within a very short distance, under 0.5m)(picture1).And RSSI value is 95(big) while there are 41 bit errors(within a long distance, about 20m)(picture2). I think the correct outcome should be opposite, -20 should be the outcome within a long distance and 95 should be within a short distance. It’s weird even after I offset them -20 become -65,95 become 50.

1_67318.png

                                                            picture1

----------------------------------------------------------------------------------------------------------------------------------------

2_92504.png

                                                            picture2

*********************************************************************************************************************

The following are the pictures of my programming:
According to IEEE 802.15.4 Fame Formate Mac Layer,RSSI is the 1st byte of the FCS(Mac Footer)

mpdu_24453.jpg

8777_97732.jpg

----------------------------------------------------------------------------------------------------------------------------------------

// In basic_rf_receive_packet.c,use "FASTSPI_READ_FIFO_NO_WAIT" to put FCS data into footer

FASTSPI_READ_FIFO_NO_WAIT((BYTE*) pFooter, 2);

888_28266.jpg

// hal.h defines FASTSPI_READ_FIFO_NO_WAIT(p,c)

hal_93243.jpg

#define FASTSPI_READ_FIFO_NO_WAIT(p,c)\

do {\

  SPI_ENABLE();\

  FASTSPI_RX_ADDR(CC2420_RXFIFO);\

  U0RXBUF;\

  for (spiCnt = 0; spiCnt < (c); spiCnt++) {\

FASTSPI_RX(((BYTE*)(p))[spiCnt]);\

  }\

  halWait(1);\

  SPI_DISABLE();\

} while (0)

----------------------------------------------------------------------------------------------------------------------------------------

//In the define of  FASTSPI_READ_FIFO_NO_WAIT(p,c),there are " FASTSPI_RX" & "FASTSPI_RX_ADDR"


#define FASTSPI_RX(x)\

    do {\

SPI_TxREADY();\

U0TXBUF = 0;\

SPI_WAITFOREOTx();\

SPI_WAITFOREORx();\

x = U0RXBUF;\

    } while(0)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

#define FASTSPI_RX_ADDR(a)\

do {\

SPI_TxREADY();\

U0TXBUF = (a) | 0x40;\

SPI_WAITFOREOTx();\

} while (0)

*********************************************************************************************************************

The following puts pFooter[0] into "rssi" variable which we set

----------------------------------------------------------------------------------------------------------------------------------------

In basic_rf_receive_packet.c, 

//set variable    

BYTE pFooter[2];

21_52250.jpg

----------------------------------------------------------------------------------------------------------------------------------------

// RSSI is in pFooter[0],so put pFooter[0] into the RSSI

rfSettings.pRxInfo->rssi = pFooter[0];

5_80014.png

//rssi structure

RSSI is in BASIC_RF_RX_INFO structure

// The receive struct:

typedef struct {

    BYTE seqNumber;

WORD srcAddr;

WORD srcPanId;

INT8 length;

    BYTE *pPayload;

BOOL ackRequest;

INT8 rssi;

} BASIC_RF_RX_INFO;


3_84842.png

----------------------------------------------------------------------------------------------------------------------------------------

pRxInfo is pointer to BASIC_RF_RX_INFO in rfSettings

// The RF settings structure:

typedef struct {

    BASIC_RF_RX_INFO *pRxInfo;

    UINT8 txSeqNumber;

    volatile BOOL ackReceived;

    WORD panId;

    WORD myAddr;

    BOOL receiveOn;

} BASIC_RF_SETTINGS;

extern volatile BASIC_RF_SETTINGS rfSettings;


7_99739.png









[ - ]
Reply by mr_banditJanuary 18, 2019

This is not my area of expertise. But - some basic googling finds that the RSSI maps to dB and the higher the negative number (dB) the better. The closer you are, the better the signal. Farther, the worst. So your 95 with a lot of bit errors make sense, although not sure why you have a positive number. The other thing the various websites say is the RSSI number is vendor-specific. I would suggest looking at the Taroko documentation on thteir interpretation of the RSSI number.

example site: https://www.sonicwall.com/en-us/support/knowledge-...

another: https://www.speedguide.net/faq/how-does-rssi-dbm-r...

Memfault Beyond the Launch