4.4 Results

The UWB demo kit is used to implement the demo software application for the secure data communication. The following figure illustrates the kit with the Receiver/Prover and Transmitter/Verifier boards. Both SAMC21 XplainedPro boards are connected to a PC using their virtual COM port with the settings: baudrate=115200, 8-bit data, no parity and 1 stop bit. A PC terminal application is connected to both COM ports to stream-out the program flow information. The OLED1 at the Transmitter/Verifier also shows the actual data communication status with SC, RC and distance in [cm].

The following figure illustrates the PC Terminal window output from the transmitter/verifier and from the receiver/prover during data communication exchange.

The transmitter/verifier TX window shows (for each data packet exchange): the SSID, counters and MAC data, in addition to the calculated distance (in cm), the clock offset (in ppm) and the selected TCK. The receiver/prover RX window shows the received SSID, the result of the FEC proof, the MAC₀ from the data packet and the calculated MAC₀c, the counters and the received data payload with the first and last data byte (Byte 6 and Byte 55). If an incorrect data telegram is received (SSID mismatch), only the SSID displays in the window (see Figure 4-6 )

In the TX window, recovering the handling of the MAC₀, MAC_-1 and RNRp data can be followed. The MAC_-1 data from the previous cycle must be the same as the prover RNRp data received by the verifier. In the RX window, the received MAC₀ data from the data telegram must match the calculated MAC₀c and the received verifier RNR_v data at the prover, while the MAC_-1 is the data from the previous cycle.

A new data telegram is sent every 500 ms by the transmitter.

If there is a communication error, the handling with the RC is as follows. The following figure illustrates the recovery of the data communication. At the position with SC=18, the resend operation is shown with RC=1 and 2 because of an error from the FEC calculation (bit error in the communication data telegram). The prover responds with an error code RNR_p = MAC_-1= 99999999, which results in incorrect decoding of the RNR_p value at the verifier due to a mismatch between the settings of the verifier and prover. This is answered by the verifier with a resent packet, which can also be seen by the same received payload data[6…55]=( 82…131).

The following figure illustrates the restart mechanism. Due to errors at the verifier err =1 and in the FEC and the prover with err = 2, the RC counts up to the limit > 20 and forces a restart with SC=0 and RC=21.

The measurements above are performed as conducted measurements for the RF signal with a damping element. At an RF damping of ~70 dB, the errors as shown in the Figure 4-6 occur, while the measurements for Figure 4-5 are performed with a damping of ~68 dB. The reduction of the overall LB with about 5 dB to 6 dB is caused by using three data packets for one communication cycle. This increases the BER and reduces the LB when compared to the measurements shown in Table 2-2, where only one data packet transfer is measured.

Testing of the LB with conducted measurements and TX power setting at the regulation limit of the average transmitted power of -41.3 dBm/MHz yields an LB of ~60 dB.

The LB can be improved in general by implementing an FEC like RS coding to correct the bit errors in the communication data packet. In the demo application, no bit error correction is implemented. Only the bit errors occurring in the data packet are shown by using a CS checking scheme (see Figure 4-6 with the FEC wrong indication).

The duration of one communication cycle strongly depends on the processing time for the data encryption, the FEC coding, bit error correction and the MAC calculation. These algorithms can be implemented in the application software or by using hardware components, either as integrated blocks in the MCU or with external ICs. The SPI clock for communication, the UWB device, has an impact on the cycle time, meaning, to read and write the data payload. The following execution times are assumed with the demo software:

Total per cycle – 6.9 ms

This cycle time includes the data transfer of the 50-byte payload and the distance measurement between the devices.