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.

CC2592: CC2640R2F+CC2592,Our signal effect is the same as if I don’t have a PA

Part Number: CC2592
Other Parts Discussed in Thread: CC2640R2F, CC2541, CC2640, CC2650

We are using CC2640R2F and CC2592,But we ran into trouble and we have been debugging for a month。

CC2592 is already working,But the Bluetooth signal is very difficult。

The distance test results with CC2592 and without CC2592 are the same, but the signal is stronger, but the communication distance is not farther.

Our company is in Shenzhen, China, and hope to get technical support from TI.

And we are willing to provide paid technical support。

How can I contact your company’s technical support?

Description:

1.https://www.ti.com.cn/cn/lit/df/tidriz6/tidriz6.pdf?ts=1615909613188&ref_url=https%253A%252F%252Fwww.ti.com.cn%252Ftool%252Fcn%252FTIDC-CC2650-CC2592-EMK

We design according to this schematic

2.https://www.ti.com.cn/cn/lit/ug/tidub71/tidub71.pdf?ts=1615909691837&ref_url=https%253A%252F%252Fwww.ti.com.cn%252Ftool%252Fcn%252FTIDC-CC2650-CC2592-EMK

We set the GPIO according to this document,Added the following code(GPIO has been set to correspond to IO ):

IOCPortConfigureSet(IOID_2, IOC_PORT_RFC_GPO0, IOC_IOMODE_NORMAL);

IOCPortConfigureSet(IOID_3, IOC_PORT_RFC_GPO1, IOC_IOMODE_NORMAL);

3.Are there any other settings?

  • We use the google pixel mobile phone to test, and the connection is disconnected at 50m,The CC2541+rfx2401C we used before can reach 100m.

  • Hi,

    Thanks for the question.

    I have passed this on to the HW experts for their insight.

    Regards,
    Toby

  • Hello,

    For the code you've provided above, I assume you're using DIO2 for LNA enable and DIO3 for PA enable in place of DIO13 for LNA enable and DIO7 for PA enable as specified in the EMK Test Report you've linked. You may also want to use a DIO to control the HGM pin on the CC2592.

    I don't know any other settings that are needed, but any conducted measurements you can take of the board's output power would be helpful. How much conducted output power do you see when the amplifier is turned off vs turned on? Pictures of measurements taken with a spectrum analyzer would be ideal, and any layout/schematic pictures would be helpful too.

  • We have seen in other posts that they have modified two files, one is the header file: ble_user_config.h Added the following code:

    #define TX_POWER_22_1_DBM 22

    #define TX_POWER_21_6_DBM 21

    #define TX_POWER_21_3_DBM 20

    #define TX_POWER_19_7_DBM 19

    #define TX_POWER_17_5_DBM 17

    #define TX_POWER_15_1_DBM 15

    #define TX_POWER_12_4_DBM 12

    #define TX_POWER_10_2_DBM 10

    The other is the source file "ble_user_config.c"Add the following code:

    { TX_POWER_10_2_DBM, GEN_TX_POWER_VAL( 0x0B, 3, 0x0C ) }, //output 10.2 dbm on CC2592
    { TX_POWER_12_4_DBM, GEN_TX_POWER_VAL( 0x0B, 1, 0x14 ) }, //output 12.4 dbm on CC2592
    { TX_POWER_15_1_DBM, GEN_TX_POWER_VAL( 0x0E, 1, 0x19 ) }, //output 15.1 dbm on CC2592
    { TX_POWER_17_5_DBM, GEN_TX_POWER_VAL( 0x12, 1, 0x1D ) }, //output 17.5 dbm on CC2592
    { TX_POWER_19_7_DBM, GEN_TX_POWER_VAL( 0x18, 1, 0x25 ) }, //output 19.7 dbm on CC2592
    { TX_POWER_21_3_DBM, GEN_TX_POWER_VAL( 0x21, 1, 0x31 ) }, //output 21.3 dbm on CC2592
    { TX_POWER_21_6_DBM, GEN_TX_POWER_VAL( 0x14, 0, 0x42 ) }, //output 21.6 dbm on CC2592
    { TX_POWER_22_1_DBM, GEN_TX_POWER_VAL( 0x18, 0, 0x4E ) } //output 22.1 dbm on CC2592

    Are these necessary?

  • We have found relevant testing institutions to test in the microwave anechoic chamber, and also tested the antenna matching. Standing wave ratio, return loss, first harmonic, second harmonic, antenna efficiency. The test results look very good. But when we did the long-distance communication test, the situation was very unsatisfactory. The PCBA with CC2592 was even worse than the PCBA without CC2592.

    Later, a professional testing organization told us that there might be a problem with the PA/LNA control sequence, but our code was written with reference to the design of the official website. I don't know where else the code needs to be modified.
    If possible, we would like to get technical support from TI in Shenzhen. We are willing to pay a certain fee to support this work and help us solve the problem.
  • In addition, CC2592 has a BIAS, we adjusted its BIAS resistance and found that there will be some improvement.Don't know how to debug it

  • Maybe try to use SmartRF Studio to adjust register to fine tune the performance.

  • Which registers should I adjust? Is there any adjustment method?

  • Hi all,

    I'm surprised and disappointed that you had good antenna matching but poor long distance performance. I think it would be a good idea to measure the conducted output power on the board to verify that the CC2592 device is not working right. Conducted performance is much easier test and replicate than radiated performance, and if your CC2592 isn't working right, it will be much easier to diagnose if we can see how much power it conducts out.

    As for the bias resistor - I would highly recommend following the reference design as closely as possible to minimize the chance of unexpected behavior. Here is the schematic. If you think there's a problem with the PA/LNA control sequence, make sure you're using DIO2 for LNA enable and DIO3 for PA enable, and that those pins are connected correctly.

    I am asking internally about the register configuration, but I think you have it correct.

    I will ask internally if we can get you more hands-on support.

    Best,

    Nate

  • Confirmation for the txpower table:

    It would be fine to use either the values you have or those listed in the app note you listed because both are verified by TI (either in the app note or in the E2E posts you're referring to). You'll notice that the app note only has a single byte for the txpower value. This should be the first byte in the 2-byte txpower field because it refers to gain control and internal bias. 

    You can use other txpower values, but we cannot guarantee performance if you choose to use those that are not verified by TI.

  • Thank you nathan block. Today I tried to disable the LNA signal and PA signal output separately to verify that my LNA signal and PA signal configuration are correct. After testing, the signals of disabling LNA and PA are very weak. Explain that my previous configuration is correct.
    We found that under normal configuration conditions, the distance that the link is disconnected or unable to connect can still receive the Bluetooth broadcast signal, which is about -76dbm, but it cannot be connected. When we do not add PA, -85dbm can still be connected, so I have reason to suspect that there is a problem with the LNA, but I don’t know where the problem is.

  • Hi Shannon, that sounds like a sensitivity issue, but again, I can't really comment effectively on your setup without proper information. The first step to debugging this will be to measure the conducted power out of the CC2640-CC2592 system when it's acting as a transmitter. Once we can verify it's transmitting correctly, I'd also measure the noise level when the device is acting as a receiver so we can verify that the sensitivity is correct. If you don't yet have access to the appropriate tools, I'd at least verify that you're sending the right control signals to the CC2592 as shown in section 9 of the datasheet.

  • I have seen the control signals of PA and LNA with an oscilloscope, and they are normal. If I disconnect the signal, the PA/LNA will not work, and the signal in the 0.5m range will also be -85dbm~-97dbm. When the PA and LNA are connected, the mobile phone is close to the antenna, and the signal value of 10bdm can be seen, even within 0.5m. There is still -26dbm.I think there should be no problem。
    During the distance test, we found that when the connection is disconnected, the broadcast signal can still be received, and it is around -75dbm.
    If there is no external PA, the CC2640R2F will also be disconnected at this time, close to -95dbm.
    In summary, I can verify that the PA works, but I am not sure whether there is a problem with the LNA.
    In addition, today I saw such a description on manual, "23.3.2.8 External Signaling
    The radio CPU controls four CPEGPOx signals that can be used for external signalling, for example for
    controlling external PAs and LNAs or debugging. CPEGPO0 is high when the internal LNA is enabled,
    CPEGPO1 is high when the internal PA is enabled and CPEGPO2 is high when synthesizer calibration is
    ongoing.
    Two of the output signals from the RAT have automatic configuration that may be used for observation.
    The signal RATGPO0 goes high when transmission of a packet is initiated and low when transmission is
    done. RATGPO0 may be observed for accurate timing of packet transmission, because the same signal is
    used internally. RATGPO0 is very similar to CPEGPO1, but it goes high some microseconds earlier, and
    the timing is more accurate compared to the first transmitted symbol out of the modem.
    By default, the radio CPU maps CPEGPO0 to the signal RFC_GPO0, CPEGPO1 to the signal
    RFC_GPO1, CPEGPO2 to the signal RFC_GPO2, and RATGPO0 to the signal RFC_GPO3 at boot time.
    This mapping can be modified by writing to the RFC_DBELL:SYSGPOCTL register.
    The RFC_GPOx signals can be mapped to output pins using the system I/O controller. Refer to
    Chapter 11 for details.
    NOTE: On the CC2640R2F device, the CPEGPO1 signal does not deassert when the internal PA is
    disabled. To control external PAs RATGPO0 must be used instead."
    The signal of RATGPO0 is linked to RFC_GPO, but I don't know how to implement it. In RF.h, I found a macro definition covering the RF register. It has the following description:
    // Map RatGpo3 to one of four intermediate doorbell signals.
    // This has to be done in the override list in order to take permanent effect.
    // The override list can be found in the RF settings .c file exported from
    // SmartRF Studio.
    // Attention: This will change the default mapping of the PA and LNA signal as well.
    #include <ti/devices/[DEVICE_FAMILY]/inc/hw_rfc_dbell.h>
    static uint32_t pOverrides[] =
    {
    HW_REG_OVERRIDE(0x1110, RFC_DBELL_SYSGPOCTL_GPOCTL2_RATGPO3),
    // ...
    }
    I found this register coverage table in the Bluetooth configuration file. And added "HW_REG_OVERRIDE(0x1110, RFC_DBELL_SYSGPOCTL_GPOCTL0_RATGPO0)," After reprogramming, the signal transmission power becomes very poor, but the sensitivity is very high. Shouldn't this set the PA control signal, and why is this address "0x1110"?
  • Hi Shannon,

    The behavior you're describing sounds like distortion on the output of the amplifier. Can you post pictures of your schematic/layout? As well as any antenna matching or other measurements taken?

    Good job verifying the PA! I worry though that you've verified that the PA is able to broadcast power, but the signal its outputting may still be distorted. I still think you need to take conducted measurements on your board to verify that your signal power and sensitivity are correct. This document here is our official guide to debugging issues like you're seeing, and you'll see that we highly recommend taking conducted measurements before trying anything radiated. The behavior you're describing will be significantly easier to debug with conducted measurements because it will be much more repeatable, easier to see on equipment because the power levels will be higher, and won't see interference from the environment.

    That being said, if you don't have access to the tools needed to do conducted measurements properly, this is how I would try to debug your issue without them to rule out a hardware issue:

    For my own understanding, it sounds like you're using the device as a transmitter and the smartphone as a receiver, is that correct?

    As well, if I understand your issue correctly, your smartphone is able to decode packets sent by the CC2640 without the CC2592 correctly until about -95 dBm, but when you attach the CC2592, you can only able to decode packets while the RSSI is above -75 dBm. Is that correct?

    Before we modify the register level code, let's first just verify that it's not a hardware issue. These devices are meant to work pretty seamlessly, which is why I'd be surprised if the issue is internal to the CC2640 (but not impossible). Can you use SmartRF studio to broadcast packets with your devices. This software has been thoroughly tested, and if the issue still presents itself while using SmartRF Studio, then I would be very confident it is a hardware issue.

    Download the software and connect your device to your computer. Run SmartRF Studio, and broadcast a some packets. You may need to change the first byte of the txpower register, which you can do by clicking the area circled in the picture.

    Use a second launchpad running SmartRF Studio in receive mode to verify that the packets can be sent and the RSSI value is what you think it is. See if your receiver sensitivity is still worse when you have the CC2592.

  • Hi Nathan, I know that whether it is linking or broadcasting, it is actually a two-way communication process. I just described the RSSI to show that this CC2640R2F+CC2592 is easy to disconnect at a very high RSSI (greater than -75dbm). If there is only no CC2592, the connection will be disconnected at a very low RSSI (about -95dbm). Does this mean that the power of the PA is sufficient, but the LNA may have problems causing the RX to be unable to receive the signal, that is, it is difficult to establish two-way communication, and this is how it will disconnect.

    Then I use two devices, one as a transmitter and one as a receiver. Then to verify whether there will be packet loss in the case of long distance?
    The broadcast method may not necessarily be able to verify this problem.
    When the RSSI of CC2640R2F+CC2592 is less than -75dbm, the mobile phone can search for its broadcast data, but cannot connect. When it is greater than -75dbm, it can be connected.
    If I use one of my equipment as a transmitter and use SmartRF Studio to operate the equipment broadcast, it should still be the same, but I will give it a try.

  • Maybe the network is restricted, and I don’t see the function of uploading files or pictures, and I can’t upload my test report.

  • HI Shannon,

    You may have the click the text that says upload. It's not immediately obvious but that's the link to open the file explorer.  

  • As for your test setup:

    First off - thank you for clarifying your procedure.

    I don't think we can necessarily say it's the LNA not the PA based off the behavior you're describing. Do you know which device communication is halting on? e.g. does the phone transmit to the CC2592-CC2640 and the CC2592-CC2640 doesn't receive it? Or does the CC2592-CC2640 transmit to the phone and the phone doesn't receive it? If it's the first scenario, I would think that the board's sensitivity is the issue. If it's the second scenario, I would think that the board may be broadcasting out a faulty signal. It's hard to point directly to the root cause without knowing the exact error scenario, which SmartRF is really good at doing.

  • I don’t have "upload" here. I found a new problem. In the CC2640R2F datasheet, RF Core Data Out 2 is "Synthesizer calibration running", but the custom target configuration of SmartRF Studio shows that RF Core Data Out 2 is "Tx start" .It is impossible to determine which one is right, is it a fault in SmartRF Studio or a fault in the datasheet?

  • I have prepared three products:
    A: CC2640R2F+CC2592  (20dbm)
    B: CC2640R2F+CC2592  (20dbm)
    C: CC2640R2F                  (5dbm)
    The first set of experiments: When I use A as Tx and B as Rx on SmartRF Studio about -77dbm, I couldn't receive any signal from A at all. This does not explain the problem of LNA.
    The second set of experiments: So I used A as Tx and C as Rx, and the signal from A was not received at about -90dbm. The comparison of the above two groups should be able to show that there is a problem with the A/B LNA.
    The third set of experiments: A is used as Rx, C is used as Tx, and A will not receive the signal from C at about -75dbm.
    In the above three sets of experiments, I think the LNA of CC2592 has a big problem, as for the PA, there may also be minor problems.

  • This is fantastic data Shannon, thank you for your clarity. 

    I think the issue is more likely to be your PCB's sensitivity than the LNA inside the amplifier. In the test report for the CC2592-CC2650 combination, I see that the board they created was able to achieve a sensitivity of -98.7 for 1-Mbps GFSK (Bluetooth Low Energy). Can you check to see how your board differs in the schematic and layout, which are available below on the same page? Some likely culprits include antenna design, grounding, placement of noisy components near the antenna and poor antenna matching. You can also post your schematic/layout files here for us to look at too.

    You can also measure your board's sensitivity by hand. Based off the results you're giving me, I would be willing to bet that the ambient noise floor of you CC2640-CC2592 device is higher that it should be. If you connect the antenna leads on your board to a spectrum analyzer with a pigtail and put the device in RX mode, the power you measure on the spectrum analyzer is the device's noise floor. If your device's noise floor is above approx. -100 dBm, there's no way a -100 dBm signal can be accurately decoded.

  • My PCB is a double-layer board, so I might be that its performance is not as good as that of a 4-layer board, so my RF performance is relatively poor.

    Can you provide the original PCB file of CC2650+CC2592? I hope to copy it completely. Although there is a pdf document, it is difficult to control it to be exactly the same.

  • Of course. These files are also listed on the reference design under design files. Here's a link regardless.