Examples Users Guide

Software Examples Overview

The Proprietary RF examples are split in to 2 types:

  • EasyLink Examples
  • RF Driver Examples

In very basic terms the RF driver offers API’s to send RF commands to the RF core. EasyLink is an abstraction layer above the RF driver offering API’s for the more common RF functions (init, set/get frequency, set/get power, Tx/Rx, address filtering etc) that send the RF commands to the RF Driver. The EasyLink layer was developed to be simple enough for developers to extend for their needs and should be seen as a starting point for adding an API on top of the RF driver. The EasyLink Examples show how to develop an RF application on top of the EasyLink API.

The RF Driver Examples show how to use the more complex RF commands and command chaining such as Listen Before Talk and Wake On Radio.

The following examples are provided:

Packet RX/TX:The most fundamental examples written directly on top of the TI-RTOS RF driver, shall be used as base for customers own applications using the RF driver. The Packet RX/TX examples illustrate how to do simple packet RX/TX using the TI-RTOS RF driver. Using the RF driver ensures optimal RF and power performance. The PHY/RF settings can be modified using SmartRF Studio. Commands exported and used directly in code. Out of the box IEEE 802.15.4g GFSK 50kbps is used. Easy to change to e.g. Long Range Mode or custom PHY settings.
Carrier Wave:Basic example for RF performance measurements and testing, written directly on top of the TI-RTOS RF driver. Set the radio into various test modes. Transmission of modulated or unmodulated signal. Easy to change radio configuration. Use radio settings exported from SmartRF Studio.
EasyLink RX/TX:EasyLink is a simplified API on top of the RF driver, intended to be used as a starting point for creating a proprietary sub-1 GHz protocol. Read more about EasyLink here. The EasyLink RX and TX examples show how to use the EasyLink API to access the TI-RTOS RF driver, how to set the frequency, and how to transmit and receive packets. One board can run the RX example while the other runs the TX example. The transmitter sends a packet every 100 ms, with a delay of 300ms between every 10th packet. The LED on the receiver board will blink for every packet received.
EasyLink NWP:The EasyLink API has been exposed over an AT Command Interface such that it can be exercised by Host SW (running on a PC, MPU or MCU) or by a human using a serial terminal emulator over a UART.
Wireless Sensor Network:
 The Wireless Sensor Network (WSN) Node and Concentrator examples illustrate how to create a very basic sensor network consisting of one or many Node device(s) and a Concentrator device. The example shows how to form one-to-many network where the Nodes send messages to the Concentrator. The Node use the Sensor Controller Engine to periodically read the value of the light sensor. Whenever the sensor value change, the main controller wakes up and sends a packet with the value to the Concentrator. The Concentrator is always waiting for incoming packet. Once a packet is received, the Concentrator sends an acknowledgement packet in return and displays the data on an LCD (if the kit has one)
Listen Before Talk:
 The Listen Before Talk (LBT) TX example illustrates how to implement a simple, proprietary LBT algorithm using the command chaining feature of CC13xx. When sending a packet, the radio first enters RX mode using CMD_PROP_CS. If the channel is IDLE (the RSSI is below RSSI_THRESHOLD) for IDLE_TIME_US, then the radio enters TX and transmits a packet. If the channel is BUSY (RSSI above RSSI_THRESHOLD), the radio enters RX again to check the channel once more. This is repeated max CS_RETRIES_WHEN_BUSY number of times. The command chain will either finish with a packet being sent (if the channel is IDLE), or after checking the channel CS_RETRIES_WHEN_BUSY times. Packet Error Rate (PER) test The Packet Error Rate (PER) example showcases different RF transfer modes (PHYs) of the CC13xx. It combines tasks, events and several peripherals into a platform- independent application. Uses LCD and/or UART to display a GUI, making it easy to navigate the example.
Wake On Radio RX/TX:
 These examples showcase the Wake-on-Radio (WoR) functionality of the CC13xx to significantly lower the power consumption of an RF link by duty cycling the radio core. It shows how to use the RF Driver to schedule automatic wake-ups in the future and send messages with long preambles. Dual Mode Wireless Sensor Network The WSN Dual Mode Concentrator and Node examples illustrate how to combine BLE advertisements and a simple sub-1GHz Wireless Sensor Network Concentrator and Node device. The Dual Mode Concentrator receives ADC sensor data, battery readings and button state from the Dual Mode Nodes over the sub- 1GHz link and displays the sensor reading on UART and LCD. Once a packet is received, the Concentrator sends an acknowledgement packet in return. The Node uses the Sensor Controller Engine to periodically read the ADC. Whenever the sensor value changes by a certain threshold, the main controller wakes up and sends a packet with the ADC value, battery voltage level and button state as payload to the Concentrator over the sub-1GHz link. The node then reconfigures the radio to send out the same payload in BLE advertisement packets in a BLE Eddystone UID + TLM Beacon. Beacon can be picked up by any Eddystone capable device. The node also sends a BLE Eddystone URL beacon with the URL to ti.com. This beacon can be picked up by any physical web capable device such as Chrome browser on iOS or Android. The node is also sending out Manufacturer Specific (MS) BLE beacons that are used with the sensorTag smartphone app. Getting Started with CC13xx Software Examples

For all examples, except Wake On Radio, the following proprietary PHY settings are available:

2-GFSK:Generic frequency shift keying with binary symbols, 50 kBit/s
LR Mode:Long-range mode
OOK:On-off keying
HS Mode:High-speed mode with up to 4 MBit/s

The following sections contain more detailed information about the examples.

Note

A guide to porting an existing Proprietary RF application based on the TIRTOS SDK to the CC13x0 SDK can be found here: http://processors.wiki.ti.com/index.php/Proprietary_RF_MCU_SDK_Porting_Guide

More information regarding TIRTOS and extending the RF examples can be found here:

TIRTOS Video Workshop SimpleLink Academy
tirtos-online-videos simplelink-academy
If you have never used TI-RTOS before, these online video workshops give you a fast start. The SimpleLink Academy contains a set of tutorials that build on top of our examples.

Rf Driver Examples

The RF Driver examples can be imported from the SDK directory: C:/ti/simplelink_cc13x0_sdk_1_00_00_xx/examples/rtos/<PLATFORM>/drivers/

rfCarrierWave

Example Summary

The carrier wave (CW) example sends a continuous carrier wave or pseudo-random modulated signal on a fixed frequency. The frequency and other RF settings can be modified using SmartRF Studio.

Peripherals Exercised

N/A

Resources & Jumper Settings

If you’re using an IDE (such as CCS or IAR), please refer to Board.html in your project directory for resources used and board-specific jumper settings. Otherwise, you can find Board.html in the directory <SDK_INSTALL_DIR>/source/ti/boards/<BOARD>.

Example Usage

Run the example.

Application Design Details

This examples consists of a single task and the exported SmartRF Studio radio settings.

The default frequency is 868.0 MHz. In order to change frequency, modify the smartrf_settings file. This can be done using the code export feature in Smart RF Studio, or directly in the file.

To switch between carrier wave (1) and modulated signal (0) set the following in the code (CW is set as default):

RF_cmdTxTest.config.bUseCw = 1; // CW
RF_cmdTxTest.config.bUseCw = 0; // modulated signal

In order to achieve +14 dBm output power, make sure that the define CCFG_FORCE_VDDR_HH = 0x1 in ccfg.c

When the task is executed it:

  1. Configures the radio for Proprietary mode
  2. Explicitly configures CW (1) or Modulated (0). Default modulated mode is PRBS-15
  3. Gets access to the radio via the RF drivers RF_open
  4. Sets up the radio using CMD_PROP_RADIO_DIV_SETUP command
  5. Sets the frequency using CMD_FS command
  6. Sends the CMD_TX_TEST command to start sending the CW or Pseudo-random signal forever

Note for IAR users: When using the CC1310DK, the TI XDS110v3 USB Emulator must be selected. For the CC1310_LAUNCHXL, select TI XDS110 Emulator. In both cases, select the cJTAG interface.

rfPacketTx

Example Summary

The Packet TX example illustrates how to do simple packet transmission using the RF driver. This example is meant to be used with the Packet RX example or SmartRF Studio. For every packet transmitted, Board_PIN_LED1 is toggled. The frequency and other RF settings can be modified using SmartRF Studio.

Peripherals Exercised

  • Board_LED1 - Toggled when data is transmitted over the RF interface

Resources & Jumper Settings

If you’re using an IDE (such as CCS or IAR), please refer to Board.html in your project directory for resources used and board-specific jumper settings. Otherwise, you can find Board.html in the directory <SDK_INSTALL_DIR>/source/ti/boards/<BOARD>. For convenience, a short summary is also shown below.

| Development Boards | Notes                                               |
| ================== | =================================================== |
| CC1310DK           | Board_PIN_LED1 is the "LED1" LED                    |
| ------------------ | --------------------------------------------------- |
| CC1310_LAUNCHXL    | Board_PIN_LED1 is the "Red" LED                     |
| ------------------ | --------------------------------------------------- |

Example Usage

Run the example. On another board, run the Packet RX example. Board_PIN_LED1 is toggled when data is transmitted.

Application Design Details

This examples consists of a single task and the exported SmartRF Studio radio settings.

The default frequency is 868.0 MHz. In order to change frequency, modify the smartrf_settings file. This can be done using the code export feature in Smart RF Studio, or directly in the file.

The default frequency is 868.0 MHz, in order to change RF settings please modify the smartrf_settings.c file. This can be done either by exporting from Smart RF Studio or directly in the file.

When the task is executed it:

  1. Configures the radio for Proprietary mode
  2. Gets access to the radio via the RF drivers RF_open
  3. Sets up the radio using CMD_PROP_RADIO_DIV_SETUP command
  4. Set the output power to 14 dBm (requires that CCFG_FORCE_VDDR_HH = 1 in ccfg.c)
  5. Sets the frequency using CMD_FS command
  6. Create packet (with increasing sequence number and random content)
  7. Set absolute TX time to utilize automatic power management
  8. Transmit packet using CMD_PROP_TX command with blocking RF driver call
  9. Toggle Board_PIN_LED1 to indicate packet transmitted
  10. Transmit packets forever by repeating step 6-9

Note for IAR users: When using the CC1310DK, the TI XDS110v3 USB Emulator must be selected. For the CC1310_LAUNCHXL, select TI XDS110 Emulator. In both cases, select the cJTAG interface.

rfPacketRx

Example Summary

The Packet RX example illustrates how to do simple packet RX using the RF driver. This example is meant to be used with the Packet TX example or SmartRF Studio. For every packet received, Board_PIN_LED2 is toggled. The frequency and other RF settings can be modified using SmartRF Studio.

Peripherals Exercised

  • Board_LED2 - Toggled when data is received over the RF interface

Resources & Jumper Settings

If you’re using an IDE (such as CCS or IAR), please refer to Board.html in your project directory for resources used and board-specific jumper settings. Otherwise, you can find Board.html in the directory <SDK_INSTALL_DIR>/source/ti/boards/<BOARD>. For convenience, a short summary is also shown below.

| Development Boards | Notes                                               |
| ================== | =================================================== |
| CC1310DK           | Board_PIN_LED2 is the "LED2" LED                    |
| ------------------ | --------------------------------------------------- |
| CC1310_LAUNCHXL    | Board_PIN_LED2 is the "Green" LED                   |
| ------------------ | --------------------------------------------------- |

Example Usage

Run the example. On another board, run the EasyLink TX example. Board_PIN_LED2 is toggled when data with CRC OK is received.

Application Design Details

This examples consists of a single task and the exported SmartRF Studio radio settings.

The default frequency is 868.0 MHz. In order to change frequency, modify the smartrf_settings file. This can be done using the code export feature in Smart RF Studio, or directly in the file.

The default frequency is 868.0 MHz, in order to change RF settings please modify the smartrf_settings.c file. This can be done either by exporting from Smart RF Studio or directly in the file.

When the task is executed it:

  1. Configures the radio for Proprietary mode
  2. Gets access to the radio via the RF drivers RF_open
  3. Sets up the radio using CMD_PROP_RADIO_DIV_SETUP command
  4. Defines a data queue to handle received data
  5. Sets the frequency using CMD_FS command
  6. Sends the CMD_PROP_RX command to start receiving data
  7. Once data with CRC OK is received we toggle the Board_PIN_LED2 and re-enter RX with the CMD_PROP_RX command

Note for IAR users: When using the CC1310DK, the TI XDS110v3 USB Emulator must be selected. For the CC1310_LAUNCHXL, select TI XDS110 Emulator. In both cases, select the cJTAG interface.

rfWakeOnRadioTx

Example Summary

This examples showcases the Wake-on-Radio (WoR) functionality of the CC1310 to significantly lower the power consumption of an RF link. It shows how to use the RF Driver to schedule automatic wake-ups in the future and send messages with long preambles.

This example is intended to be used together with the rfWakeOnRadioRx example.

Peripherals Exercised

  • Board_PIN_LED1- Toggled when data is transmitted over the RF interface
  • Board_PIN_BUTTON0 - Press to send packet

Resources & Jumper Settings

If you’re using an IDE (such as CCS or IAR), please refer to Board.html in your project directory for resources used and board-specific jumper settings. Otherwise, you can find Board.html in the directory <SDK_INSTALL_DIR>/source/ti/boards/<BOARD>. For convenience, a short summary is also shown below.

| Development Boards | Notes                                               |
| ================== | =================================================== |
| CC1310DK           | Board_PIN_LED1 is the "LED1" LED                    |
|                    | Board_PIN_BUTTON0 is "Board_KEY_UP"                 |
| ------------------ | --------------------------------------------------- |
| CC1310_LAUNCHXL    | Board_PIN_LED1 is the "Red" LED                     |
|                    | Board_PIN_BUTTON0 is "Board_BTN1"                   |
| ------------------ | --------------------------------------------------- |

Example Usage

Run the example on one of the boards above, this will be the TX board. Pressing Board_PIN_BUTTON0 will trigger a transmit. Every time a packet is sent, Board_PIN_LED1 will toggle.

Start the rfWakeOnRadioRx companion example on another board (RX board). Board_PIN_LED1 on the RX board should now be blinking.

With the RX board running, press Board_PIN_BUTTON0 on the TX board. Both Board_PIN_LED1 on the TX board and Board_PIN_LED1 on the RX board should now toggle.

Basic configuration

It is possible to use the Code Export feature of SmartRF Studio with the Packet TX / RX tab selected to export settings for this example. This example has been tested mainly with 50kbit/s.

The wakeup interval is set using the WOR_WAKEUPS_PER_SECOND define at the top of the rfWakeOnRadioTx.c file. Make sure that this is set to the same in both the RX and TX part of the Wake-on-Radio example.

Application Design Details

The complete Wake-on-Radio example suite is based on the principle of duty-cycling the radio and entering RX just as much as necessary to detect a packet.

This TX example is very similar to the rfPacketTX example except that it uses the CMD_PROP_TX_ADV to be able to send a long preamble.

The length of the preamble is dynamically calculated based on the WOR_WAKEUPS_PER_SECOND define at the top of the rfWakeOnRadioTx.c file.

For more details about the general operation of the Wake-on-Radio example suite, please see the rfWakeOnRadioRx README.

Note for IAR users: When using the CC1310DK, the TI XDS110v3 USB Emulator must be selected. For the CC1310_LAUNCHXL, select TI XDS110 Emulator. In both cases, select the cJTAG interface.

rfWakeOnRadioRx

Example Summary

This examples showcases the Wake-on-Radio (WoR) functionality of the CC1310 to significantly lower the power consumption of an RF link. It shows how to use the RF Driver to schedule automatic wake-ups in the future and do a Carrier Sense as quickly as possible using RSSI and Preamble Quality (PQT).

This example is intended to be used together with the rfWakeOnRadioTx example.

Peripherals Exercised

  • Board_PIN_LED0 - The LED is on when the radio is in active RX
  • Board_PIN_LED1 - Toggled when data is transmitted over the RF interface

Resources & Jumper Settings

If you’re using an IDE (such as CCS or IAR), please refer to Board.html in your project directory for resources used and board-specific jumper settings. Otherwise, you can find Board.html in the directory <SDK_INSTALL_DIR>/source/ti/boards/<BOARD>. For convenience, a short summary is also shown below.

| Development Boards | Notes                                               |
| ================== | =================================================== |
| CC1310DK           | Board_PIN_LED0 is the "LED4" LED                    |
|                    | Board_PIN_LED1 is the "LED1" LED                    |
| ------------------ | --------------------------------------------------- |
| CC1310_LAUNCHXL    | Board_PIN_LED0 is the "Green" LED                   |
|                    | Board_PIN_LED1 is the "Red" LED                     |
| ------------------ | --------------------------------------------------- |

Example Usage

Run the example on one of the boards above, this will be the RX board. Board_PIN_LED0 will blink on this board for every wakeup. By default the example is set up to wake up two times per second, so every 500 ms.

Start the rfWakeOnRadioTx companion example on another board (TX board) and press Board_PIN_BUTTON0 on that board to send a packet.

Board_PIN_LED1 on the RX board should now toggle for every button press.

Basic configuration

It is possible to use the Code Export feature of SmartRF Studio with the Packet TX / RX tab selected to export settings for this example. This example has been tested mainly with 50kbit/s.

The wakeup interval is set using the WOR_WAKEUPS_PER_SECOND define at the top of the rfWakeOnRadioRx.c file. Make sure that this is set to the same in both the RX and TX part of the Wake-on-Radio example.

Application Design Details

Note: For IAR users using any SensorTag(STK) Board, the XDS110 debugger must be selected with the 4-wire JTAG connection within your projects’ debugger configuration.

The Wake-on-Radio example is based on the principle of duty-cycling the radio and entering RX just as much as necessary to detect a packet.

The application has one task which, besides initializing the application, re-submits a CMD_PROP_RX_SNIFF command to the radio with a given interval.

Whenever the RX Sniff command has been run, it also logs the status of the command. Some statistics regarding this status may be found in the “worStatistics” structure. Here it’s possible to see why the command finished, which can be one of four reasons:

  1. Returned Idle because no RSSI was found
  2. Returned Idle because RSSI was found, but not PQT
  3. Timed out because we found RSSI and PQT, but not a valid sync word
  4. Received a packet

In the application, the internal LNA control signal has been routed to Board_PIN_LED0. This means that when the radio is in active RX, Board_PIN_LED0 will be on. If RSSI is not found to be over the configured threshold, then it will be on for a shorter time than if it is found to be over the threshold. The reason for this is because if it is over the threshold, then it will also check for a valid preamble.

If the RSSI and a valid preamble is found, then it will also continue and look for the sync word. If the sync word is found, and the CRC of the packet is also correct, then Board_PIN_LED1 will toggle.

Packet Preamble

Below is a typical radio physical layer packet format.

|  Preamble  |  Sync Word  |  Length Byte  |  Payload  |    CRC    |
--------------------------------------------------------------------
|   4 byte   |   4 byte    |    1 byte     |  X bytes  |  2 bytes  |

The preamble is usually set to a repeating 10101010 pattern, as the beginning of the packet is used for several purposes in a modern radio. This usually involves settling the Automatic Gain Control, estimating frequency error etc. In addition to this, it can also be used for detecting the presence of a signal.

If we use the preamble to detect the presence of a signal, then the receiver has to wake up often enough to not miss the preamble. This means that the length of the preamble directly affects how often the receiver has to wake up.

At 50kbit/s 2-GFSK a 4 byte preamble is only 650 us long. This means that to not miss a packet, the receiver would have to wake up more than 1500 times per second. This is generally not a feasible solution, and does not save a lot of power.

If we instead configure the transmitter to send a 100 ms long preamble, this means that the receiver only have to wake up 10 times per second to be guaranteed to receive the packet. This increases the latency in the system, but significantly reduces the average power consumption.

In this Wake-on-Radio example, the default setting is to send a 500 ms preamble and so wake up approximately two times per second to check for it.

RSSI and PQT

There are generally two ways to check for the presence of a signal on the air with a receiver. One is to check the Received Signal Strength Indicator (RSSI) which simply indicates the energy received. The other is to check for the presence of a valid preamble and check the Preamble Quality (PQT).

RSSI is usually quicker to check, but also gives less information. How long it takes to get a valid RSSI read to compare against a given threshold depends mainly on the configured receiver bandwidth. The information you get from an RSSI reading is only that there is a signal present, it give no qualitative information.

PQT takes a bit longer to check than RSSI. The main reason being that the receiver has to receive a certain number of symbols before it can take a look at the received data and check that it does indeed look like a valid preamble. How long this takes mainly depends on the symbol rate.

It is also possible to check both RSSI and PQT. In that case one would normally first check RSSI, preferably at the sensitivity level, and then if the RSSI is above it, check for PQT.

The RX Sniff Commands

The CC13xx have dedicated radio commands for entering RX and for doing Carrier Sense. To enter receive mode, one would send either CMD_PROP_RX or CMD_PROP_ADV. To do a carrier sense, one would send CMD_PROP_CS. There are also two commands which combine a carrier sense with entering receive in the presence of a signal. These are the CMD_PROP_RX_SNIFF and CMD_PROP_RX_ADV_SNIFF.

The sniff commands themselves consist of two parts. The first part are bit fields that are identical to the respective RX command, and the second part is identical to the carrier sense command. In practice, the sniff commands behave much like chaining a CMD_PROP_CS with a CMD_PROP_RX(_ADV), but with less overhead.

The sniff command can be configured to use either RSSI, PQT or both as a criterion for detecting the presence of a signal. In this example, both are used by default.

Wake-on-Radio configuration of the RX Sniff command

There are several parameters that are important when configuring the RX Sniff command for use with a long preamble for Wake-on-Radio.

This example has configured the RX Sniff command in the following way by default:

  • Use RSSI and PQT:

    rxSniffCmd->csConf.bEnaRssi = 1; rxSniffCmd->csConf.bEnaCorr = 1;

  • Report Idle directly if RSSI is not valid, no need to test PQT then:

    rxSniffCmd->csConf.operation = 1;

  • End command straight away if Idle is reported:

    rxSniffCmd->csConf.idleOp = 1;

  • Continuously check RSSI and PQT for the entire length of the preamble:

    rxSniffCmd->csConf.busyOp = 0;

  • The RSSI threshold is set in a define in the example. Default is sensitivity of default 50kbit/s SmartRF Studio settings:

    rxSniffCmd->rssiThr = (int8_t)WOR_RSSI_THRESHOLD;

  • A single RSSI above threshold is enough to report Busy / Idle:

    rxSniffCmd->numRssiBusy = 1; rxSniffCmd->numRssiIdle = 1;

  • A single valid PQT is enough to report Busy / Invalid:

    rxSniffCmd->corrConfig.numCorrBusy = 1; rxSniffCmd->corrConfig.numCorrInv = 1;

Except for the functional settings, there are also several timing parameters that need to be configured correctly. These are based on the length of the preamble and/or the selected data rate:

Start Trigger

To be able to have a deterministic interval between wake-ups, absolute timing is used. This is done by setting the start trigger type to be TRIG_ABSTIME. This means that the start time itself is given in Radio Timer (RAT) ticks, and this is incremented with the given interval, (i.e. 500ms for waking up twice per second) for each wakeup.

The start trigger also has the “past trigger” feature enabled. This means that if the start time has already passed, it will trigger immediately. The reason for this is because when we increment the start time for the wakeup after we receive a packet, the new start time might already have passed. This means that we will simply check the RSSI directly after we receive a packet, and then start incrementing to the given interval again. Since the interval will simply be shorter when this happens, no packets can be lost.

End Trigger

The end trigger of the RX Sniff command is set to slightly longer than the entire preamble plus the length of the sync word. This means that if we wake up at the very beginning of the preamble, we wait until we would have received the entire preamble and sync word, and if we have not gotten a sync word by then, we leave RX.

Note: This is critical for not getting stuck in RX in the presence of an interferer which is sending a valid preamble.

Correlation Period

The correlation period is the time window in which the radio have to have detected a valid preamble. This time window will be moved forward for every valid PQT detected, which is done in the underlying hardware via correlation peaks, hence the name. The very first peak will happen after about 24 symbols of preamble has been received. Subsequent peaks will happen every two symbols. If there is no correlation peak within the Correlation Period, then there is no valid preamble on the air.

One caveat of this period is that it has to be both wide enough to get the very first correlation peak. Another is that it also has to be wide enough to be able to fit the entire sync word, with some margin. The reason for this is because if it is not, then the command will report back that it can no longer sense preamble as it is receiving the sync word.

Carrier Sense End Time

The RX Sniff command does not normally take a decision on the presence of a valid preamble until the end of the correlation period. And as mentioned above, the correlation period has to be wide enough to fit the sync word with some margin. With the carrier sense end time, it is possible to force an early check.

The earliest we can force this check is when we know that we would have gotten a correlation peak if there is any preamble present. This will be after about 24 symbols plus 150us. The subject of this, and other timing parameters, will be covered in a future Wake-on-Radio application note from Texas Instruments.

Note for IAR users: When using the CC1310DK, the TI XDS110v3 USB Emulator must be selected. For the CC1310_LAUNCHXL, select TI XDS110 Emulator. In both cases, select the cJTAG interface.

rfListenBeforeTalk

Example Summary

The Listen Before Talk (LBT) TX example illustrates how to implement a simple, proprietary LBT algoritm using command chaining.

When sending a packet, the radio first enters RX mode using CMD_PROP_CS. If the channel is IDLE (the RSSI is below RSSI_THRESHOLD) for IDLE_TIME_US, the the radio enters TX and transmits a packet. If the channel is BUSY (RSSI above RSSI_THRESHOLD), the radio enters RX again to check the channel once more. This is repeated max CS_RETRIES_WHEN_BUSY number of times. The command chain will either finish with a packet being sent (if the channel is IDLE), or after checking the channel CS_RETRIES_WHEN_BUSY times.

Default Settings:

  • CS_RETRIES_WHEN_BUSY: 10
  • RSSI_THRESHOLD: -90 dBm
  • IDLE_TIME_US: 5000 us

Peripherals Exercised

  • Board_PIN_LED1 - Toggled for every packet sent.

Resources & Jumper Settings

If you’re using an IDE (such as CCS or IAR), please refer to Board.html in your project directory for resources used and board-specific jumper settings. Otherwise, you can find Board.html in the directory <SDK_INSTALL_DIR>/source/ti/boards/<BOARD>. For convenience, a short summary is also shown below.

| Development Boards | Notes                                               |
| ================== | =================================================== |
| CC1310DK           | Board_PIN_LED1 is the "LED1" LED                        |
| ------------------ | --------------------------------------------------- |
| CC1310_LAUNCHXL    | Board_PIN_LED1 is the "Green" LED                       |
| ------------------ | --------------------------------------------------- |

Example Usage

The example code can be tested with SmartRF Studio or the rfPacketRX examples as the receiver, and a jammer at 868.0 MHz.

Application Design Details

The command chain contains the following commands:

  • CMD_NOP
  • CMD_PROP_CS
  • CMD_COUNT_BRANCH
  • CMD_PROP_TX

The following image shows the control flow:


                               -------------
                               |           |
                               |  CMD_NOP  |
                               |           |
                               -------------
                                     |
                                     |
                                     |
                             -----------------
     PROP_DONE_IDLE          |               |
---------<-------------------|  CMD_PROP_CS  |----<---
|                            |               |       |
|                            -----------------       |
|                                     |              |
|                      PROP_DONE_BUSY |    RF_cmdCountBranch.counter-- > 0
|                                     |              |
|                          ----------------------    |
|                          |                    |    |
|                          |  CMD_COUNT_BRANCH  |-->--
|                          |                    |    |
|                          ----------------------    |
|                                    .               |
|                                    .    RF_cmdCountBranch.counter-- = 0
|                                    .               |
|                            -----------------       |
|                            |               |       |
--------->-------------------|  CMD_PROP_TX  |       |
                             |               |       |
                             -----------------       |
                                    |                |
                                    |--------<--------
                                    |
                        Last command in chain done

The carrier sense command CMD_PROP_CS is prepended by a CMD_NOP in order to set an absolute trigger time TIRG_ABSTIME for the whole chain. All other commands trigger immediately after each other. If CMD_PROP_CS indicates a busy channel it is restarted by CMD_COUNT_BRANCH for maximum RF_cmdCountBranch.counter times. Only if CMD_PROP_CS observes an IDLE channel, CMD_PROP_TX is executed.

On a successful transmission, Board_PIN_LED1 toggles and the sequence number in the packet is incremented. If CMD_PROP_TX can not be executed due to an always BUSY channel, the command chain is restarted again after PACKET_INTERVAL_MS which is 200 ms by default.

Once triggered, all commands runs entirely on the RF core and do not involve the main CPU. The CC13xx enters enters Standby mode in-between packet transmissions. The following image shows the characteristic current consumption profile when channel is IDLE (the radio is in RX for 5 ms):

          TX                                             TX
         ----                                           ----
         |  |                                           |  |
         |  |                                           |  |
         |  |                                           |  |
         |  |                                           |  |
      RX |  |                                        RX |  |
      ----  |                                        ----  |
      |     |                                        |     |
      |     |             Standby                    |     |
------      ----------------------------------------      ----------------
      <--------------------------------------------->
                          200 ms

If the channel is BUSY, the CMD_PROP_CS command is called 10 times. The synthesizer is kept on in between the commands.

With the default settings it takes ~250 us to determine if the channel is BUSY or not. Considering a worst case of 10 retries, the execution of the whole chain takes around 5.6 ms, including CMD_NOP and CMD_COUNT_BRANCH.

Note for IAR users: When using the CC1310DK, the TI XDS110v3 USB Emulator must be selected. For the CC1310_LAUNCHXL, select TI XDS110 Emulator. In both cases, select the cJTAG interface.

rfPacketErrorRate

Example Summary

The Packet Error Rate (PER) example showcases different RF transfer modes of the CC13xx. It combines tasks, events and several peripherals to a platform- independent application and runs on all CC13xx launchpads as well as the CC1310EM/SmartRF06.

Test cases are provided for the following RF modes:

  • 2-GFSK: Generic frequency shift keying with binary symbols, 50 kBit/s
  • LR Mode: Long-range mode
  • OOK: On-off keying
  • HS Mode: High-speed mode with up to 4 MBit/s

Peripherals Exercised

This example uses the following CC1310xx peripherals:

  • RF core for radio communication
  • 2 GPIOs for buttons
  • SPI to drive the LCD displays on the boards
  • UART0 (115200 Baud) as an alternative display on VT100-compatible terminal emulators
Peripheral Identifier CC13xxEM/SmartRF06 CC13xx Launchpad
Select button Board_PIN_BUTTON0 UP BTN-1
Navigate button Board_PIN_BUTTON1 DOWN BTN-2
Display LCD Dogm1286 Display Booster Pack

Resources & Jumper Settings

The PER application runs with default jumper settings on all supported boards.

Example Usage

This example requires two boards, each running the PER Test application. However, the packet format is identical to the default one in SmartRF Studio, so that any compatible hardware can be used as well.

  1. Connect a display to the board or alternatively, use the UART and hook it to a VT100-compatible terminal emulator at 115200 Baud. Use PuTTY or TeraTerm on Microsoft Windows. On Linux, use the terminal emulator that is shipped with your distribution. After a splash screen, you will see the main menu:

    Main Menu
    >Test: 2-GFSK
     Freq: 868.0
     Pkts: 10
     Mode: Rx
     Start...
    
  2. Navigate through the rows with BTN-2/DOWN, modify a value or start the selected test with BTN-1/UP.

  3. Use a second board with the PER test application as test companion for transmissions. Once started, the current progress is shown with these menus (TX mode on the left side, RX on the right):

    Sending...      |  Receiving...
    2-GFSK  868.0   |  HS Mode 868.0
                    |  Pkts ok   : 39
    Pkts sent: 47   |  RSSI [dBm]: -74
                    |  PER  [%]  : 17.01
                    |
                    |  Push a button
                    |  to abort.
    

The receiver prints the amount of successfully received packets (Pkts ok), the Signal strength of the current packet (RSSI) and the observed packet error rate (PER) in percent. Please note that the PER is n/a when sending more packets than configured in the receiver.

  1. You can always abort a running test case by pushing any button and go back to the main menu.

Application Design Details

The PER test application contains of one main task and an event handler to synchronize the task with buttons. After setting up all resources, the menu task is started and runs in an endless loop. It shows the menu and invokes test cases in either rx.c or tx.c.

Changelog

Version 1.1
  • released with TI-RTOS 2.17
  • add version number on the splash screen
  • hide cursor on VT100 terminals
Version 1.0
  • shipped along with the CC1310 launchpads as default application
Version 2.0
  • released with TI-RTOS 2.21
  • added support for CC2650_LAUNCHXL and CC2650DK_7ID
  • added BLE mode for CC1350 and CC2650 platforms. Note that the default frequency is 2.402MHz, which is an advertisement channel and may result in packet errors due to BLE devices advertising.
  • added custom mode which takes settings exported from SmartRf Studio into rfPacketErrorRate__settings