CCS/CC1310: Custom Board using TI 15.4 Stack not transmitting

Try to use sniffer to check if sensor joins collector correctly.

Without knowing too much about the hardware it's difficult to pinpoint where you may have a bug. We haven't you mounted the 32 kHz xtal?

I have tried making my custom board act as either the Sensor or Collector and connect with the CC1310 Launchpad with no success. Using a spectrum analyzer, no transmitted packets can be detected when my custom board should be transmitting. The LEDs clearly blink as expected on the custom board.

It really doesn't help that the Collector example gets stuck in macRadioPowerUpWait() upon a CPU reset when run on the Launchpad with the normal ccfg file (sourcing RTC from xtal). The same error occurs on my custom boards so I have to flash with the Flash Programmer 2 as a workaround. This issue has been mentioned previously on the forums and a solution was not found for TI provided code.

I previously had a 32KHz xtal mounted and was trying to determine the source of the error. I removed the 32KHz clock and change the ccfg as follows:

#define SET_CCFG_MODE_CONF_SCLK_LF_OPTION            0x0        // LF clock derived from High Frequency XOSC

This way the TI Stack uses only the 24MHz HF clock. Running the TI Stack on the Launchpad boards with this setting works successfully. Running this code on my custom board does not (does not connect, no transmission detected). 

My custom board only uses a HF crystal which is not the same as the launchpad, however as mentioned before I am using external capacitors and the internal capacitor tuning to get an exact frequency match with an unmodulated signal in SmartRf Studio. Am I missing an additional connection that is required for the TI Stack to execute correctly? Perhaps this is an issue with the RTOS not working with my HF clock?

I have added back the 32KHz xtal and measured the frequency to be hovering about 32KHz. In CCS, I used ROV to verify that no there were no obvious errors or exceptions with the RTOS.

I setup UART connection on the custom board with the Sensor example and the correct messages are received.

I setup the Launchpad as a packet sniffer on different subchannels in the 433 MHz band for the TI Stack and only received one packet after hours of testing. I was not able to replicate another reception with the sniffer. Again, I have verified that my RF circuit transmits in the 433MHz band correctly with a spectrum analyzer and with the rfEasyLink examples.

I'm open to any more suggestions!

Thank you for the help so far!

Madison

EDIT:

The sniffer with the rfEasyLinkTx example at 433.3MHz works.

Are you using the phy's actually supported by the stack: dev.ti.com/.../ti154stack-overview.html ?

The wording in the stack documentation suggest channel 0 is 403.3MHz, however every other resource suggest 433.3MHz as channel 0 (e.g. using SmartRf Packet Sniffer 2 with 'sniffer_fw_gfsk_50kbps_433.hex' loaded on the CC1310 Launchpad has 433.3MHz set as channel 0, 433.5MHz as channel 1, etc.). As well, I can clearly detect the CC1310 Launchpad transmitting with 433.3MHz as channel 0 with a spectrum analyzer with the TI 15.4 Stack.

I am indeed using the stack provided definitions for the Chinese 433 MHz 50kbps band:

#define CONFIG_PHY_ID                (APIMAC_GENERIC_CHINA_433_PHY_128)

A related forum with no definite conclusion to a similar problem:

e2e.ti.com/.../2270658

I will attempt to use both the defined 868MHz and 915MHz PHY_ID on my custom board, however my RF matching circuit was not designed for the higher frequencies and performs poorly with rfEasyLink examples.

Is there any timing constraints defined by the TI 15.4 stack or by the TI-RTOS that would prevent communication if a clock was not oscillating at the exact expected frequency? i.e. MAC protocol timing check that cancels TX if the crystal doesn't match an internal crystal timing check, race scenario between XOSC and internal OSC to timeout TX? Other than a change in the carrier frequency, how would poor XOSC components affect the TI 15.4 stack negatively? 

There may be a mistake with the Ti 15.4 stack or the documentation under the 433MHz settings:

I have verified that channel 0 in the 868MHz band is indeed 863.125 MHz, however channel 0 in the 433MHz band is 433.3MHz, not 403.3 MHz. Regardless of this issue, the channel spacing is still set at 200KHz and the packet smartRf Packet Sniffer 2 application expects channel 0 at 433.3MHz.

My custom board is able to communicate in the 868MHz band and the 915MHz with the TI 15.4 stack and the sniffer is able to receive the correct beacon packets.

This problem now appears to be an issue either with the TI 15.4 stack settings in the 433MHz band, or with my RF circuit. I have confirmed with smartRf Studio that my custom boards radio can transmit from 400MHz to 500MHz with the same amplitude or greater than the CC1310 Launchpad. Why would it fail when using the TI 15.4 stack in this frequency band?

Is there additional modifications required to config.h to get better gains with APIMAC_GENERIC_CHINA_433_PHY_128?

To see if I understand your current status correctly:
Your custom board is able to communicate in the 868MHz band and the 915MHz with the TI 15.4 stack but not on 433 MHz?

I assume you have tested that you are able to communicate on 433 MHz with a LP (The match is made for 868 MHz) but you should still be able to have a link across your desk.

I agree that it has to be a typo in the documentation, I will file a ticket on this.

You are correct in your understanding. I have tested communication with a Launchpad (LP) at 433MHz and can get communication across my desk. I can make my custom boards communicate directly at 433MHz using the SmartRf settings for the radio, just not with the TI 15.4 stack.

Everything suggests that the specific radio settings used by the TI 15.4 stack at 433MHz results in my match antenna failing which I have accepted as the problem. 

Within the Ti 15.4 stack, mac_settings.c has some the default RF settings used for the radio. Do you have the SmartRf settings used when in the 433MHz band? I am now interested in replicating the issue in SmartRf possible.

Thank you for the help with identifying the problem. 

I find it a bit difficult to support this case over mail. It could sound like it's at least partially a hardware issue. Not sure I understand why you removed the 32 kHz xtal in the first place?