1.
Sebastian Cheah A53081673
Roger Huang A09230317
Final Report
Overview
This report is both an analysis of time synchronization between two BeagleBone Blacks (BBBs) each with a
Zigbee Xstick for wireless communication capabilities and an application description that utilizes a wireless
system with high resolution for time synchronization between two nodes. The following report is organized as
follows: an application description, an analysis of time synchronization, our implementation, our methodology
of characterization, the characterization of our initial implementation, potential optimizations, the
characterization of the optimized implementation, and finally a conclusion to our project.
Application
When nodes can be time synchronized with high resolution there are many applications that can utilize this
capability. We decided to apply time synchronization as a security authentication method. One node in the
system will expect to receive keys during a specific window of time. If the keys are not received in the window
of time, the authentication fails. All keys must therefore transmit accurately in timing according to a master
clock. This application can thus only be accomplished if the nodes in the system have a high degree of time
synchronization between each other. As the time synchronization accuracy between the nodes improves, the
window of key acceptances can shrink and the validity of authentication through this method improves.
Analyzing time synchronization through delay and offset statistics
We use an algorithm based off of the Network Time Protocol (NTP) clock synchronization algorithm. We
perform a round trip communication between coordinator and end point. We store four specific time stamps:
● t​0​ is the coordinator’s timestamp of the request packet transmission
● t​1​ is the end point’s timestamp of the request packet reception
● t​2​ is the end point’s timestamp of the response packet transmission
● t​3​ is the coordinator’s timestamp of the response packet reception

2.
Using these time stamps we can calculate the offset between coordinator and end point time, and the round
trip delay due to the ZigBee communication.
● ffset θ ) (t )] / 2O = = [(t1 − t0 − 2 − t3
● elay δ t ) (t ) D = = ( 3 − t0 − 2 − t1
With these calculated statistics, we can come up with a plan on synchronizing an event between BeagleBone
Black boards over the ZigBee network.
Implementation details
To implement our authentication system we utilize two BeagleBone Blacks (BBB) and two Zigbee Xstick usb
modules to enable a wireless serial link between the two BBB. Our system is written using the GO language
platform and utilize the time, format, OS, syscall, unsafe, and a C library for getting cycle counts. For simplicity,
the two BBB are set to run at 1 Ghz, which results in a 1 nanosecond clock period. Using this simplification, we
can easily convert number of cycles to a time duration in nanoseconds.
The first thing our two node system does is synchronize their times with each other. This is described in the
previous section under “Analyzing time synchronization through delay and offset statistics.” Once the two BBB
have been synced with each other, one board sends the request for key authentication to be received
sometime in the future from now. Prior to sending the request, the coordinating board will begin a cycle timer
to enforce the lower bound requirement within the acceptance window. The cycle timer is implemented
through constantly calculating the difference in cycle counter values until the difference is equal or greater
than the necessary time. If the key is received before the timer expires then the authentication fails. On the
other end, the second BBB in our system receives the key request and will wait until the appropriate amount
of time based on the time synchronized information of the system before sending the key over to the
coordinating BBB. The waiting is implemented through the same methodology as the cycle timer in the
coordinating board. Calculating the difference between cycle counter reads proved to be significantly more
accurate than using any kind of sleep function provided by either the C language environment or the Go
language environment. The coordinating BBB then checks to make sure that the key is received within the
upper bound of the acceptance window. If the key is not received during the specified period (as enforced
through the lower bound timer and the upper bound timer), the authentication mechanism fails. More
information concerning window size and other system characteristics can be found in the characterization
sections.
In our implementation, we have determined that the offset that was calculated during time synchronization is
unnecessary for coordinating our synchronized event of key authentication. This simplification is due to the
timing characteristics of the two BBB. Because each BBB is set to run at the same frequency, the time
progression is identical in each of the boards. Therefore a fixed delay in one board represents the same fixed
delay in the other board. The only corrections that have to be applied in the receiving board is to account for
the delays of transmitting information wirelessly from one BBB to another BBB through the Zigbee stack.
The demo portion of our application involves triggering an event of some kind depending on the success of the
authentication. Our demonstration uses two LEDs through two GPIO ports on the coordinating BBB. When the
application is locked, one of the two LEDs will be on. When the application is unlocked through authentication,

3.
the other LED will turn on and the previous LED that was on will turn off. Part of the demonstration will show
how without timing synchronization the authentication mechanism fails. With timing synchronization
however, the authentication succeeds and the application can be unlocked.
Methodology of characterization
To characterize our system, we utilized cycle counter values. The cycle counter is initialized before the block of
code that was targeted for analysis and read again afterwards. The difference in values equates to roughly the
execution time of that sequence of code in nanoseconds because each clock cycle is one nanosecond long in
duration. Therefore if the difference in counter cycles measured was 100,000 cycles then the respective
execution time is roughly also 100,000 nanoseconds. This allowed us to get a baseline understanding of where
majority of the delays in our system come from.
The characterization of our system that we were interested in was characterizing the round trip time. The
round trip time is just the delay portion of the round trip delay as explained in the time analysis section above.
For this calculation, we repeatedly exchange time stamps and measure the delay for the process. Each of the
delays is stored in an array and used to calculate the median of the delays. The median of all of the recorded
delays was calculated by first sorting our array of values and then calculating the average between the middle
two elements in the array. In our experimentation, the median proved to be a better value to use than the
average which can be heavily influenced by outliers in our data collection. Once the median is calculated, the
jitter within our application could be computed by calculating the absolute value of the recorded delay and
the median delay. As our system became more optimized, the values calculated here for the round trip delay
and the associated jitter would decrease. In characterizing the application, one hundred samples were taken
for round trip delays for exchanging timestamps. The results of our characterizations can be found in the
following sections for before and after optimization techniques were applied.
Characterization of initial implementation
Average Round Trip Delay 257806000 ns 257.806 ms
Average Jitter to Round Trip Delay 59287139 ns 59.287 ms
Acceptance window Size 500 ms

4.
As seen from the table and graphs provided, the performance of our initial implementation is not that great.
The round trip delay measurements are quite large and the minimum and maximum values differ significantly.
The jitter associated with the delay is also unstable in our initial implementation. Because of all of these
variances in our delays and jitter values, the acceptance window in our initial implementation was quite large.
The large acceptance window size ensures that our authentication application succeeds.
One issue regarding the Zigbee protocol was left unsolved in our initial version of the application. For some
reason when collecting data, our application tends to stall after just four iterations. This makes it extremely
difficult to gather enough samples for behavior analysis. The samples are the round trip delays related to
simply exchanging timestamps between each of the boards. After exchanging timestamps four times, our
application stalls for awhile before resuming, at which point the progress through our testbench application is
sporadic. Instead of a linear continuous execution stream of progress, the application manages to only finish
between two to six iterations at a time before stalling. The benchmark application for delay analysis is meant
to repeatedly exchange timestamps one hundred times from which the median and jitter can be calculated.
Potential Optimizations
We first begin analyzing the data path beginning from running a GO application until a message is sent from
the BeagleBone board. Along the way, there could be optimizations applied to the GO application to optimize
the run time performance. (compiler etc). We must also consider when we send a message through the USB to
Serial driver. We identify this driver as:
Bus 001 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB‐Serial (UART) IC
There is a USB to Serial latency issues that can arise and be improved upon. In a USB to serial converter, the
FTDI chip buffers data it receives until either the buffer is full, or until a timer triggers the buffer to flush
because no data has come on the serial port for a fixed amount of time. As such, we need to consider the
latency timer and the block request size. Default values for these parameters are 16ms and 4096 bytes
respectively. The USB buffers packets of fixed size 64 bytes at a time. As such, latency can be calculated as the
following:
aximum Latency latencyTimer lockRequestSize/64M = * b
With the default parameters, latency can be at most 1.024 seconds. This presents an opportunity for
improvement. Instead of using the default parameters, we can instead use customized parameters tailored to
our particular application. Our application communications with small packet sizes, so a latency timer of 1ms
and block request size of 64 bytes would be the best available values to change to. This change would involve
either modifying the current USB driver onboard the BBB or interfacing the BBB with another compatible USB
driver that could be modified for the specific application.
There are two specific methods to interface with the FT232 USB UART: through the Virtual COM Port (VCP,
which runs by default onboard the BBB) or through D2XX drivers. D2XX drivers provide a useful interface for
setting the latency timer and block request size. We set these values to 1ms and 64 bytes respectively.

5.
However, the library is written in C, so we may incur some overhead using this method. Also, the VCP interface
cannot run concurrently with D2XX drivers, so applications have to be specifically written using the libftd2xx
library to interact with the serial port. On the other hand, VCP can be naturally accessed through Golang, but
does not provide an accessible way to change the latency timer or block request size. An alternative would be
to modify and rebuild the driver module (ftdi_sio), but BBB does not provide the source complying with its
kernel source, so we did not ultimately pursue this approach.
Other than the application itself, there are optimizations that can be done for the environment that the
application runs within. On the BBB, there are many background processes that active but unnecessary
towards our application. These processes can be viewed using the command “ps ‐A ‐l” at the command
prompt. By removing these unnecessary processes, our application can have access to more of the resources
onboard the BBB. In addition, it is also beneficial to increase the priority of relevant processes to increase the
performance of the application. This was done using the “nice” and “renice” commands to set priority levels.
There are two lists below that display what processes were killed and which processes gained priority when
running our application. Each table also contains an explanation for why they could be killed or why they were
chosen to be prioritized.
Processes that were killed:
pkill ‐KILL avahi‐daemon
pkill ‐KILL wpa_supplicant
pkill ‐KILL console‐kit‐dae
pkill ‐KILL lightdm
pkill ‐KILL xrdp
pkill ‐KILL Xorg
pkill ‐KILL cron
pkill ‐KILL apache2
pkill ‐KILL udhcpd
pkill ‐KILL wicd
pkill ‐KILL menu‐cached
pkill ‐KILL udisks‐daemon
Processes that gained priority (when using ttyUSB0):
renice ‐n ‐20 `pgrep ksoftirqd/0`
renice ‐n ‐20 `udevd`
when executing our application use: nice ‐n ‐20 ./{application_name}
The final optimization that could be done for our application involved modifying the firmware of the Zigbee
USB module. During the initial development of the initial implementation, the Zigbee modules were set with
some default firmware settings. For the purposes of getting a basic application to function the communication
channel between the two Zigbees was slow but functional. Upon inspection of the firmware settings, it was
discovered that the endpoint module destination address for transmission was all zero and the destination
address for transmission on the coordinator module was all Fs. In other words the two modules were set to
broadcast settings instead of a point to point communication channel. Once the destination addresses for

6.
each of the Zigbee modules was set to correspond to the address of the other module, a point to point link
was established and performance should improve.
Characterization of final optimized implementation
One issue that is still unresolved is related to starting up the Zigbee stick on the endpoint board. After the
board powers up, the Zigbee stick maintains a solid LED. However, once our application is executed for the
first time the LED turns off for some undefined duration before powering back on. We currently do not have
an explanation for this particular behavior between the USB module and the BBB.
TTYUSB0
(VCP)‐broadcast
TTYUSB0 (VCP)‐P2P D2XX
Average Round Trip
Delay
259222500 ns / 259.223
ms
42118500 ns / 42.119 ms 63595000 ns / 63.595 ms
Average Jitter to Round
Trip Delay
55505158 ns / 55.505 ms 6755530 ns / 6.756 ms 2326480 ns / 2.326 ms
Window Size 500 ms 100 ms 100 ms

7.
As seen from the table and graphs provided above, the most significant gains in performance came from
switching from broadcast mode on the Zigbees to a point to point communication link. Using a point to point
(P2P) link in combination with eliminating unnecessary processes while simultaneously increases the priority
on our own application, we were able to get significant gains in performance. Average delay decreased by a
factor of around 6 while average jitter decreased by a factor of 9. The entry for D2XX refers to the use of our
modified usb driver instead of the built in default usb driver on the BBB. There is a trade off in terms of delay
and jitter when using our custom usb driver instead of the default driver. When using our custom driver, the
average delay increases as compared to when using the original driver. However, using our custom driver
results in better jitter control.
Conclusion
In this report we have demonstrated a method for obtaining timing synchronization as well as the utility of
having a system with a high degree of timing synchronization precision. Of the many kinds of applications that
timing synchronization enables, our application is from a security authentication perspective. With a very
narrow timing window for accepting valid keys, timing synchronization enables a high degree of security. The
chances of the system receiving a false positive is significantly lowered as the timing window is compressed.
Through proper authentication, applications may be unlocked, events may be enabled or triggered, and
security mechanism can be enforced.
References:
http://www.ftdichip.com/Support/Documents/AppNotes/AN232B‐04_DataLatencyFlow.pdf
http://www.eecis.udel.edu/~mills/ntp/html/warp.html
http://www.ftdichip.com/Support/Knowledgebase/index.html?howcaniopenaportonthef.htm
http://www.ftdichip.com/Support/Documents/ProgramGuides/D2XX_Programmer's_Guide(FT_000071).pdf