Please note as of Wednesday, August 15th, 2018 this wiki has been set to read only. If you are a TI Employee and require Edit ability please contact x0211426 from the company directory.

Latency Test Mode

From Texas Instruments Wiki
Jump to: navigation, search

Measure Performance

Advanced Remote

Performance is always important when designing a system. Measuring performance can however be complicated, and be done in many different ways. In a remote control system a typical metric is whether or not a key press is received by a Target. The RF4CE protocol provides several mechanisms to improve the probability of successfully transmitting a message. These include MAC layer retransmissions, backoffs to avoid collision, and network layer retransmissions. This is hidden from the application, although configurable. The default overall retransmission time is 1 second in RF4CE. This is set to define a maximum sleep period for the Target where it can still receive the message. In other words, the duty cycle for the Target is designed such that even if the Target sleeps its maximum allowed period it will still have a chance to receive a message from a Controller. A sleeping Target is only one reason why a message is not received. It can also be because of interference or the Controller being out of range. As such, measuring the average time it actually takes to send a message is a good metric for real performance. One system may define a packet as lost after 300ms, while another may define it as lost after 700ms. This will affect the effective range of the system. All of this is covered by the Latency Test Mode.

In the Latency Test Mode a configurable number of packets, typically 1000, are sent with either no delay in between, or with a random delay in between messages. The random delay can emulate a user pressing keys at different rates. Setting the delay to 0 gives the test another metric; actual throughput. Size of each message is also configurable, and a combination of these settings can determine the optimal settings for a system's optimal throughput.

During the test the Controller measures the application layer latency, and collects data in different bins. Each bin is typically 10ms wide, although this is configurable by modifying the code. An enhanced version of the test also reports the actual timestamp for message k in message k+1. This allows the Target to track the test in more detail; post process data, plot latency versus time, plot packet loss versus time, update statistics real time.

When the test has completed the Controller will either send a report automatically, or when the user presses the button mapped to HID_KEYBOARD_RETURN. The default is to wait for the user to press a key to send the report.

Automated testing can be setup where test is triggered by sending configuration to the Controller, and automatically have the remote send back the report when test has completed. To do so the test should be setup such that the test data is sent with a lower Tx power than the report. This delta in Tx power must then be considered if range is measured. Another alternative is to pair with two Targets, and send the report to a Target that is always within range.

Latency Test Mode Implementation in Sample Application

RF4CE latencyTestMode.png
RemoTI Latency Test Mode

The advanced remote controller sample application includes code for latency testing. Pressing the test mode key, mapped to RSA_ACT_TEST_MODE, circled in green/yellow, puts the application into test mode and key actions in this mode are handled differently. The radio receiver is also turned on during test mode. See rsaToggleTestModeKeyAction() for the action triggered by the test mode key.

In test mode, the key commands are handled in rsaRRTRunTest().

A timer event RSA_EVT_RANDOM_BACKOFF_TIMER is used during test mode. See RSA_ProcessEvent() for the code that handles this event.

When the test completes, the rsaState variable is changed to the RSA_STATE_TEST_COMPLETED state and the only key accepted is a key mapped to HID_KEYBOARD_RETURN user control command, which triggers sending a test report. See RSA_KeyCback() and rsaRRTSendReport() for details.

The RTI_SendDataCnf() callback function also includes logic for test mode.

In order to remove latency test mode code to reduce code size, remove rsaToggleTestModeKeyAction(), rsaRRTRunTestMode(), rsaRRTSendData(), rsaRRTSendReport(), and all references to the functions (for instance, remove RSA_STATE_TEST, RSA_STATE_TEST_COMPLETED state code from RTI_SendDataCnf()).

Latency Test Mode Implementation in Host Application on Linux

To receive test data and control the Latency Test Mode we have a Linux sample implementation. Any RemoTI-Linux Client can compile in the RTI_Testapp module. Grep RTI_TESTMODE in SimpleApp.

Module Integration

  1. Add compilation of RTI_Testmode.c to the makefile.
  2. Include RTI_Testmode.h on top of the file, #include "RTI_Testmode.h"
  3. Implement a function to return from submodule, static void appReturnFromSubmodule(){}. This function allows the RTI_Testmode module to return control to the calling module. RTI_Testmode module must be granted IO control when in test mode. Do so by routing key events to appTestModeProcessKey().
  4. Initialize the RTI_Testmode module by calling RTI_TestModeInit(appReturnFromSubmodule);
  5. Enter Latency Test Mode in one of two ways
    1. Call RTI_EnterTestMode();
    2. Receive Latency Test Mode data