CC1350 Spread Spectrum

So when it is in long range mode then DSSS is automatically used and no parameters need to be set for it? As far as how many channels and which frequencies are used, hop time...etc?

Yes. It's implemented in the RF core firmware. Some parameters can be customized using overrides, but we do not document them. So you have to stick to the settings that you can export from SmartRF Studio. Hop times and channels apply only to FHSS and have nothing to do with DSSS. In the TI long-range mode, you set one center frequency as usual. If you want to try out the Long-range mode, have a look at the rfPacketErrorRate example, provided with TI-RTOS.

Also I was trying to find a spec for the settling time of the PLL to determine how well it might be able to be used for FHSS but I was unable to find that specification. Do you have any information on that spec?

These values are highly settings-dependent. I suggest, to create a test scenario and measure the channel switching time. Use command chaining to speed up the execution. Create chains in the form CMD_FS -> CMD_PROP_TX -> CMD_FS -> CMD_PROP_TX ...

In order to measure the timing, this code might help you:

#include <ti/drivers/pin/PINCC26XX.h>

// RF core signals that can be routed to GPIO pins
// RFC_GPO1 	For controlling an external PA. High when the PA must be enabled and otherwise low.
// RFC_GPO2 	Goes high when the synthesizer calibration starts and low when the calibration is done.

// Map RFC_GPO1 to IO 23 in the application.
// pinhandle must be valid handle and IOID_23 must be initialized as
// output. Have a look at the TI-RTOS examples.
PINCC26XX_setMux(pinHandle, IOID_23, PINCC26XX_MUX_RFC_GPO1);

// RFC_GPO1 might be the most interesting one to measure channel switching times.

Thanks Richard, 

You have been very informative, I will look into the things you suggested. 

Regards, 

Nate

Hi Richard,

Today I tried the LR mode in the demo that you mentioned, I believe you said this mode is supposed to be DSSS. I observed the signal on the spectrum analyzer and notice that it does not meet the DTS Bandwidth requirements for FCC which specifies a bandwidth of 500kHz or more, in long range mode it is only about 150kHz. How does TI recommend the long range mode can be used and still comply with FCC 15.247? 

Thanks, 

Nate

Hello Nate,

To comply with FCC non-hopping (DTS) requirements we have a specific mode that also uses DSSS with symbol rate of 500kbps and data rate of 62.5kbps. It has been tested for functionality but it is not yet released since the characterization is not complete. This requires a specific patch which is also not released yet. If you need this urgently, please contact the locala TI field team (preferred) or send me a private message and I will try to share it with you.

Regards,

There is a solution that can do 500 ksps, DSSS with 6 dB BW > 500 kHz. I will ping SVS so she can provide status and any special patches (if needed). Preliminary results for this mode are: sensitivity (1% BER) of -107 dBm and a max power spectral density of 6.6 dBm/3 kHz.

Two alternative solutions:

a) In SmartRF Studio there are settings for 2-GFSK, 500 kbps, +/-175 kHz deviation. This gives a 6 dB BW of 500 kHz. 175 kHz deviation gives a modulation index of 0.7 and was chosen to keep the power spectral density (PSD) in any 3 kHz bandwidth as low as possible. FCC 15.247 specifies the peak PSD as max 8 dBm/3 kHz.

When using CC1310 at +14 dBm output power the PSD was measured as 5 dBm/3 kHz. Thus, the output power can be increased with an additional 3 dB and still be compliant to the PSD requirement. (note sure you want to add an external PA for the additional 3 dB output power though....). The sensitivity (1% BER) was measured as -96.5 dBm. Assuming ideal antennas the link budget is then +14 + 96.5 = 110.5 dB.

This solution gives higher throughput and lower active TX current than 500 ksps, DSSS for the same data payload. Range will be shorter though.

b) Operation under FCC 15.249 where the output power is limited to approx. -1.2 dBm. As an example: If you then operate at a lower data rate of 50 kbps the link budget will be -1.2 + 110 = 108.8 dB.

Sverre:

Thanks very much for the timely response.

I tried the 500/175 GFSK mode, but measured a 6 dB BW at around 480 kHz.  So, I manually increased this to 600 kbps, with 220k deviation, which easily put me over the hump (about 560 kHz BW).

I do have a few follow-on questions...

Since this is GFSK, do you see any reason why it wouldn't pass FCC 15.247.a.2 and 15.247.b.3?  I feel like the intent of those rulings was for DSSS, but we're achieving the same effect with GFSK.  Just want to be sure we're not "cheating" the system, and setting ourselves up to fail the cert.

Any ideas on ways to get that PSD level down further?  We'll be using the 1350 on our sensors, and the 1350 with 1190 on our gateway (it will have wall power).  The LNA in the 1190 will help our link in one direction, but if we can only run the 1190's PA for a gain of 3 dB, then we have an asymmetric link budget.  So, the FEM isn't very helpful to increasing range.

Finally, there's no need for use to run at 600 kbps.  1 kbps would be more than enough for our purposes.  If we give up baudrate, can we play any games with the other modulation settings to get back some more power?  We'd really like to get beyond the +17 (assuming we use the amp) before hitting the PSD wall.

Again, many thanks for your help.

Chris

Chris, 

Something I would encourage you to look into that will make a big difference in passing the PSD is the Modulation Index. It is a ratio of the deviation and the data rate that will affect the way the bandwidth looks on a spectrum analyzer. Minor changes can make a big difference in passing or failing. 

Preliminary results shows PSD of 6.6 dBm/3 kHz using the 500 ksps DSSS and operating at +14 dBm output power. The advantage with the DSSS approach (62.5 kbps) vs 500/600 kbps 2-GFSK is the significant improvement in sensitivity. 

You will not "cheat" the system if you use 2-GFSK. Using DSSS is not required. 

The PSD depends strongly on the modulation index. A modulation index close to 0.7 is the better choice (slightly below 0.7 gives lower PSD).

SVS:

I have a clarification question on your post on Aug 2.  Using SmartRF Studio, I followed your directions in changing the registers in the Override Editor, and found how to add the two new HW_REG_OVERRIDE fields.  The spectrum I see looks like what you described.  However, I'm not clear with the last step.  You say "Apply correct patches for cpe, mce, and rfe."  Is this something that needs to be done if I'm testing with RF Studio?  Or do you simply mean that we need to be sure that the correct *.h files are used when we eventually write code and compile?

We want to repeat our range and sensitivity tests on RF06 and/or LaunchPad boards, using SmartRF Studio, with your settings as a comparison.  I just want to make sure I'm not missing some important final step to apply the changes, and that I'm looking at the correct spectrum.  My captured spectrum is below.  Does that match your results?

Also, I'm a little concerned about the side bands.  I believe that everything outside of +/- 1 MHz of the occupied BW has to be at -20 dBc, correct?

Hello Chris,

Since this mode requires patches that are not yet available in SmartRF studio, it cannot be tested using SmartRF studio. In future, we have plans to add this mode in studio.

Without applying the mce, cpe and rfe patches for this mode, the output will not be as desired. The quickest way to test this would be to start with packet TX example in CC1310 SDK and implement all the suggested changes. You can use the CMD_TX_TEST command to transmit continuous modulated signal to check the spectrum.

Attached is  a plot of expected TX spectrum in this mode.

Regards,

6dB_20KHzRBW_100KHzVBW_Maxhold.WMF

Hello MM,

The patches needed for implementation of non-frequency hopping FCC compliant mode is part of the current release of CC13xx SDK.  I have sent you a message with the RF settings needed to implement this mode in a out-of-box RF example from SDK.  As an alternative, TI 15.4 Stack has FCC compliant long range mode already implemented.

Regards,