RSSI value of SMAC packet

[mircopizzichini]

Hi

I'm using the Radio Utility GUI for MRB-KW0x: Modular Reference Boards for Kinetis KW0x Family of MCUs

Is there a way to read the RSSI value of received packets?

Thank you

[CesarM · Accepted solution]

Hi mircopizzichini,

There are two ways to do this:

1) If you are running packet handler, you can view the RSSI of each packet received by turning on the PacketLog.

This log contains several information about each packet, one of them is RSSI.

To turn on this log (applies only for the Receiver device) refer to chapter "3.2.7 Log Window Control" of

the MKW01 Demonstration Application User's Guide (MKW01DAUG.pdf)

http://cache.freescale.com/files/microcontrollers/doc/user_guide/MKW01DAUG.pdf?fasp=1&WT_TYPE=Users%...

2) You can also view the RSSI on the channel (center frequency as specified in Frf frequency on the common tab) by going to the

Receiver tab and selecting "Receiver" on the Operation Mode window.

You will see the value displayed in the RSSI window under "Value"

Refer to chapter "2.2.3.5 RSSI Display Area" of the MKW01DAUG.pdf

Regards,

César

[mircopizzichini]

Thank you Cesar.

I tried the first way, and it works.

There's only a problem in reading the RSSI value of first received packet.

Looking the firmware, in PacketHandler.c, function PacketHandler_SendUartRxAck(), for the first packet received the RSSI value is overwritten by the payload (row 500-501).

uartMsg[6] = MLMELinkQuality();
FLib_MemCpy(&(uartMsg[6]), gpSmacRxPacket->smacPdu.smacPdu+4,gpSmacRxPacket->u8DataLength);

I think that has to be

FLib_MemCpy(&(uartMsg[7]), gpSmacRxPacket->smacPdu.smacPdu+4,gpSmacRxPacket->u8DataLength);

Let me know if you'll correct it,

thank you

[CesarM]

Hi mircopizzichini,

Thanks for the observation.

You are correct, in addition we need to change the following couple of lines of code as follows:

FLib_MemCpy(&(uartMsg[7]), gpSmacRxPacket->smacPdu.smacPdu+4,gpSmacRxPacket->u8DataLength);

uartMsg[gpSmacRxPacket->u8DataLength + 3] = 0x7F;                                         

uartMsg[gpSmacRxPacket->u8DataLength + 4] = 0x7F;     

Otherwise the last byte of the message would be overwritten by the 0x7F code.

I will update this on the next version of the firmware.

Regards,

César                                

[mircopizzichini]

Hi CesarM, building the firmware for my custom board, code stops in mcg.c,

if (pll_val < 0x100)

   while(1);

because pll_val = 0x11 (in my board source of FLL reference clock is the internal reference clock, so function returns this value).

if I correct

if (pll_val < 0x100)

code is still right?

[CesarM]

Hi mircopizzichini,

The current code for the MKW01 application demos is taking the CLKOUT from the Radio as the source clock for the MCU.

This external clock feeds the MCG and enables the PLL to work in the PEE mode.

Do you intend to not use this CKLOUT from the Radio as your MCU clock source?

If this is correct and you are planning to use the internal clock as the refernce for the MCG... you need to change

the MCG mode to FEI (FLL Engaged Internal)

So the current code where the application calls "MCG_Setup" is no longer necessary as this line configures the MCG as PEE.

What you want to do is:

1) In sysinit.c

- enable the following line:

#define NO_PLL_INIT

This will set the MCG to run from internal reference (FEI mode) @ 48MHZ Sysclk.

2) In main.c

- Platform_Init()

Comment out this line:

/*Initialize clock based on CLKOUT*/

//        MCG_Setup();   

Answering specifically the question about pll_val=0x11:

This is because the IREFST flag in MCG_S Register is set to one indicating that the source of FLL reference clock is the internal reference clock,

instead of an external ref clock that would set this flag to zero as expected by the application demos and thus pll_val would not fall in the 0x11 case.

[mircopizzichini]

Sorry Cesar, your explanation is very clear, as I read from data sheet, but I don't understand one thing.

In my case, I use CKLOUT from the radio, so IREFST is correctly set to one, and pll_init returns 0x11.

But then, since pll_val = 0x11, code stays in the following while(1) and doesn't proceed

if (pll_val < 0x100)
  while(1);

Maybe the if condition has to be changed?

[mircopizzichini]

Now it works, maybe it was a temporary debugging problem... Thanks anyway

[CesarM]

Great!

You're welcome