• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 54 subscribers
  • Views 267 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1352P7: simple peripheral tx power is not stable

Renfang zhou
Prodigy 70 points
Part Number: CC1352P7

hi:

in the simple peripheral example, there are two advertising sets, one is legacy, and another is extended with coded PHY. here is some tx power problem.

when I set default tx power 0, and use analysis equipment to measure the transmission power, it has a large gap between the highest and lowest power. as measured, the power gap can reach 10 dbm.

at first, the two different advertising sets are suspected to the cause of this issue, but when I shut down one of the advertising sets, this problem is still existed.

then, I try to demonstrate whether it is a hardware problem, I use the smart radio rf to control the launchpad transmit packets with fixed power, and the measured result illustrates the hardware is ok. 

according to the description above, it seems this example has some tx power instability issue. can you find the primary casue.

thanks!

  • 0
    TI__Genius 10305 points

    Hi,

    To help us debug this issue, please could you:

    • Describe your test setup
    • Provide scope shots of your measurements
    • Is this custom hardware or a TI LaunchPad?

    Regards,

    Zack

  • 0 in reply to ZC
    Prodigy 70 points

    Hi, zack:

    test setup

    1. seting default tx power 0, and use analysis equipment to measure the transmission power(advertising power), to suppress the interference, the signal is transmitted through cable. it has a large gap between the highest and lowest power. as measured, the power gap can reach 10 dBm. the measure scope is ( -29) - (-30)dbm

    2. the two different advertising sets are suspected to be the cause of this issue, but when I shut down one of the advertising sets, this problem still exists.

    please refer to the scope shots of the measurements,  focus on the power(dBm) item, the path loss is 30 dBm.

    all the experiments are conducted on the launchpad.

    BR

  • 0 in reply to Renfang zhou
    Prodigy 70 points

    sorry that the measurements video was not uploaded in the last reply, please check it here.

  • 0 in reply to Renfang zhou
    TI__Mastermind 29560 points

    Hi,

    Have you performed a static unmodulated Tx test with a spectrum analyzer to determine if there are power variations against time ?

    This sounds more like a measuring sync issue when measuring the output power levels during advertising mode. 

  • 0 in reply to RGW
    Prodigy 70 points

    Hi RGW，

    As mentioned in the question description, the power output is stable when the launchpad was controlled by smartRf radio. So, in my opinion, this issue has nothing with hardware, it should be the application self-problem.

    best wish.

    Renfang

  • 0 in reply to Renfang zhou
    TI__Mastermind 29560 points

    Hi,

    Have you altered your trigger / sync when measuring the output power levels during advertising mode on your instrument ?

    Regards,

       Richard 

  • 0 in reply to RGW
    Prodigy 70 points

    Hi RGW,

    I am really sorry that the cause of this issue is instrument measurement mistaken. according to our analysis, the instrument only can measure the power accurate if the ble packet is not whitened, so it shows right result when ble is in PTM mode but can't be applied to the whitened ble packet.

    as the ble specific Core 5.2 illustrated, all the le packets show be whitened to randomize the data from highly redundant patterns and to minimize DC bias in the packet.  what's the reason that the packet in PTM mode is not whitened. I have a conjecture, the reason is the packet payload(please see the attached picture for details), the ptm mode is employed to check the hardware design, so the packet should be the original other than whitened.

  • 0 in reply to Renfang zhou
    TI__Mastermind 29560 points

    Hi,

    Great that the output power variation in the measurement is identified. Need to ask a colleague to check why the packet in PTM mode is not whitened.

  • +1 in reply to RGW
    TI__Mastermind 25810 points

    Hey Renfang,

    Renfang zhou said:
    I have a conjecture, the reason is the packet payload(please see the attached picture for details), the ptm mode is employed to check the hardware design, so the packet should be the original other than whitened.

    This is correct. If you, for example, are running a HCI_EXT_ModemTestTxCmd, this will transmit a carrier wave which is not whitened. This is usually used to test the RF PHY settings. When trying to capture a modemTestTx command, you'll have to use the HCI_EXT_ModemTestRxCmd command to receive this (because it is not whitened).

  • 0 in reply to Ammar N
    Prodigy 70 points

    Hi, Ammar

    thanks for your confirmation and specific explanation. it gives me a much deeper appreciation.

    BR.

    Ren-fang Zhou