Bluetooth Performance Tests (Compact 7)
3/12/2014
This test will verify and record timings for Bluetooth RFCOMM data transfer using various buffer sizes.
Each iteration of the test does the following steps:
1. Connect Device Under Test (DUT) and PEER
2. Send the same amount of data (n iterations) for each packet size:
* 16 byte
* 512 bytes
* 1024 bytes
* 2048 bytes
3. Tear Down connection
Test Prerequisites
Your device must meet the following requirements before you run this test.
Hardware:
* One host machine using Platform Builder (PB) to connect to Windows Embedded Compact devices
* Two Windows Embedded Compact devices (DUT and PEER)
* Bluetooth radio, such as a Bluetooth USB dongle, installed in DUT and PEER
* MAC address of the PEER device must be known
Software:
* Remove adapters from the two devices (BTPAN, etc.)
* Bluetooth test dll perf_bluetooth.dll must be present in the release directory
* Delete the BTPerf.xml from any previous runs
Subtests
This test has no subtests.
Setting Up the Test
1. Boot the DUT and PEER
2. Verify the BT adapter is present and discoverable (Method is unique to the reference implementation)
Running the Test
1. From the PEER execute " s tux -o -d perf_bluetooth -c "-i 10 -p 12 -b 163840"
2. From the PEER verify the line containing " ** RFCOMM ** localhost< " lists the MAC address for the PEER's BT radio.
3. From the PEER verify " ** RFCOMM ** Accepting... " is the last line present
4. From the DUT execute " s tux -o -d perf_bluetooth -c "-i 10 -p 12 -b 163840 -s <PEER BT MAC Address> -r -c"
5. From the DUT verify the Tux tests are running
Verifying the Test
* The Tux output on the DUT and PEER must both show 1 test case passed.
* The throughput graphs should have data <= 3 MBps
Troubleshooting the Test
1. If the DUT cannot connect to the PEER:
* verify the BT service was on and discoverable on both devices
2. If the DUT tux fails for parsing the command line:
* Make sure the PEER BT MAC address does not have a preceding 0x. Example (000a3a7321e5)
* Make sure the PEER BT MAC address is the correct length
3. Command line options:
* -i iterations 10 is enough for performance measurements (more than ten has not been verified)
* -p serverChannelNumber RFCOMM channel at which server is listening. Must match on the DUT and PEER
* -s serverAddress Bluetooth address of server or peer device in 12-digit hex format. Do not use an initial 0x
* -r Perform gap analysis
* -b numberOfBuffers Number of buffers to transfer for data transfer stress test
* -c use current directory for perf output file
For additional platform specific issues, consult the CTK articles on the TechNet wiki.