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.

eZ430-rf2500 How to? Calculate LQI

Other Parts Discussed in Thread: CC2500

xxxx.Lqi[i] = packet.rxMetrics[MRFI_RX_METRICS_CRC_LQI_OFS];

Is it right to use this as LQI? I'm getting very low numbers by using this, ranging from 4 to 6 at 50cm.
If its wrong, then what is the way to calculate it out?


Another matter altogether,  what is the range of LQI for the CC2500. Please indicate which end(more or less) is good or bad

Thx in advance. 

  • Lqi = packet->rxMetrics[MRFI_RX_METRICS_CRC_LQI_OFS] & MRFI_RX_METRICS_LQI_MASK;

    I included the mask but the results are the same. Anyone can tell me what I'm doing wrong? 
    Best LQI should be 110. 

  • The LQI value is determined by a similar method as the PQT (preamble quality threshold) discussed in section 17.2 of the CC2500 spec sheet.  The LQI value is representative of the value in the LQI register when the last byte of the message was received.  If your message contains long runs of similar bits (i.e. transmitting many zeros in a row), then the LQI value will be decreased.

    The whole point of the LQI value is to indicate the ease with which the radio is capable of demodulating the signal.  There are several factors which can influence this.

    1. Data Rate - Higher data rates require less time between bits thus requiring the bandwidth of the receiver to be higher which in turn allows in more noise which results in increased probability of detecting a bit in error.
    2. Modulation Settings - Usually settings which affect the error vector magnitude results will have the most effect here.  For example, if you are using an FSK modulation and the frequency deviation is small, it will make it more difficult for the demodulator to detect changes in the state of the received bit stream, i.e. the signal is noisier so the probability of bit detection failure increases.  If using ASK modulation and the amplitude deviation is small, similar issues exist.
    3. Receiver Bandwidth Settings Invalid - If the receiver bandwidth settings are aggressive the effective time to integrate per bit is reduced thus causing similar issues as too high a data rate.
    4. PLL Gain - If the PLL gain is too high, you can introduce jitter into the system especially for long runs of similar bit values.  If the gain is too low, you may not detect the preamble correctly and miss the sync mark entirely.  If the latter is the case, you can increase the length of the preamble to compensate.
    5. RSSI - Received Signal Strength Indicator - If this value is low the probability of a bit being received in error will increase.  This can be caused by the deployed environment also.  Local nulls due to standing RF waves in space can reduce RSSI.  Depending on the amount of reflected RF in the vicinity of the receiver, you can lose as much as 40dB quite easily.  Moving either the transmitter or receiver by as little as 5cm at 2.4GHz can reveal such an issue.  Also simply waving your hands around in the vicinity can cause the local nulls to move around (talk about the magic of RF and waving of hands...).

    Remember, the LQI value appended to the end of the packet is representative of the value after receiving the last byte.  If you really want a fairly good indication of what the demodulator is capable of given your current radio setup, always set the last two bytes in your packet to values witch will encode into alternating ones and zeros.  This will allow you to have a measure of demodulation which is comparing apples to apples.  From here you can determine any encoding issues with pathological packet payload data sets.

    Jim Noxon