LAUNCHXL-CC2650: RSSI not measured

When you test this with your signal generator, is it a conductive test? If you use another LAUNCHXL-CC2650 as TX to do PER test, can you see RSSI varied?

Hi Pascal,

Are you intentionally broadcasting zeros out from your signal generator? Below is what my screen looks like when I do the test YiKai is suggesting (2 launchpads communicating with one another over the air, both connected to SmartRF studio windows). Notice that the data format is 

time | packet number | packet payload | RSSI

Your screenshot makes me think this is greater than just the RSSI because your packet numbers and payloads are all zeros as well.

Can you replicate this too?

Hello Nathan, Yikai,

I have one launchpad and I'm using an RF equipment (EXM from Keysight in non connected mode) configured as a generator.

The test is done in radiated mode, I don't have the right cable (UFL) to perform a conducted test.

RSSI test is OK when I disabled the whitening function on smart studio.

During the PER and BER test, i have many CRC errors and overflow messages. I tried to change the configuration of the waveform (packet) and to increase the idle interval but it doesn't change the result. I tried to change the polling period on smart studio but overflow messages and CRC messages are still here.

Please find the screenshots below (smart studio & packet configuration for the EXM)

thanks in advance for your support,

Pascal

Hi Pascal,

Are you sure you're broadcasting on the right channel? You have a channel index of 0 in your Keysight window which corresponds to 2404 MHz if I'm not mistaken, but your receiver is set to 2440 MHz (channel 17). Is that accurate?

HI Nathan,

This channel index is defined in Packet Parameter Setup, it doesn't affect the frequency of the generator. The frequency of the generator is defined with an another setting in the generator. If the frequency of the generator was not ok, it will be not possible to measure the RSSI and the RSSI is OK but not the FER and PER (CRC).

But I change the channel index to the correct value the issue is still present on the PER, FER... So no progress.

For your information ,when I used only the EXM by creating a loopback between the generator and the receiver of this same equipment, the frame is recognized. So it seems to come from the configuration of the launchpad CC2650. Do you have any other proposition ?

Hi Pascal,

Thank you for the clarification. I'm going to check with a colleague about what parameters to consider in your setup, but I'm not so sure your RSSI is correct. Many of your packets have RSSI's in the 60's and the 100's from the screenshot, which is definitely an unreasonable measurement. An RSSI of 30 dBm is extremely high, especially considering you're doing a radiated measurement, not a conducted. Each packet's RSSI should be relatively the same under normal circumstances, and unless you have a very strong generator placed very close to your device, they should be below 5 dBm at least. Is your screenshot indicative of the behavior you're still seeing?

Hello Nathan,

You are right -30 dBm is high for a receiver but I tried before lower level -55 dBm for example and it doesn't change the CRC error, PER or BER. So I let -55 dBm (see the screen shot below)

Regarding your remarks about the time between tow packets, please see the screenshot of the EXM below You'll see that the idle interval between two packets is equal to 1s. It seems that the board can't demodulate the signal when the EXM is capable to demodulate it, please see the message on the EXM screenshot: Paket Type: LE 1M ref, PAYLOAD. PRBS9. Please see below the configuration of the waveform done with signal studio. The fail "F" message on the EXM screenshot is not important (only due to the low level received).

For your information, note that with the EXM (see the screenshot below) the channel index 19 (instead of 17) corresponds to 2.440GHz.

Hi Pascal,

Perhaps I misunderstand, but from the SmartRF screenshot you're showing, the board was able to demodulate the signal without error. You're saying the board can't demodulate when there's 1 second of idle time between packets. Is the SmartRF screen of that  not shown in this post?

Nathan,

The screenshot above shows when the whitening is disable on smartstudio to measure the RSSI (no BER and PER measurement is done in this case)

To measure the PER and BER, I need to enable the whitening function on smartstudio but the PER and BER test results and the CRC are not good (see the screenshot below). So the packets are not well demodulated. I tried a lot of configuration but no progress.

Is it clear for you?

Sorry, there is a misunderstanding! I'm sorry Nathan, it ok now. I don't need to enable whitening function. it ok BER and PER are ok!!!

When I decrease the level of the generator to -93 dbm, the PER and BER is around 24.8%. so it's OK!

thank you for your support!!!!