Chapter 6. Direct Test Mode

Knowledge must come through action; you can have no test which is not fanciful, save by trial.


6.1. Background

One of the biggest problems with wireless systems, especially those that are designed for the lowest possible cost of production, is how to calibrate them and perform qualification and product line tests of their performance. This is especially true after the device has been packaged into another module or product, and there is no way to move aside the host stack to perform a few seconds of testing at the start of the device’s life. Direct Test Mode solves all these problems by defining standard testing procedures and a hardware interface to drive this protocol even after a host stack and other parts of the device have been incorporated in the device.

For the direct test mode to work, three devices are required (see also Figure 6–1):

• A Device Under Test (DUT)

• An Upper Tester (UT)

• A Lower Tester (LT)


Figure 6–1. Test configuration

The DUT is the controller, module, or end product that is being tested. The device must have both an antenna and a Universal Asynchronous Receiver Transmitter (UART) or Host/Controller Interface (HCI) to the UT.

The UT is typically manufactured by a test-equipment manufacturer and includes software to drive the device under test through the UART or HCI interface as well as the ability to communicate and drive the LT.

The LT is a device that can transmit and receive packets, effectively communicating with the device under test through the device’s antenna.

The device under test is told what to do by the UT and transmits or receives packets. The UT at the same time informs the LT to do the opposite; that is, to receive or transmit packets, respectively. This means that the device under test will transmit packets to or receive packets from the LT. At the end of the test, the UT can use the information available from both devices, a packet count from the device under test or more comprehensive information from the lower tester, to determine if the DUT passed the tests.

The UT can also do calibration of the controller on a production line by asking the device to transmit packets at a known frequency and measuring the actual frequency that the controller is transmitting. Typically, this is required if the external crystals used for a timing reference are not exactly at their design frequency. This crystal trimming would be done while the controller is transmitting packets, allowing very fast calibration of parts.

6.2. Transceiver Testing

To test the transceiver, the controller can either be asked to transmit or receive packets. When the controller transmits packets, it does so for a length of time determined by the tester. The tester then attempts to receive these packets and can determine various Physical Layer properties from these received packets. For example, the LT can measure the frequency drift of the device under test while transmitting. When the transceiver receives packets, it does so for another length of time determined by the tester. The tester sends a known number of packets, and the DUT just counts the ones that were correctly received. This information can be passed back to the UT when the test has completed. By doing so, the tester can determine how well the receiver has performed for a given number of transmitted packets.

6.2.1. Test Packet Format

The packet format for test packets is very similar to the advertising packet format, as described in Chapter 7, The Link Layer, Section 7.3. The access address used is the bit inverse of the advertising access address. However, given that this access address is only ever used during testing, and can never be used in a product during a typical connection, it is not a protected value such as the main advertising access address.

The test packet format uses the advertising packet header format, so the first four bits are the test packet type, and all other bits are set to zero. The test packet types that are defined include:

• PRBS9 (a 9-bit Pseudo-Random Bit Sequence)

• “11110000”

• “10101010”

• PRBS15 (a 15-bit Pseudo-Random Bit Sequence)

• “00001111”

• “01010101”

Only the first three packet types are used in the qualification test specification. However, these tests might be useful for production line testing. For all advertising packets, whitening is disabled. This must be done to allow accurate measurement of frequency deviation for the nonrandom bit sequences.

6.2.2. Transmitter Tests

The transmitter tests determine how accurately the transmitter in the DUT is performing. You can use the transmitter tests to determine frequency deviation, frequency drift, and other radio parameters that are specified.

To start the transmitter test, the UT sends a command to the DUT. This command includes three parameters that determine the test to be performed. The first parameter is the frequency that will be tested. This is the radio channel number, as defined in Equation 5-2. The next parameter is the packet payload length; valid values are 0 to 37 bytes, inclusive. The last parameter is the type of data that will be transmitted.

Three types of data in test packets can be transmitted:

1. PRBS9—Used for power transmission testing

2. 11110000—Used for frequency deviation testing

3. 10101010—Used for carrier and initial frequency testing

The PRBS9 packet sequence is a pseudo-random bit sequence that uses a repeating 9-bit sequence. It is generated by using a linear feedback shift register. The PRBS9 sequence is commonly used as a test pattern to test the performance of the radio as quickly as possible. The primary reason for using the PRBS9 sequence is that it closely resembles the random nature of whitened packets used in connections. As such, it is easily used for power transmission tests as well as receiver sensitivity tests.

The 11110000 packet sequence is a repeating sequence of four ones and four zeros. This is used to test the frequency deviation when the same bit is transmitted continuously and then moved to the other bit. The tester will be looking for a frequency deviation of over 225kHz. This illustrates why the whitening must be turned off in test mode; otherwise, the radio would not transmit repeating bits.

The 10101010 packet sequence is a repeating sequence of one and zero. This is used to test the frequency deviation when alternate bits are transmitted. This is used to perform carrier testing and for measuring the initial frequencies used in transmissions.

After the LT has received enough packets to obtain a suitable result, the UT commands the DUT to stop the test. The DUT immediately stops transmitting and returns an event to confirm that it has finished transmitting. The UT can then start another test, possibly using a different packet type, a different packet length, a different frequency, or a combination of all three.

6.2.3. Receiver Tests

The receiver test is much simpler than the transmitter test. The receiver tests are used to determine the bit error rate at various transmit power levels. This requires the LT to transmit packets at a known transmit power, typically by using a conducted antenna connection to the DUT so that uncertainty of the path loss over the air is removed from the equation. The DUT counts the number of successfully received packets and sends this information to the UT at the end of the test. The UT can then determine the resulting number of packet errors, thereby estimating the bit error rate of the receiver at the given signal strength.

To start the receiver test, the UT sends a command to the DUT. The command includes just one parameter. The parameter is the frequency that will be tested, the radio channel number, as in the transmitter tests. When the DUT receives this command, the DUT resets a packet counter to zero and starts receiving.

When the receiver receives a valid packet, the packet counter is incremented. The DUT continues to increment until the UT commands the DUT to stop the test. Once the stop command is received, the DUT immediately stops receiving and returns an event to confirm that it has finished receiving. The event includes the number of valid packets received by the DUT. The UT can then compute the performance of the receiver, based upon how many packets were transmitted and how many were received. The UT can then start another test, possibly using a different frequency or at a different transmit power.

6.3. Hardware Interface

To enable very efficient and device-independent testing of modules, possibly from multiple controller manufacturers, a standardized hardware interface is defined that can be used by UTs. The hardware interface is a simple two-wire UART that has a single line for transmitting bits from the UT to the DUT, and another line for transmitting bits from the DUT to the UT. It is expected that module manufacturers and end-product manufacturers will expose two pins or pads that can be connected to the UT on a production line to allow for calibration and verification of an individual product’s ability to transmit and receive.

6.3.1. UART

UARTs are typically very flexible in how they can be configured. To reduce the problem of an incompatible interface, the Direct Test Mode UART only has one configurable parameter: baud rate.

The baud rate for the DUT can be one of the following values: 1200, 2400, 9600, 14400, 19200, 38400, 57600, or 115200. The typical rate is 38400 because this is a good compromise between efficient command and event transfer and implementation cost.

The rest of the UART parameters are very standard. Each byte is 8 bits in length, sent with no parity, and one stop bit. There is no flow control, either software or hardware. Obviously, it is impossible to do hardware flow control because there are no hardware flow control wires. Software flow control is also not required because a command or event is only a maximum of 2 bytes in length and only one command can be sent at a time. The final design parameter is a common ground. It is assumed that there is a common ground between the two devices.

To send a command or event, 2 bytes of data must be sent a maximum of 5 milliseconds apart. Once a command is sent, an event must be returned within 50 milliseconds. This ensures that the DUT starts and stops tests in a timely manner, and therefore, the accuracy of any counting is easily validated.

6.3.2. Commands and Events

Four commands can be sent from the UT to the DUT:

• Reset

• Transmitter Test

• Receiver Test

• Test End

Two events can be sent from the DUT to the UT:

• Test Status

• Packet Reporting

The reset command does exactly as it says. It stops the controller at whatever point it is located; if the controller was transmitting or receiving test packets, it must stop. It also places the controller into a known good state. It immediately returns a test status event to confirm that everything is back to the quiescent state. Only 2 bits within the reset command are used; all other bits are ignored.

The transmitter test command starts the transmitter test. This includes the three parameters: frequency, length, and packet type, as shown in Figure 6–2. Once this command is received, the DUT sends a test status event and starts transmitting packets using the parameters. If for some reason the device cannot transmit packets, the DUT still returns the test status event but sets the status bit to denote an error. If the transmitter test command failed to start, the UT would need to reset the DUT to place it into a known good state.


Figure 6–2. The Direct Test Mode command bit structure

The receiver test command starts the receiver test. This includes the frequency parameter; all other bits in this packet are ignored. Once this command is received, the test status event is returned and the DUT starts receiving packets on the desired frequency. Again, if the device cannot receive any packets, the test status event is returned with the status bit showing an error.

After a successful transmitter or receiver test, the test end command can be sent by the UT to stop the test. When this command is received by the DUT, it immediately stops what it was doing and returns the packet reporting event. If the receiver test was being run, this packet-reporting event includes the packet count for the successfully received packets (see Figure 6–3). If the transmitter test was being run, this field in the event is set to zero because no packets are received in the transmitter test. After the packet-reporting event is received, the UT can start another test by using another test command.


Figure 6–3. Direct Test Mode events reporting bit structure

The test status event only defines a single bit. If this bit is zero, the test command was successful. If this bit is one, the test command failed for some reason. There are two possible reasons a test command fails:

• The controller is in a state that confuses it, and a reset is probably the most suitable next step for the UT.

• The controller doesn’t support the test, probably because it doesn’t have either a transmitter or receiver. (Although it possible to test the receiver of a transmitter-only device.)

It is not possible to determine from this command set if the DUT supports a given test; a UT can only try each test and determine the status.

The packet-reporting event is used to report that the test completed. It includes a single 15-bit packet count of the number of successfully received packets. This packet count will always be zero for transmitter tests, but can be any value from 0 to 32,767 for receiver tests. The DUT doesn’t worry about overflow of the packet counter; if the packet counter overflows, a test that might have taken a very long time can determine that only one packet was received, even though 32,769 packets were actually received. UTs should therefore only run tests for a duration that would not cause overflow of the packet counter.

6.4. Direct Testing by Using HCI

It is also possible to reuse the existing HCI transports (see Chapter 8, The Host Controller Interface, Section 8.2) and logical interface to exercise direct test mode on a controller. This does require more infrastructure to be in place, especially if the host interface is complex. However, for controllers that are being individually tested—as opposed to being within a highly optimized module design or end product—this is a very valid approach.

The test procedures are identical, except that instead of sending 2-octet commands and events, full HCI commands and events are sent. The mapping of the HCI commands and events to the Direct Test Mode commands and events is shown in Table 6–1.

Table 6–1. HCI to Direct Test Mode


There is no dedicated test status event or packet reporting event when using HCI because the Command Complete already performs this function, includes an opcode to determine which command triggered this Command Complete, and has differing parameters, depending on this command.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.