CC1352P: sensitivity optimized when carrier frequency is not aligned

Hi Tal,

In your designs, do you use:

1. external crystal load capacitors on the 48 MHz crystal ? or

2. internal crystal load capacitors ?

Recommend to perform a static unmodulated carrier at 868.3 MHz and measure the frequency offset in kHz.

If you are using external load capacitors and also using the internal load capacitors; then this can cause an incorrect load on the crystal which can cause a frequency offset.

Regards,

   Richard

Richard, hi.

We are using an external 10ppm crystal oscillator with external capacitors, the cap-array state is on.

We are calibrating the carrier frequency with an unmodulated signal. The cap-array mode will only change the carrier frequency calibration value (we have tested that).

No matter the cap-array state (on or off), after calibrating the carrier frequencies (by unmodulated signal) we found that the sensitivity is optimized only when F_TX - F_RX ~= 4kHz; which is very odd hence I need assistance investigating this issue.

HI,

For the P devices, it is recommended to use external loading capacitors for the 48 MHz. 

Then you should not use the internal capacitors at all. 

Can you measure the RF unmodulated Tx carrier and let us know the frequency offset in kHz ?

Please provide a screen dump of the signal analyzer if possible.

What is the part number of the crystal ?

RGW: It would not surprise me if the measurements are correct, I have seen the same on the old transceivers with given settings. It should be relatively fast and test PER vs level vs freq for this phy and see if you get the same in the test system.  

Hi,

Please see screenshots for unmodulated with array-cap on and off before and after calibration, as requested.

cap-array on calibration value is -8000

cap-array off calibration value is 36700

48MHz crystal is NX2016SA-48M-EXS00A-CS05517, datasheet is attached.

cap array off before calibration

cap array off after calibration

cap array on before calibration

cap array on after calibration

crystal datasheet

NX2016SA-48M-EXS00A-CS05517_Spec.pdf

Hi,

Let's just look at the two plots with the cap array off since this is the state which should be used since you have external load caps.

The first screen shot shows an initial frequency offset of about -37 kHz which correlates to -42.6 ppm error. This is outside the crystal specification of +/- 10 ppm at 25C. I presume this measurement has been performed in rooms temp.

What are the values of your crystal load caps ? We normally use 7.5 pF on either side of the crystal. Even without calibration at rooms temp, this frequency offset should not exceed +/- 10 ppm i.e. +/- 9 kHz

Hi,

I agree, this is why we stayed with the cap-array on, I've tried a wide range of capacitors (2pF to 12pF), with several cap-array values when cap-array is on, and a different crystal oscillator (EPSON OUT-20-5440), without success to reach the 10ppm.

currently, we are using 7.5pF [picture 1 - schematics].

Pictures 2 to 3 are the PCB layout relevant layers. and Picture 5 is a 3D representation of the area.

please note :
A) the phenomena occur with and without cap-array.
B) I can tune the carrier.
C) I can reproduce the large PPM drift on the CC1352P1 Development board.
D) Same phenomena with different crystal oscillators and multiple values of capacitors.
E) Same phenomena with different layouts (5 layouts).
F) Same phenomena with different ASICs CC1352P and CC1352P7.

Taking into account A, to F I think the cap-array mode is not relevant to the subject's phenomenon.
Taking into account C to F I think the cap-array issue is an ASIC issue and therefore I suspect the ASIC to the subject's phenomenon.


[picture 1 - schematics]

[picture 2 - layout - TOP]

[picture 3 - layout - layer 2]

[picture 4 - layer 3]

[picture 5 - 3D capture]

The frequency offset is measured in production of the LAUNCHXL-CC1352P-1 so how can you be measuring a large frequency offset here ?

I measure the offset by a spectrum-analyzer using an unmodulated signal, for tuning the carrier frequency.

but let us return to the issue.

history of the investigation:
I started to investigate the instability of the sensitivity (-100dBm to -107dBm); after a long investigation of power integrity, crystals PPM, layout, and more, I've found out that the carrier frequency accuracy is the main cause of the instability.

By tuning all the devices to the same carrier frequency I've received a -105dBm stable sensitivity, but I did not receive the -107dBm that was previously observed. After further investigation, I found out that when the transmitter carrier frequency deviation is about 4kHz from the receiver carrier frequency I get 107dBm sensitivity. Hence the phenomenon.


again; the phenomenon is as follows
1. when F_TX - F_RX ~= 0kHz, sensitivity is ~-105dBm
2. when F_TX - F_RX ~= 4kHz, sensitivity is ~-107dBm

and yet, as discussed earlier, the cap-array has no effect on the phenomenon, because I'm tuning the carrier frequency with the software.

The frequency offset is measured in production of the LAUNCHXL-CC1352P-1 so how can you be measuring a large frequency offset here ?

Please see the procedure I've just created to create the offset on the TI CC1352P Development board with and without "Cap-array tunning"

Regarding the below procedure, please note
1. you may switch the order of steps 6 and 8, it doesn't change the final result
2. I reproduced the procedure on more than 2 Development boards with the same result
3. if you return to the "LAUNCHXL-CC1352P1" profile the offset does not occur

Procedure to create an offset on the CC1352P development board.

1. open smartRF studio (in my case 7 2.28.0)

2. select the device and then select "Proprietary mode"

3. choose LAUNCHXL-CC1352P1 to open "Custom Target Configuration"

4. Duplicate the configuration by 
4.a. press "Create Copy As"
4.b. change "Target name" to for example "ttt" (note that the name must not start with "LAUNCHXL")
4.c. press "Save"
4.d. press "Close"

5. Use the new duplicated profile you had just created
5.a. change frequency to 868.3MHz
5.b. change Filter RBW to 195.9kHz
5.c. choose "Continuous TX"
5.d. choose "Unmodulated"

6. Choose "Cap-array Tunning" and "Cap-array Delta" as 0
6.a. Start TX

7. Stop TX

8. change "Cap-array Tunning" to off
8.a. Start TX

Hi,

I'll measure this on a LP and will let you know the results.

Hi,

You do not need to set the DIOs since these will automatically be set when you choose the LAUNCHXL-CC1352P-1.

Cap array should be off.

You mention that " if you return to the "LAUNCHXL-CC1352P1" profile the offset does not occur" ?? We will test this at multiple frequencies and various Rx bandwidths to see if we can see this as well.

Hi,

1. the new profile "ttt" is a duplicate profile of "LAUNCHXL-CC1352P1", I've checked, and the DIOs are configured the same for both profiles.
2. when using "LAUNCHXL-CC1352P1"
2.a cap-array on and value = 0  ==> offset is -51kHz
2.b cap-array on and value = -43  ==> offset is +7kHz
2.c cap-array off ==> offset is +7kHz
3. when using the duplicated profile "ttt"
3.a cap-array on and value = 0  ==> offset is -51kHz
3.b cap-array on and value = -43  ==> offset is +7kHz
3.c cap-array off ==> offset is -51kHz
4. Rx BW does not have any effect on items 2 & 3 

our products behave like item #3

We tried this in the lab measuring a LAUNCHXL-CC1352P1 and the frequency offset is as expected.

i.e. LAUNCHXL-CC1352P1 has crystal load capacitors and with the cap array disabled, we measure the correct frequency offset.

Can you take a picture of your LAUNCHXL-CC1352P1 since this should have external caps on.

One thing we noticed was when you make a custom configuration by duplicating LAUNCHXL-CC1352P1, for some reason the default cap-array  becomes 0 and not the default -43. 

Please see the attached pictures.

1. Dev board in action, please note Cap-array is off and offset is -51kHz

1.1 zipped Dev board in action, for the ability to zoom in by any PC software (cpa-array is off while offset is -51kHz)
PXL_20231116_100306565.zip

2. Dev board TOP

3. Dev Board Bottom

Use LAUNCHXL-CC1352P1 to base your design on. You do not need to change this.

ttt is a duplication of LAUNCHXL-CC1352P1 

Hi Tal,

This is a bug in SmartRF. When you make a custom configuration by copying the LAUCHXL-CC1352P1 configuration, the default cap-array delta becomes 0 while is suppose to be -43.

In your custom configuration, just enable the cap-array tuning, set it to -43, and disable the cap-array tuning again. Then, you will have the same behavior is the item #2. 

Regards,

HG

Hi,

So we are back to square one.

I have tested this in the lab and the behavior of the LaunchPad is as expected.

Your conclusion is incorrect that the cap-array mode is not relevant and this is an ASIC issue. If I change the cap-array mode, I can change the frequency offset of the chip as expected.

We perform PER v Level v Frequency on all PHYs and if we had an offset it would be apparent but this is not the case. Please refer to the datasheet for these plots.

20 dBm output and 14 dBm output power settings showing a frequency offset of 8.3-9.5 kHz offset on a random CC1352P Launchpad controlled via SmartRF studio.

I do agree that when making a copy of the Target Configuration that the copy is not the same as the original LAUNCHXL-CC1352P1 and then a frequency offset error can occur as you are reporting. This is a SmartRF studio bug. Hence, the reason to not make a copy since you do not need to do this when measuring on the LaunchPad. If you measure as shown below, you will not have any problems. It is just when you are making a copy of the Target Configuration, you will see an issue.

Hi,

I was able to reproduce the fault using two TI's development boards.

Results summary:
1. Total path attenuation is ~ 130 dB.
2. The best test result (measured by the number of good packets received) was when the TX board offset from the nominal frequency was from -5kH to -2kHz, while the RX board remained on the nominal frequency. The fault is reproduced!
3. While measuring both board's center frequencies (by unmodulated signal) the center frequency changes while transmitting using the PA (20dBm) from when transmitting not using the PA (14dBm).  Why?

Test Results

Result Chart:
The vertical axis represents the total number of good packets received out of 10000 packets transmitted, while the horizontal axis represents the Tx nominal frequency offsets in kHz regarding the Rx nominal frequency.

Test block diagram:

TESCOM RF chamber TC-5916AU (https://tescomwireless.com/en/manufacture/view/?no=33)
mini-circuit dynamic attenuator RCDAT-4000-120 (https://www.minicircuits.com/WebStore/dashboard.html?model=RCDAT-4000-120)


Tests Notes
a.1 nominal frequencies difference is about -200Hz
a.2 The Smart-RF software doesn't allow an accurate 1kHz step; for example when I try to change the nominal frequency to 868.295MHz (-5kHz offset) the Smart-RF changes to frequency automatically to 868.29532MHz.
a.3 The test is done by changing the center frequency of the board used as the transmitter by 1kHz step while the center frequency of the board used as the receiver stayed at the nominal frequency.

TI's development board No. 1, used as TX:
High: center frequency set to 868.3MHz and power out is 20dBm: measured => 868.307536138MHz, 19.99dBm.
Low:  center frequency set to 868.3MHz and power out is 14dBm: measured => 868.306591411MHz, 13.2dBm.

TI's development board No. 2, used as RX:
High: center frequency set to 868.3MHz and power out is 20dBm: measured => 868.307714589MHz, 20.1dBm.
Low:  center frequency set to 868.3MHz and power out is 14dBm: measured => 868.306845832MHz, 13.6dBm.

test result screenshots are attached as a single archive file
test-results-screen-shots.zip

Thanks,
Tal

Is this for this phy:

 1. GFSK step: 70kbps
 2. Bit rate: 50Kbps
 3. RXBW: 195.9kHz (enhanced setting is 86)
 4. Central frequency: 868.3Mhz

If that is the case, would you be able to do the same measurement with the 50 kbps setting from SmartRF Studio? For this you should get the same PER vs level vs freq offset as in the datasheet and as Richard posted here. If you get the same curve the measurement is good (which I suspect it is) and it's something with the phy that create a slight frequency offset.

For the frequency steps, see chapter 13 in https://www.ti.com/lit/an/swra682/swra682.pdf that could give some insight. 

Hi,

Regarding the PHY parameters, these parameters are correct.

Regarding the tests to perform with 50kbps (instead of 5kpbs), I don't understand how to perform the test with the Smart-RF program, where can I find the test protocol?

Regarding the previous test I did; I measured the carrier frequency (nominal frequency), using an unmodulated signal, and during that test, I observed an offset of about 1kHz between the high path (including the PA) and low path (not including the PA). Because of this offset, I've done a similar test but instead of transmitting in 20dBm, through the high-path. I transmitted 14dBm, through the low power. 
please see the attached data regarding the previous test I performed for the low-path

Test Summary:
1. Total path attenuation is 123.75dB (to keep the same total power budget as for the previous test)
2.a. The best test result (measured by the number of good packets received) was when the TX board offset from the nominal frequency was from -4kH to -0kHz, while the RX board remained on the nominal frequency. The fault is reproduced but with better results (regarding the offset)!
2.b. lower the number of good packets received, even though the total power budget is the same. Why?

Test setup:
same as the high-power test.

Result Graph:

test result screenshots are attached as a single archive file
test-results-screen-shots-low.zip

My suggestion is to perform the test exactly the same way as you have done with the phy you intend to use but when you program the radio you use the settings from SmartRF Studio (code export) .

Is it a typo in your latest reply? In the original mail you write 50 kbps, GFSK step: 70kbps (is this deviation+) but now you wrote 5 kbps?

Your phy looks fairy narrowband, if I read the curve correctly, you loose more than 60 % of the packets (compared to in the centre) with less than 10 kHz offset. This means that you have to use a TCXO to get good enough frequency tolerance? 

Hi,

All the tests I've done were with 50kbps, 70khz GFSK, and RXBW=195.9kHz (index 86). I've used the RF-Strudio software with two TI's development boards for the two latest tests. These tests reproduced my product observation described in the original question.

5Kbps was done by RGW 20 days ago, see the above reply from RGW.

Ah, sorry, I only looked at the shape of the plot Richard posted and for some reason assumed it was 50 kbps (which is most relevant in this case). For some reason the 50 kbps plot is not in the CC1352 datasheet but I looked at the plot from the CC1310 datasheet (Not fully the same modem but gives an indication):

and it looks like this is is not symmetrical around 0 offset as expected.

Richard, could you dig out the 50 kbps plot for the standard 50 kbps phy for CC1352P? The CC1310 plot indicate that your customers measurements are correct and the initial question remains...

Hi,

Attached PER vs RF Level vs Frequency Offset plot for 50 kbps PHY, 868.3 MHz for CC1352R:

Hi,

I think the graph supports my observation.

We are talking about 2 to 3 dB in sensitivity.

What should be the next step to resolve this issue? 

The PER vs RF Level vs Frequency Offset plot shows a symmetrical response that does not show any frequency offset. 

With your graph you are showing that the optimum number of packets received was at approx -3 kHz (taking the center point) which is -3.5 ppm at 868.3 MHz.

You will not be losing 2-3 dB of sensitivity when offsetting the carrier by -3 kHz; this can be seen in the the PER vs RF Level vs Frequency Offset plot.

Hi,

Thank you for reproducing the measurements, I find myself confused because, from my perspective, your graph clearly shows a minimum at -5kHz to -10kHz offset and not symmetrical edges. I marked it in the graph below.


As I explained in my initial question, I tuned the carrier frequencies (TX and RX) to 868.3 +/- 1kHz and I lost 2 to 3dB from if they were tuned to Tx unit -4kHz from the Rx unit, as it was reproduced the problem with two TI's development boards by showing good packets received vs Tx/Rx carrier offsets.

Furthermore, I found a sensitivity degradation when transmitting from the low path compared with when transmitting from the high path (with the two TI's development boards) while having the same total power budget. I still waiting for a response regarding this issue.

Hi,

The PER vs RF Level vs Frequency Offset plot should have symmetrical far limitations of approx +/- 40 ppm for this particular PHY case. That the symmetrical edges are slightly different will always be the case. However, at the far edges we have approx -40 ppm and +45 ppm here.

We will reproduce your sensitivity measurements on a LaunchPAD and will let you know the results asap. 

1. when F_TX - F_RX ~= 0kHz
2. when F_TX - F_RX ~= 4kHz

For the PER vs level vs offset plot for 50 kbps: I think I recall that some of these curves are not fully symmetrical around 0 Hz offset. This is because the filter in the RX chain is not fully symmetrical due to how it's implemented. 

Hi,

Do you recommend changing the frequency (for Fcrrier - 4kHz) right before we start transmitting and changing it back after it, in order to reduce the RX chain asymmetric effect?

That would not have any effect since what I mentioned is the frequency response of the filter. But note based on the datasheet and the measurements Richard did, you are seeing a larger frequency dependency than expected.