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.

RTOS/CC1310: Longer packets w/ higher BER and receiver behavior dependent on Tx power setting

Part Number: CC1310
Other Parts Discussed in Thread: CC1200

Tool/software: TI-RTOS

I have node1 and node2 where I change transmit power in node2 only with CMD_SET_POWER between max and min. Node1 RSSI confirms the about 20dB change. But, when the  node2 is receiving it reports now 10dB less received power when the transmit power is set to max. We also see that cc1310 receive mode draws different amount of current from the supply depending on the Tx power level setting. Should we expect that received signal quality depends on the tx power setting or is it just a wrong RSSI reading?

Also, we see about 10dB performance difference in BER (calculated from PER) between 30byte and 1kbyte packets. We have had same problem with cc1200 but it was resolved by whitening. This doesn't seem to help with cc1310. Is there any known problems using longer packets?

Thanks

  • Tommi,

    I assume this test is done over the air, then a 10dB delta from one measurement to the next is very likely. If you want to carry out these detailed test you will need to perform them when the boards are connected using coaxial wires with a known loss in the path.

    Also to confirm output power I recommend using Spectrum analyzers.

    Regards,
    /TA
  • Hi,
    All measurements are done cabled. Here is the receiver current consumption depending on what the Tx power setting is:
    -10dBm:10.61mA
    0dBm:10.89mA
    10dBm:13.3mA
    12.5dBm:22.07mA

    Also, the receiver sensitivity is greatly improved by setting the Tx power to the minimum. So, in order to both save battery and get the best sensitivity we change the Tx power level before receiving. Is there a preferred way to do that? We have tried to transmit zero length packet after power change command which does the trick most of the time. But, sometimes it causes M0 to hang.
    Thanks
    Tommi
  • If I understand you setup correctly you have connected the Rx and Tx side directly together with a cable meaning that you get 12.5 dBm at the input of the receiver (+10 dBm at the RF pins is maximum rating). If this is the case the receiver is saturated.

    To test I would recommend using at least 30 dB attenuation between Rx and Tx.
  • We use 50-100dB attenuation. That's how we also see the improvement in the receiver sensitivity after lowering the Tx power setting.

  • You wrote: "I have node1 and node2 where I change transmit power in node2 only with CMD_SET_POWER between max and min. Node1 RSSI confirms the about 20dB change. But, when the node2 is receiving it reports now 10dB less received power when the transmit power is set to max."

    So Node 2 Tx, node 1 Rx you see a 20 dB difference in RSSI when changing Tx power
    So when node 2 is receiving, have you set node 1 Tx, node 2 Rx (static) or do you send an ack? The link should be symmetrical given equal settings on both sides.
  • If I have node 1 transmitting at constant power level then I can manipulate the sensitivity, reported RSSI and power consumption of the receiving node 2 just by using CMD_SET_POWER in node 2. Node 2 does not need to transmit anything for this to happen. 

    The power consumption saving when receiving is that significant that we are setting the transmit power to the minimum after transmitting. That is why we are curious what would be the preferred method of lowering the Tx power? Or, maybe the observed behavior is completely avoidable by some other means?

    Thanks

  • I want to try to recreate this on my side.

    Is it possible for you to post a minimal project that shows what you see on a Launchpad? The CMD_SET_POWER should not have any impact in Rx.

    Do you see the same if you first program (without CMD_SET_POWER, just setting txPower static) node 2 with 12.5 dBm, do the test and then test with the lowest txPower? In other words is it CMD_SET_POWER that cause the issue?
  • Adding myself to this thread