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.

CC1352P: Seeing packet loss with good RSSI, low noise floor

Part Number: CC1352P

Hello,

I am running a PER test between our device and a Launchpad.  Our device is the TX and the Launchpad is the RX.  The distance between the devices is about 110m in a field.  The PHY setting is the standard 20dBm, 200kbps PHY from the preset list in SmartRF Studio, on channel 902.4MHz.

  1. The RF signal strength is pretty good.  The Launchpad reports an average RSSI of -70.8dBm during the test.  This is close to our estimates of what the signal strength should be at this distance.
  2. The noise floor is pretty low.  The Launchpad measures an average RSSI of -98dBm at this location on this channel and same RX BW setting (when our transmitting device is turned off).  There are no notable spikes in the noise floor, it's just pretty low and flat vs. time.
  3. The PER and BER are higher than I expected.  Packet length is 76 bytes, PER is 74.5%, BER is 0.23%.  Total # of packets received was around 50,000.  I was sending a continuous stream of packets so the PER is probably even worse, since I can't account for extra packets that were completely lost vs. ones marked as "Received Not OK".

I suspect the BER should be lower than I'm seeing in these conditions with what seems like pretty strong SNR (27dB).  Do you agree, and do you have any suggestions of possible debug methods?

Thanks,

Arthur

  • I would have expected PER close to 0 % (no loss) based on the description. Are you sure about the PER and BER numbers you have measured, I would have expeted a high PER and a high BER and the other way around.

    What I would try is:

    - Different location (same distance between RX and TX)

    - DIfferent time (see if you see a difference based on the time you do the test)

    - Try different channels

    - You can also try shorter packets to see how this impacts.

    I would suspec that you have some noise that causes bit errors.

  • Hi TI,

    This is Wilson working on the same platform

    May I know for far distance communication limit on 50kbps data rate, as we measured the noise floor could not be that low as the conducted sensitivity level around -109dBm, which means SNR may be <0dB?

    Thanks!

    Br, Wilson

  • Sensitivity is measured conducted and in an environment with a minimum of external noise. In the field, radio noise will be on the air. This noise will both be location and time dependent. Some locations will have more noise, urban environment will have more noise than in the middle of nowhere. The noise will also increase if something is sending etc. 

  • Hi TER,

    Understanding you are saying the noise of SNR as Arthur's mentioning point. But it would be good to know how low the SNR that for 50kbps and 200kbps can receive the packet successfully regardless of audio application concern (latency)

    Normal communication receiver system would consider below, and TI would know the Minimum Eb/No or C/N requirement

    • Determine Eb/No for desired BER = 0.1% (only for example if PER of about 58% at a BER of 0.1% based on the formula PER=(1-(1-BER)^n))
    • Convert Eb/No to C/N at the receiver using the bit rate and bandwidth of interest
    • Add the path loss and fading margins (different location and obstructions of the communication path)

    Thanks,

    Wilson Chen

  • The required SNR for 50 and 200 kBps is about 7. 

  • Hello Arthur,

    my opinion, 0,23% BER is a really bad value at your reporoted RSSI, escpecially if you use (G)FSK or even OOK (two state modulation schmemes->should have high noise imunity).

    The problem might be caused by an (narrow band) interferer / intererence and not by gaussian white noise. White noise should enter in the picture when we near to the sensstivity level.

    BER, PER, BLER formulas are valid in presence of white noise only. Because, wihite noise governed by the nature and not a man-made phenomenon. White noise can be controlled relative easily by filters, transmission speed etc due to its flat spectrum, noise power depends on the bandwidth (of sensing Network): Pn=k*T*B. white noise insatenteous amplitude has Gaussian distribution: mean=0 (no DC content), power is the variance (square of std deviation=sigma, std dev corresponds to RMS voltage: within RMS values the 63% of amplitude (samples), amplitudes > RMS are even rare, if detection thershold >6*sigma->no erronous bit detection (below 1ppm)).

    If antenna can be detached you may apply wired link between the parts (be careful: do not overdrive receiver input- 20..30dB attenuator pad recommended and minimum TX level) to exlude a possible interferer.

    Other remarks:

    - maybe distorted baseband signal the rootcause : when too narrow band (IF) filter used and after reshaping demodulated signal, timming problem can occur (similary when you pass UART/RS232 transmission trough a slow optocpupler)
    - check frequency offset, crystal circuitry and AFC: the IF signal is not at the centre of bandpass filter, check PLL settings at TX, RX side
    - on board EMC issue pls check grounding and CPU interface. It is worth to use ferrite beads on data line.
    - Is supply voltage clean? Enough low impedance (properly bypassed)? You may switch it by the CPU. Pls check wheter MOSFET can enough open when ON (enough small Vgsth and Rdson)

    Joseph

  • Thank you TER for the answer to my SNR question

    We doubt using TI EVK to detect environment receive noise floor is limited use for reference during our test in the field

    Q1: Since from the path loss equation:  = 2010 + 1010 + − 28, whereas Lfn number might not be easy to involve the multi-path environment (multi-reflections) so as the RSSI could be widely ranging for the receiver, at different test duration/time, right?

    Q2: There are coarse two kinds of noise for sensitivity noise floor or NF, one is AWGN @ 900MHz at environment measured by TI EVK that is accountable while the other is human made LTE eNodeB band 8 (925~960MHz) that cannot be directly taken account into

    Correct me if wrong.

    Thanks,

    Wilson Chen

  • For some reason the equation did not show as wanted, correct again for Q1 equation:

    Path loss (dB) = 20* LOG (f) + 10n *LOG(d) + Lfn − 28; Lfn is a factor varying with the environment of the channel

  • Hi Wilson,

    The white noise can come in to the picture even enough above the sensitivity level (calculated for given Bps) in this case:

    the FSK demodulator (I assume this is the modulation scheme) cannot develop enough output signal swing (which is the function of FM signal frequency deviaton - its gain expressed in [V/kHz] ) resulting the detected signal just exceeds the data comparator threshold but leaving no enough margin-> noise can influence the data recovery.

    -> Thus the frequency deviation setting may be improper at the TX side.

    Joseph

  • Q1: The environment will be both place and time dependent meaning that you can get different results if you test the exact same place at different times. We did some tests this summer and we saw that the noise floor changed at least 10 dB from one day to another. 

    Q2: LTE is one known noise source. But at some locations it's a lot of RF devices that generate background noise. This doesn't have to be a signal that uses the same channel that you are operating on. Since all devices have phase noise energy could be bleeding into the used channel. It's a lot of radio traffic out there meaning that some bands are crowded and hence the noisefloor increases. 

  • Hi Joseph,

    Understood your point of noise easy to be across over the threshold of data comparator.

    However may we know TX side frequency deviation or RX side received signal frequency deviation accounts more on this topic, or both? 

    Since there was a E2E: e2e.ti.com/.../932507.

      To me it seems concluded that slight offset <60ppm would not make big RF performance impact, or you think that is for good SNR operation condition only instead of environment noise up and down disturbance?

    Thanks!

    Wilson Chen

  • Hi TER,

    Q1: It did surprise me that you also got >10dB variation at your site only different time, and even there is no Band 8 interference. So in the larger distance cases with possible fast fading become prominent to our application of the device wear-on-body, how is the height importance to receive the signals coming from the (multiple) reflections on the ground when there is few to none obstacle in the line-of-sight case? Should we pay high attention to receive those reflected signals on the ground that can be demodulated by the 2-GFSK receiver, .let say the antenna pattern reception range?

    Q2: Understood. We did inspect that random small piece of noise pulsated like at the noise floor

    Thank you.

  • Hi Wilson,

    unfortuantely, I could not open the link.

    I just wanted to point that certain other issues may act like a broadband noise limited fundamental case.

    At 900MHz the 60ppm does cause 54KHz offset, its maginitude similar to FSK frequency deviation. I think without compensation / AFC is can degrade the performance.

    Joseph

  • I believe a 10 dB variation is to be expected since other radio sources turn on/ off. In an urban environment reflections from buildings etc will also impact on the result, I have seen in a different test that increasing the distance with 1 -2 m gave a lot better PER. But in your case I'm not sure that you are actually seeing reflections, it could just be noise that has time variation. 

  • Hello all,

    I have not yet been able to use a spectrum analyzer to confirm that my Launchpad and my own device are tuned to low frequency ppm error.  This could be a possible explanation for my packet errors (despite having good SNR) if I have some crystal cap loading configured wrong.

    Wilson did get a measurement that two of our own devices can transmit and receive to each other with low packet loss rates at 300m, which is what we expected.  This is the key test that really matters to us, though it would also still be good to get the Launchpad to work well, in case we need to do a comparison.

    Thanks,

    Arthur