BLE Hands on Simple Server and Using Network Analyzer - joe-possum/IoT-Developer-Boot-Camp GitHub Wiki

In this work sheet we will revisit Bluetooth - SoC Thermometer and introduce the Network Analyzer tool.

Reopen the Bluetooth - SoC Thermometer project. Select the .slcp file and switch to the SOFTWARE COMPONENTS tab. Enter "pti" into the search box. Scroll down to the RAIL Utility, PTI component (1) under Platform / Radio. Verify that it is selected. This component provides the interface used by the Network Analyzer. Since we we are working with WSTK mounted radio boards, the configuration is already entered. If you had to add the component be sure to rebuild the application before flashing. Flash the appication to the device.

Click on the Open Perspective icon (2) and select Network Analyzer (3) from the dialog.

Notice that the Network Analyzer perspective is now active (4). Right-click on the WSTK in the Debug Adapters pane (5) and select Connect.

Note there is a subtle change in the icon for the WSTK, the symbol is now shaded blue.

We can beging collecting data from the PTI. Right-click on the WSTK again. Select Start Capture.

Studio is now recording every packet transmitted and received by the radio. This is done via a parallel connection to the radio hardware without the need for software running on the MCU core. Packet captures can be very valuable in debugging unexpected interactions. The plot near the top, (6), shows radio activity vs time. The Events pane at the bottom (7) shows a terse decoding of each raw packet. The Transaction pane above (8) indicates decoded transactions which involve multiple raw packets. The Event Detail pane (9) will display full decoding of the currently selected event and the Hex Dump (10) pane displays the raw event. Events in this context mean packets from the PTI. The Event encapsulate the actual over-the-air packet with additional meta-data.

Since the data device is simply transmitting a connectable scannable advertisement, we can stop collecting aftwe a breif interval. Once again right-clicking on the WSTK and selecting Stop capture.

By clicking and dragging across the event timeline, it is possible to zoom in.

Until clusters of packets separated by the advertising interval can be observed.

Zooming in on a single cluster, we can see a single advertising event. Notice how clicking on an event in on pane selects the same event in all other panes.

Select a single advertisement in the Events pane and expand "BLE Advertisement Data" in the Event Details pane. Note how the bytes in the Hex Dump pane are highlighted to match the selected field. Expand "Radio Info EFR32", this is some of the meta-data. Verify that in a single advertising event the same data is transmitted on all three advertising channels once (Network Analyzer indicate physical channels 0, 12 & 39 rather than Bluetooth labeling 37,38 & 39).

Close the the "Live" capture. Locate the device in the EFR Connect browser. Notice that the entry now has a Connect button. If this is not the case, the app may be confused by the device's change in identity since it was a beacon. Close and reopen the app in this case. We will now capture a complete connection. Start a new capture, once you see advertising events appearing in the timeline, tap Connect on the app. Wait for a few seconds after the app displays information about the services found, then click Connections or swipe right and disconnect.

We can actually see all the transactions during the connection in a single screen. Here the connection is initiated at 1.99 seconds. Connection handshaking continues until 2.45 seconds, then GATT discovery continues through 4.64 seconds. From the end of GATT discovery, through the disconnection, nothing but PDU empty packets are exchange to keep the connection open.

• Try capturing the PTI data of EFR Connect Demo Health Thermometer interacting with the device. Can you identify the temperature measurements being transfered?
• Capture the PTI data from the Eddystone TLM beacon of the previous exercise.
• Can you identify differences in timing between the packets transmitted in a single advertising interval for a non-connaectable non-scannable advertisement vs a scannable connectable advertisement. How would this impact energy consumption?
• Can you examine an advertising packet to determine if the device will respond to a connection or scan request?