RSSI values for zigbee cc2520

Hi,

How exactly do you print these values?

typedef struct

{
osal_event_hdr_t hdr; /* OSAL Message header */
uint16 groupId; /* Message's group ID - 0 if not set */
uint16 clusterId; /* Message's cluster ID */
afAddrType_t srcAddr; /* Source Address, if endpoint is STUBAPS_INTER_PAN_EP,
it's an InterPAN message */
uint16 macDestAddr; /* MAC header destination short address */
uint8 endPoint; /* destination endpoint */
uint8 wasBroadcast; /* TRUE if network destination was a broadcast address */
uint8 LinkQuality; /* The link quality of the received data frame */
uint8 correlation; /* The raw correlation value of the received data frame */
int8 rssi; /* The received RF power in units dBm */
uint8 SecurityUse; /* deprecated */
uint32 timestamp; /* receipt timestamp from MAC */
uint8 nwkSeqNum; /* network header frame sequence number */
afMSGCommandFormat_t cmd; /* Application Data */
} afIncomingMSGPacket_t;

In the AF file of Zstack.

Now Here is the display by Real term:

Do you have an option to debug what the other side (cc2520) sends to the serial port?

It seems to me like some sort of overflowing on the cc2520 side when you sending this number to the serial port

Well This is my device, which side do you mean ? at the moment I am using the uart pins section (in image).

I am using sampleApp and in SampleApp code, I configure the uart port then I give HALUARTWRITE commands.
first to send ID.
then RSSI value.
then LQI value.
so all are in order in my realterm output:

ID RSSI LQI all three in order.
Each is one character long.
So I am not able to understand how can it be overflowing ?

Can you also tell me something more about int8 rssi value which I extract from received packet Is it the final rssi value or some changes needs to be done to get the actual RSSI in Dbm ??

Also in this document http://www.ti.com/lit/an/swra114d/swra114d.pdf

It says that we can convert the RSSI Register value, Is the rssi int8 variable and RSSI register value in the image are same ?.. shall I convert my int8 rssi value according to what is shown in the image ?

The rssi part is my biggest confusion.

Do you have an option of debugging the FW running on MSP?

In case you have such an option, you could trace whether the wrong RSSI values are transferred from cc2520 to MSP, or the wrong values are transmitted from MSP to the serial on your PC.

Sir,

First I was wondering that I could know that whether the RSSI values we extract from the received pkt are in Dbm or not. I mean in the AF.h file it is written that the rssi value extracted are in Dbm ?

So normally those are final values or they need to be converted ?

Can't tell you right away, since i'm not familiar with the code that extracting this RSSI value.

From my previous experience the RSSI values are in dBm

Sir,

Please can you tag someone who has tried this things.
I will be really thankful.

Anyway the code is a sampleApp.c

And in the SampleApp_Messagecallback funtion I write the part to extract RSSI.

void SampleApp_MessageMSGCB( afIncomingMSGPacket_t *pkt )

{

unsigned char* Recv_RSSI = (unsigned char*)pkt->rssi;
HalUARTWrite ( HAL_UART_PORT_0, Recv_RSSI, 1 );

}

Regards 
Sumit

Hi Sumit,

HalUARTWrite only display strings. Recv_RSSI is a int8 and can't be correctly display.

Sir,

Now I am getting more confused.

I convert the int8 variable to unsinged char type.
Then I send the value charater wise, one character at a time.
Then at the real term I again real the bits and try to display it in int8 format.

1. Is the method to extract pkt->rssi is correct ? and give correct rssi values in Dbm?
2. If 1. is true, does that means My method to use HALUARTWRITE and display it on realterm is wrong ?
3. If 2. is wrong, then how would I send my rssi data to the uart port of ZigBee ? as I need to connect it to some other board.

Thanks 
Please reply.

Sir,

I think HALUartWrite just write the 8 bits to the tx pin doesn't it ? whether it is char or int8 8 bits will always be same 

and then I can get those 8 bits displayed in any format I want in the real term ?

Thanks

Nice to hear it working well finally. It looks good.