Bluetooth Low Energy Fundamentals

Feedback
Feedback

If you are having issues with the exercises, please create a ticket on DevZone: devzone.nordicsemi.com
Click or drag files to this area to upload. You can upload up to 2 files.
Register

Exercise 2

Inspect a Bluetooth connection, analyze GAP and GATT packets

In this exercise, we will be sniffing the packets in a Bluetooth LE connection between your Nordic device and your phone. This exercise will help you apply what you learned in Lesson 3 about connection establishment and connection parameters to what actually happens over the Bluetooth LE link.

We will be using the application we made in Lesson 3 Exercise 2 for this exercise.

Exercise steps

In the GitHub repository for this course, go to the code for this exercise, found in lesson6/blefund_less6_exer2.

Note that this is the same firmware as the solution to exercise 2 found in lesson3/blefund_less3_exer2_solution.

1. Build and flash the application on your board.

LED1 on your board should be blinking, indicating that your board is advertising.

2. Filter only the device packets from Nordic_Peripheral.

In Wireshark, run the sniffer again and open the Device drop-down list to select Nordic_Peripheral. If you only see the name from the previous exercise (Nordic_Beacon), you may need to close Wireshark, and open it again.

If there are too many devices, you can use the RSSI filter as we did in the previous exercise.

After you select Nordic_Peripheral, you should only see the packets from this device, in this case, the device address is cd:f6:1b:aa:5f. Here we can see mainly advertising packets (ADV_IND), and some scan requests (SCAN_REQ) and scan response (SCAN_RESP) from the same advertiser.

Make sure that the “Automatic Scroll” function is enabled to see the latest packets

3. Establish a Bluetooth LE connection

Launch nRF Connect for Mobile and connect to the Nordic_Peripheral device, just like we have done several times previously.

When the connection is established, you should be able to see this from the nRF Sniffer in Wireshark.

Notice a large number of packets being exchanged between the peers at a high speed. Most of them are empty PDU packets.

Note

If you don’t see any empty PDU packets, the sniffer may have missed the connection. This happens if the sniffer fails to capture the connection request packet to follow the connection. Try to connect again, by disconnecting the peripheral from the nRF Connect application, and initiating the connection again.

4. Inspect the connection parameter update request packet.

Find a packet with the Info: “Connection Parameter Update Request”, from the L2CAP protocol, see below.

It might be a good idea to turn off “Auto Scroll” to easier navigate through all the captured packets.

Expand Buetooth L2CAP Protocol and Command: Connection Parameter Update Request to find the request minimum and maximum connection interval of 800 (1000 ms) which is what we requested in Lesson 3 Exercise 2.

5. Inspect the connection update indication packet (LL_CONNECTION_UPDATE_IND).

Right after the request, you can see the LL_CONNECT_UPDATE_IND packet from the phone. This packet dictates the new updated connection parameters according to what was requested by the peripheral.

Inspecting LL_CONNECT_UPDATE_IND will show you the new connection parameters. In this case, we see the connection interval of 800 (1000ms) and the connection timeout of 400 (4 seconds). This corresponds to what was requested in the code. Also, notice the Instant value of 177. This value tells the peers at which connection event the new parameters will take effect.

As we can see from the Delta time column of the packets after this, the new connection interval of 1000 ms takes effect at Event number 177.

6. Apply a filter to filter out the empty data packets.

The majority of the packets you see in the Live Capture are just empty PDU packets that are sent to keep-alive the connection between the peers. The central sends a packet at the beginning of the connection event and the peripheral responds with a packet as an Acknowledge. When they don’t have anything to send, they simply send Empty PDU packets that only contain a data header and no payload. Without these packets being sent and acknowledged, the connection times out after the connection supervision timeout.

However, these Empty PDU packets make it difficult to inspect the communication, especially when you need to find a certain meaningful packet. The best way of solving this is to create a filter to hide these Empty PDUs.

Let’s apply the filter by selecting an Empty PDU. Then in the Packet Details window, expand Data Header and right-click where it says Length: 0. Then click Apply as a Filter > Not Selected.

Filtering out empty PDUs

Alternatively, you can write the filter manually in the “Apply a display filter” text box in the top left corner. To filter out packets with empty length you can enter the following filter command: !(btle.data_header.length == 0)

After the filter has been applied, you will only see the packets that actually have data payload

7. Inspect the communication when connected.

Now that all the empty packets are filtered out, let’s inspect the packet exchanges when two devices are connected.

The following image shows the anatomy of a connection between the phone and the “Nordic_Peripheral” where we enable notification on the button characteristic via the phone and then press and release the button a few times:

Try to reproduce a similar capture log, by subscribing to notifications from the Button Characterstic in nRF Connect for Mobile, like we have done in previous exercises.

Let’s inspect some of the other packets in the connection lifecycle.

7.1 Inspect the connection request, CONNECT_IND.

The connection request is sent from your phone to the device, when you select Connect in nRF Connect for Mobile. This is where we will find the the initial connection parameters, like the connection interval and the connection supervision timeout.

Here we can see that we get an initial connection interval of 30 ms, which explains the delta time between the empty PDU packet we saw in a previous step. And a connection supervision timeout of 5000 ms.

7.2 Inspect the PHY request, LL_PHY_REQ.

The packet LL_PHY_REQ is the request from the peripheral to use 2M PHY radio mode, where the peripheral informs that it prefers to use the LE 2M PHY (left image). We can also see the response from the central in LL_PHY_UPDATE_IND, indicating that LE 2M PHY shall be used (right image).

LL_PHY_REQ
LL_PHY_UPDATE_IND

Note

The actual packets exchanged depend on whether the central or peripheral initiates the procedure.
If the procedure is initiated by the central, which is what happened in this case, it sends an LL_PHY_REQ and the peripheral responds with an LL_PHY_RESP, before the central sends the LL_PHY_UPDATE_IND.
If the procedure is initiated by the peripheral, it sends an LL_PHY_REQ and the central responds directly with an LL_PHY_UPDATE_IND.

7.3 Inspect the write request to the CCCD to enable notifications

Find the packet that sends a write request with the handle of the CCCD attribute (0x0013). Upon inspection, notice that it is setting the notification bit to true, to enable notifications from this characteristic.

7.4 Inspect the notifications when the button is pressed and when it’s released

You may notice many consecutive “Rcvd Handle Value Notification” packets from the ATT layer in the capture log.

The handle of the notification value attribute is 0x0012. It’s very common in the attribute table that the value attribute is located right above the CCCD attribute 0x0013. Also notice that the value of the characteristic when the button is pressed is 0x01 and when the button is released is 0x00. This is how the app on the phone detects whether to display “Button Pressed” or “Button Released”.

This marks the end of this exercise. You should be able to start using the sniffer to inspect other exercises. For example, the screenshot below is from the capture log of Lesson 4 Exercise 3, where we use NUS service to send UART data from the computer to the phone. In this case, we have typed “Nordic Academy” into a serial terminal and can now see the notification that contains this data being sent to the phone:

Make sure to Log in or Register to save your progress

Back
Next
Register an account
Already have an account? Log in
(All fields are required unless specified optional)

  • 8 or more characters
  • Upper and lower case letters
  • At least one number or special character

Forgot your password?
Enter the email associated with your account, and we will send you a link to reset your password.