rfSynchronizedPacketTx Example
Example Summary
In this example you will learn how to build a time-synchronized connection between one transmitter and a receiver. Time-synchronization enables both communication partners to transfer data quickly at predictable time points. Unlike the wake-on-radio example, the transmitter does not need to send a very long preamble and the receiver does not need to wait and check for a signal on air. This leads to the lowest possible power consumption on both sides. It also fits very well to the SimpleLink Long-range mode. Time synchronization builds also the foundation for Frequency and Time Division Multiple Access, FDMA and TDMA respectively.
This example project shows the transmission part. The receiver part can be found in the Synchronized Packet RX example.
Peripherals Exercised
BUTTON1
- Toggles the state ofLED1
and sends a message in spontaneous beacon state.BUTTON2
- Toggles between periodic and spontaneous beacon state.LED1
- Toggled whenBUTTON1
is pushed.LED2
- On while data is being transmitted over the RF interface (PA enable), off when in standby.
Resources & Jumper Settings
This section explains the resource mapping across various boards. 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>.
SmartRF06 in combination with one of the CC13x0 evaluation modules
Resource | Mapping / Notes |
---|---|
BUTTON1 |
BTN_UP (up button) |
BUTTON1 |
BTN_DN (down button) |
LED1 |
LED1 |
LED2 |
LED2 |
CC1310 / CC1350 / CC2640R2 Launchpad
Resource | Mapping / Notes |
---|---|
BUTTON1 |
BTN-1 (left button) |
BUTTON2 |
BTN_2 (right button) |
LED1 |
Green LED |
LED2 |
Red LED |
Board Specific Settings
- The default frequency is:
- 433.92 MHz for the CC1350-LAUNCHXL-433
- 433.92 MHz for the CC1352P-4-LAUNCHXL
- 2440 MHz on the CC2640R2-LAUNXHL
- 868.0 MHz for other launchpads In order to change frequency, modify the smartrf_settings.c file. This can be done using the code export feature in Smart RF Studio, or directly in the file
- On the CC1352P1 the high PA is enabled (high output power) for all Sub-1 GHz modes by default. The user must set USE_SUB1_HIGH_PA_SETTING to 0 in smartrf_settings.h and smartrf_settings_predefined.h, and rebuild the example, to disable the high PA and use the default PA
- On the CC1352P-2 the high PA operation for Sub-1 GHz modes is not supported
- On the CC1352P-4 the default PA is used for all Sub-1 GHz physical modes by default. The user must set USE_SUB1_HIGH_PA_SETTING to 1 in the smartrf_settings.h and smartrf_settings_predefined.h, and rebuild the example, to enable the high PA (high output power) CAUTION
- This will change the center frequency for 2-GFSK to 490 MHz
- The center frequency for SimpleLink long range (SLR) stays at 433.92 MHz, but the high output power violates the maximum power output requirement for this band
- This will change the center frequency for 2-GFSK to 490 MHz
- The CC2640R2 is setup to run all proprietary physical modes at a center frequency of 2440 MHz, at a data rate of 250 Kbps
Example Usage
This section is similar for both TX and RX. You need 2 boards: one running the rfSynchronizedPacketTx
application (TX board) and another one running the rfSynchronizedPacketRx
application (RX board).
Initial synchronization
Build and run the
rfSynchronizedPacketRx
example on the RX board. You will seeLED2
on the RX board being on all the time.Build and run the
rfSynchronizedPacketTx
example on the TX board. You will seeLED2
on the TX board flashing with a period of 500 ms. On the RX board, you will see thatLED2
is flashing synchronously.Push
BUTTON1
on the TX board.LED1
will toggle immediately. On the RX board,LED1
follows after a short delay.You may push
BUTTON1
several times and will see thatLED1
on the RX board will always reflect the state on the TX board with some delay.
Explanation: After starting, the RX board goes into WaitingForSync
state. The receiver is switched on end waits for a packet. The LNA signal (LED2
) is enabled to reflect the current receiver state.
When the application on the TX board is started, it starts to send periodic beacon messages. Once the RX board has received the first beacon message, it switches the receiver off and goes into SyncedRx
state. In this state, it wakes up the receiver right before the next packet from the TX board is expected.
When BUTTON1
on the TX board is pushed, the current LED state is sent in the next available time slot and is shown on the RX board as soon as the packet has arrived.
Sending spontaneous beacons after synchronization
Push
BUTTON2
on the TX board. You will see thatLED2
on the TX board stops flashing whileLED2
on the RX boards remains flashing.Push
BUTTON1
on the TX board. You will see thatLED1
toggles on the TX board and with a short delay also on the RX board.LED2
on the TX board will flash a short while after pushing the button.
Explanation: After pushing BUTTON2
on the TX board, the TX application goes into SporadicMessage
state and stops sending periodic beacons. The RX application remains in SyncedRx
state and wakes up when it expects a packet. As long as no button on the TX board is pushed, the RX board will wake up only for a short time and go back to standby after a very short timeout because no packet is received.
When pushing BUTTON1
on the TX board, a packet with the new state of LED1
is transmitted. The TX board sends exactly at the same time when the RX board expects to receive a packet. The RX board receives the message and updates the state of its own LED1
.
Error handling: Resynchronization due to crystal drift ===
Repeat step 6 for a while. After a couple of minutes, you will notice that
LED1
on the RX board is not updated properly anymore.Push
BUTTON1
on the RX board.LED2
will remain on permanently.Push
BUTTON1
on the TX board. You will seeLED1
toggle on both boards andLED2
on the RX board starting to flash again.
Explanation: Both TX and RX board predict the following wake-up events based on the time when synchronization happened. If both clocks have a small drift, then the wake-up time will be incorrect after some time.
By pushing BUTTON1
on the RX board, the application goes back into WaitingForSync
state and re-synchronizes to the TX board.
Application Design Details
This examples consists of a single task and the exported SmartRF Studio radio settings. The TX application is implemented as a state machine with 3 states:
In order to send synchronous packets, the transmitter uses an absolute start trigger for the TX command. Absolute start triggers are explained in the proprietary RF user’s guide and the technical reference manual. It starts with an arbitrarily chosen time stamp:
/* Use the current time as an anchor point for future time stamps.
* The Nth transmission in the future will be exactly N * 500ms after
* this time stamp. */
RF_cmdPropTx.startTime = RF_getCurrentTime();
And then adds a fixed interval for any further transmission:
/* Set absolute TX time in the future to utilize "deferred dispatching of commands with absolute timing".
* This is explained in the proprietary RF user's guide. */
RF_cmdPropTx.startTime += RF_convertMsToRatTicks(BEACON_INTERVAL_MS);
In SpontanousBeacon
state, the next transmission start time is calculated based on the last value transmission start time:
/* We need to find the next synchronized time slot that is far enough
* in the future to allow the RF driver to power up the RF core.
* We use 2 ms as safety margin. */
uint32_t currentTime = RF_getCurrentTime() + RF_convertMsToRatTicks(2);
uint32_t intervalsSinceLastPacket = DIV_INT_ROUND_UP(currentTime - RF_cmdPropTx.startTime, RF_convertMsToRatTicks(BEACON_INTERVAL_MS));
RF_cmdPropTx.startTime += intervalsSinceLastPacket * RF_convertMsToRatTicks(BEACON_INTERVAL_MS);
That means, the transmission is not really “spontaneous”, but rather “as soon as possible” according to the interval. A safety margin of 2 ms is added because the RF core is powered down while waiting for the RX command. If we are close to the next slot, the RF driver would not have enough time to re- initialize the RF core.
No further timing restrictions apply to the transmitter.