App Note: Bluetooth Application Debugging Using the Bus Utilization Graph

Introduction

The bus utilization graph found in the range of CATC BLUETOOTH Analyser applications provides a valuable time-scaled view in addition to the chronological packet and logical transfer views of the primary display window. Some modes of operation of the BLUETOOTH piconet and some Piconet Master problems can be more readily observed using the bus utilization view. This application note looks at some of the strategies that can be employed using the bus utilization view as a debugging tool.

Viewing transmission modifiers (Sniff, Park, Hold)

Some Bluetooth activity such as Sniff, Park and Hold can be readily seen as LMP messages, however they actually effect the operation of the baseband. In the picture above we can see that the Slave with member address #1 (in this case) requests to enter sniff mode with 162 slot interval between sniff attempts. Some time later the slave requests to exit sniff mode and then re-enter it with a sniff interval of 402slots. The true effect of this can be more readily seen in the bus utilization view where we can see that the dense normal null/poll activity is at Point A before the first LMP 651. This sniff mode is entered and the reduced sniff activity is seen at B. After LMP 659 the null poll activity is further reduced and can be clearly seen at area C.

Viewing multiple device interaction

When working with multiple slaves the master has to schedule time to each slave for transactions and polling. The bus utilization graph shows where in the time line these events happen relative to each other. The Bus utilization display can readily show this, however you will need to adjust the default graph to add some more customized graphs.

For this example we have a piconet with 3 devices (assigned LT_addr 1, 2 and 3). By default the primary graph shows all devices on the same graph. If we select the new graph from the bus utilization menu, we can create a new view of the piconet data.

The first view will be the entire Master only traffic. Change the graph name to ‘Master’ and then instruct it to filter out all slave data leaving the Masters communication to each device enabled. The click OK.

Repeat the new Graph process for slave 1, again change the name and this time filter out all master and slave traffic except for the slave traffic from Slave 1:

Repeat this again for slave 2, only this time disable slave 1 traffic and enable slave 2:

and so on for each other slave of interest.

The result will be a display like this one:

On this display we can see the Master establish a connection to slave 1 at around 42s (the dark brown block is the paging process so it is heard by all devices). Then at 49s it connects to slave 2, whilst maintaining the link with slave 1. It then has 3 attempts to connect to slave 3 (59-64s, 68-73s and 77s) connecting on the third attempt.

By using the cross hair or magnifying glass icons it is possible to zoom in closer to observe Bluetooth Piconet traffic at work. Here we see the poll packets (grey) from the master in the top graph being responded to by the slaves in turn by nulls (purple) on the lower graphs. We have added arrows to show the corresponding events between each device.

Viewing absence

When working with multiple piconets the interaction of those piconets can be of interest. In this case we have used a BTTracer with the second radio module option. Both radios are synchronized to the same highly accurate internal reference clock allowing us to accurate synchronize the traces even though the two piconets are operating on different master BTClocks. One radio is tracking Piconet 1, the other Piconet 2. In scatter mode the PS packet is used and so we can see that the first Piconet is established at the start of the trace and ‘normal’ poll/null activity is performed. At 70s into the trace the second piconet is started and the scatter-mode is setup at around 72s into the recording:

In this case the two graphs were setup by assigning all traffic from a recording channel (piconet) to a separate graph using the new graph button again:

Assigning a name and selecting the pull-down for each channel:

NOTE: the multiple channel options only appear if there are multiple channels in the recorded trace file.

By zooming in closer to this trace, we can observe the interaction of both Piconets for the device that is both a Slave on one Piconet and a Master on the other

Similarly we can observe when the Dual role device is absent from the first piconet because it is active on the second piconet.

Summary

The bus utilization view is a valuable addition to the chronological packet view and the logical transfer view. The bus utilization graph gives a comprehensive idea of the relative timing and sequencing of events within the piconet.