Skip to content

Using the Speed Test feature

thedjnK edited this page Aug 24, 2017 · 3 revisions

The speed test functionality of UwTerminalX can be used to test the throughput of a serial connection with or without testing the integrity of the data. Please ensure you are using the latest version of UwTerminalX for speed testing (v1.09 at the time of writing) as previous versions have smaller datatypes which can overflow easier when testing for longer periods of time or with faster data-rates.

Please note that this feature requires a fast CPU for processing the data and is not recommended for use with the raspberry pi or mac osx versions of UwTerminalX - the raspberry pi can run the test but the throughput is limited to ~700kbps (raspberry pi 1) or ~900kbps (raspberry pi 3). OSX testing displays frequently corrupt data when there is nothing wrong with the data, please forward all questions regarding this issue to apple developer support on https://developer.apple.com/support/

The setup of the test depends on what functionality you would like to test, a test can be as single as a loopback serial device connected via USB:

Direct UART loopback

Or could use a BL600 with a smartBASIC application acting as the loopback device:

BL600 UART loopback

Alternatively, multiple instances of UwTerminalX can be used to test both the UART and BLE systems with two BL652s:

Dual UwTerminalX instance with BL652 to BL652 over BLE

Or two BT900s for UART and SPP/BTC throughput:

Dual UwTerminalX instance with BT900 to BT900 over SPP (BTC)

Note that only one PC/laptop is required for speed testing as two instances of UwTerminalX can run on the same system. Applications required for the speed test should be downloaded, executed and setup prior to starting the throughput testing, for BLE testing on the BL652, applications $autorun$.dle.data.length.extension.central.sb and $autorun$.dle.data.length.extension.peripheral.sb can be used (available from the BL652-Applications github repository in the Applications folder https://github.com/LairdCP/BL652-Applications/tree/master/Applications) and for SPP BTC testing on the BT900, applications $autorun$.SPP.UART.bridge.incoming.sb and $autorun$.SPP.UART.bridge.outgoing.sb can be used (available from the BT900-Applications github repository https://github.com/LairdCP/BT900-Applications)

On the main speed test page, various options can be see to configure how the test runs:

UwTerminalX speed tab

Along the top are similar icons as in the terminal page for displaying the current CTS, DSR, DCD and RI pin statuses with checkboxes for toggling the status fo RTS and DTR. Next to this are options for showing the RX/TX data if desired (this can create a large amount of data in the window) and an option for showing errors which will appear in the bottom text area (the clear button will clear any text in this area).

Slightly below is the data type dropdown which allows selecting between 'String' (sending, receiving or both) or 'Speed only' (receiving only without testing the integrity of the data), the display dropdown allows adjusting the units of the fields between bits (the total number of bits per character, 8-bits for the ASCII character, the start/stop bits and any bits for parity), data bits (excluding all other bits, 8-bits for each ASCII character) or bytes - which can be changed on the fly whilst the test is running. The data field specifies the data to send/receive for the test, there is a checkbox next to it which allows un-escaping of chracters in the string, for example if a\4Cb was used as the string and the checkbox was checked then the data sent/received would be 3-bytes (aLb), if it was unticked it would 5-bytes (a\4Cb) - if running multiple instances of UwTerminalX for the speed test then these fields must match. UTF-8 data is fully supported by the speed test system.

There is a single button to start/stop the speed test which opens a dropdown menu - a recieve only test sends no data and just shows statistics for the data received on the serial port, a send only test just sends data but doesn't check the received data and a full send/receive test does both. There are options for delaying the speed test by 5, 10 or 15 seconds which can be used if multiple instances of UwTerminalX are running or if the test is being performed over multiple systems: the data will not start being sent until the displayed time has elapsed but any data received before then will be checked by the speed test (If the 'Sync receive time' checkbox is ticked then the timer for the receive data will only start once data has been received by UwTerminalX, otherwise the timer will start as soon as the test is started, which may show a reduced received data-rate value).

Once the test has started, the system can be left as long as needed until the testing is complete although system suspension/hibernation should be disabled so that the system does not power off whilst the test is running. If any errors are found during the test, they will be shown on the screen in the bottom text area with information including the expected and actual data, the time the error occured and position of the mismatch:

UwTerminalX speed test showing an error

The error rate is the percentage of failed packets received in the test, not the BER (Bit Error Rate) as the test works by using the start and end delimiter of the supplied data, if an error is found then it will search for the next start delimiter.

Once the cancel button is clicked, data will stop being sent but will continue to be received until 5 seconds elapse or the cancel button is clicked again, this is to allow time to capture data that may still be stored in the buffers. The data-types are 64-bit with v1.09 of UwTerminalX and newer which should allow for running extended tests without issues:

UwTerminalX speed testing showing longer-term testing

The copy stats button will copy information and statistics from the current test which can be emailed or uploaded to share the statistics with others, for example:

=================================
  UwTerminalX 1.09 Speed Test
       24/08/2017 @ 14:05
---------------------------------
Settings:
    > Port: [COM207:3000000,N,8,1,H]{cr}
    > Data Type: String
    > Data String: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!"£$%^&*()_+-=[]{};:'@#~,<.>/?\|¬`
    > Data String Length: 96
    > Data String Size (bytes): 98
    > Unescaped Data String: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890!"£$%^&*()_+-=[]{};:'@#~,<.>/?\|¬`
    > Unescaped Data String Length: 96
    > Unescaped Data String Size (bytes): 98
    > Unescape: Yes
    > Send Delay: 0
    > Synchronise receive timer: Yes
    > Receive Delay: 0
    > Test Type: Send/Receive
---------------------------------
Results:
    > Test time: 24:59:19.25
    > Tx (Bytes): 0
    > Tx (Data bits): 0
    > Tx (All bits): 236911945340
    > Tx last 10s (Bytes): 2693922
    > Tx last 10s (Data bits): 21551376
    > Tx last 10s (All bits): 26939220
    > Tx average (Bytes): 263353
    > Tx average (Data bits): 2106830
    > Tx average (All bits): 2633538
    > Rx (Bytes): 0
    > Rx (Data bits): 0
    > Rx (All bits): 236911928280
    > Rx last 10s (Bytes): 2690304
    > Rx last 10s (Data bits): 21522432
    > Rx last 10s (All bits): 26903040
    > Rx average (Bytes): 263353
    > Rx average (Data bits): 2106829
    > Rx average (All bits): 2633537
    > Tx (Packets): 241746890
    > Tx last 10s (Packets): 27489
    > Tx average (Packets): 2687
    > Rx (Packets): 241746865
    > Rx last 10s (Packets): 27452
    > Rx average (Packets): 2687
    > Rx Good (Packets): 241746865
    > Rx Bad (Packets): 0
    > Rx Error Rate % (Packets): 0
=================================
Clone this wiki locally