CC1350: Custom CC1350 board frequently missing acknowledgements/struggling to receive data.

Hello Craig, 

I do not see any obvious issues with the schematic and layout that you have posted. With change in stack up, matching may need to be optimized but you should still be able to receive packets at close proximity with default values of match. 

Following are few pointers for debug:

1. Measure TX power and frequency with spectrum analyzer. If TX power is good, the matching is likely good. Since you are using a crystal that requires different load from the default settings for crystal load capacitor on CC1350, the frequency offset may be large which can also cause the issue that you have described. Frequency offset can be reduced by tweaking the value of load capacitors. 

2. Check voltage levels on RF_SW and RF_PWR traces to make sure that they are being programmed correctly to select sub-GHz path. 

3. Check conducted output power if not already done, this will eliminate any issues with the antenna.

4. Check current consumption, if there is an issue with hardware, you will likely see different current consumption compared to expected values from datasheet. 

Hope this helps. 

Regards,

Hi SVS, Thanks for your reply.

1. Unfortuantely I don't have access to a spectrum analyzer at the moment, but I'll hopefully be able to check this soon. In the meantime I've done a very basic test to see how varying the load capacitors over a range affect the packets sent/received/perceived as failed. What I found wasn't ideal...
   
   

   Load cap delta (value)	Node packets sent	Node packets with no 'ack'	packets received by concentrator
   -5 (7.9pF)	120	120	100
   -2 (8.6pF)	120	118	115
   0 (9pF)	120	114	104
   2 (9.4pF)	120	120	108
   5 (10.1pF)	120	120	111
   10 (11.1pF)	120	120	120

   
   
   
2. I've checked the voltages and they seem fine. Messing around manually with the control lines I'm able to active/deactivate them and see the results clearly when packets don't get through to the concentrator at all. For now I've made sure it is never switched from the sub-GHz path to avoid any mistakes while debugging.
   
   
3. I'll have to wait until I get my hands on a spectrum analyzer to do this properly. The packets that are being received by the concentrator are around -30 to -45 dBm when doing the tests above within a few feet of each other.
   
   
4. There are a lot of other components on the board, so this might be tricky, but I'll give it a shot.

I'm not sure, but perhaps the balun components are wrong/not the exact ones specified to the manufacturer. Could this affect the performance this badly? I have ordered the specific components for the feedlines that were originally stated in the BOM, so I'll maybe try to replace them if this is potentially the cause.

Cheers,

Craig

Hello Craig,

With load capacitor of 11.1pF, it seems like concentrator is receiving all packets but none of the acknowledgements are being received by the node, is this interpretation correct? While you wait for spectrum analyzer, you could try increasing the receive bandwidth to allow the transmitter to receive packet with higher frequency offset. This will especially help if you testing at low data rates. What PHY mode are you using for testing?

-30 to -45dBm power levels are quite reasonable at few feet distance and even though the matching may not be optimized, I would expect it to be fairly close to ideal values.

Also, have you tried testing at different frequencies?

Regards,

It certainly does look like the situation you describe when I alter the load capacitors.

Right now I'm using the custom RF Studio PHY that comes with the EasyLink examples:

// Parameter summary
// Address: off
// Address0: 0xAA
// Address1: 0xBB
// Frequency: 868.00000 MHz
// Data Format: Serial mode disable
// Deviation: 25.000 kHz
// Packet Length Config: Variable
// Max Packet Length: 128
// Packet Length: 20
// RX Filter BW: 98 kHz
// Symbol Rate: 50.00000 kBaud
// Sync Word Length: 32 Bits
// TX Power: 14 dBm (requires define CCFG_FORCE_VDDR_HH = 1 in ccfg.c, see CC13xx/CC26xx Technical Reference Manual)
// Whitening: No whitening

I played around with the RX filter bandwidth in SmartRF studio and it does seem to make a good bit of difference if I change it from 98 to 196kHz. I've transferred those settings over to the custom node/Launchpad concentrator and it seems a lot more robust; no missed ack's in a short test with over 300 packets sent.

Obviously I still hope to find the true source of the issue here, but in the meantime, what are the implications of having a wider RX filter BW?

I also tested with the frequency at 915MHz, and it seems like the concentrator will receive every single packet no problem, but the node receives no ack packets as before.

I haven't looked up the xtal you are using. Which CL is this specified for? Note that according to the datasheet CL = 9 pF is max and if you have to use 11.1 pF you are outside what the chip is spec'ed for.

I would start with the CW example and verify that the chip sends on the correct frequency. What is the line routed under Q1 and Q2 for the xtal?

Hi TER,

The line routed under the xtal is the power for the RF switch.

The xtal I'm using is one specified in the list of acceptable xtals on the wiki: Kyocera
CX2016DB24000C0WPRC1, 10ppm, CL = 8pF.

With the Carrier Wave example, how will this allow me to check the correct frequency? Would I need a VNA or other RF tool?

I'm still uncertain on one thing from before: what are the implications of having a wider RX filter BW?

You would need a spectrum analyzer using a low RBW to measure the exact frequency. You should check this before changing code etc since you need to have control over your hardware before starting to look at software.

With a wider RX BW you will receive more noise and the sensitivity will be reduced.