Running the Connection Handover scenario

Connection Handover is an NXP proprietary feature that enables a Bluetooth Low Energy connection to be seamlessly transferred from one peripheral to another while the central device remains unaware. It is best exemplified by (but not limited to) the CCC Digital Key use case. As a person carrying a phone moves around the vehicle, the Bluetooth Low Energy connection is transferred between Car Anchors in order to ensure the best user experience. From the Device’s point of view, it stays in the same initial connection.

The CCC Digital Key demos showcase the Connection Handover feature. The handover is performed on demand via a button press. In a real scenario, the handover is performed based on criteria such as RSSI. The feature is currently supported on the KW45B41Z-EVK and KW47-EVK platforms.

Prerequisites:

  • Three boards (two boards act as Car Anchors, one as a Device). The demo is currently limited to a maximum of two Car Anchors.

  • The two Car Anchors must have a serial connection via the secondary UART as shown in the image below. The UART connection stands in for a real deployment solution such as a CAN bus.

  • The gHandoverDemo_d macro must be set to 1 in app_preinclude.h for the digital_key_car_anchor project. Figure 1 shows KW45B41Z-EVK car anchors connected via secondary UART. (J1-1 is connected to J1-2 and J1-2 is connected to J1-1. GND connection is J13-1 to J13-1.)

  • If KW47-EVK boards are used, make the UART connection between J1-1 to J1-3 and J1-3 to J1-1.

Demo steps:

  • Connect a Car Anchor and a Device using either the Owner Pairing or Passive Entry scenario as detailed in the previous sections. If doing Owner Pairing, the bonding data synchronization between the two Car Anchors will happen automatically over the UART connection.

  • Optional: Use the “send” shell command on the Car Anchor to send a test message over the L2CAP Credit-Based channel. The message is displayed in the console on the Device.

  • Press the SW3 switch on the Car Anchor which is connected to the Device.

  • The connection is handed over to the second Car Anchor as seen in console messages. LED2 also turns solid blue on the Car Anchor, which has taken over the connection.

  • Optional: Use the “send” shell command on the Car Anchor that has taken over the connection. The message is displayed in the console on the Device.

  • The connection can continue to be handed over back and forth between the two Car Anchors by pressing the SW3 switch on the Car Anchor which currently has the connection. Figure 2 shows first Car Anchor connects and pairs with the Device, sends the L2CAP test message and successfully performs handover when SW3 is pressed.

Figure 3 shows that the second Car Anchor receives the bonding data automatically via UART when the first Car Anchor pairs with the Device. After the handover is successfully completed, it sends the L2CAP test message to the Device.

Figure 4 shows the Device receiving both L2CAP test messages. From the device’s point of view, it is in a single uninterrupted connection.

Running the Anchor Monitoring scenario

Anchor Monitoring is an NXP proprietary feature that allows a second Anchor to monitor the connection between the first Anchor and the Device. The prerequisites are the same hardware setup as used for the Connection Handover scenario. Note, however, that the Connection Handover scenario cannot be performed while Anchor Monitoring is in progress.

Demo steps:

  1. Connect a Car Anchor and a Device using either the Owner Pairing or Passive Entry scenario as described in Owner Pairing Scenario and Passive Entry Scenario.

  2. Run the “monitor start” shell command on the Car Anchor, as seen in Figure 1.

  3. The second Car Anchor begins monitoring the connection and receives RSSI info events, which it forwards to the first Car Anchor (see Figure 2).

  4. The received RSSI messages are displayed in the console (see Figure 3).

  5. To stop monitoring, run the “monitor stop” shell command on either Car Anchor (the second one is recommended, as its console is not flooded by RSSI event messages).

Parent topic:Running the Connection Handover scenario

Running the Packet Monitoring scenario

Packet Monitoring is an NXP proprietary feature that allows a second Anchor to receive the packets from the connection between the first Anchor and the Device. The prerequisites are the same hardware setup as used for the Running the Connection Handover scenario. Note, however, that the Connection Handover scenario cannot be performed while Packet Monitoring is in progress. Packets received by the second Anchor are sent over the serial interface to the first Anchor for processing. The first Anchor determines the source of the packet based on the SN and NESN bits and displays the RSSI.

Demo steps:

  1. Connect the first Anchor and a Device using either the Owner Pairing or Passive Entry scenario as described in Owner Pairing Scenario and Passive Entry Scenario.

    Anchor has performed Owner Pairing and the “packetmon start” command is run.

  2. Run “packetmon start” on the first Anchor, as shown in Figure 1.

  3. The second Anchor begins monitoring the connection and receives packet information, which it forwards to the first Anchor. See Figure 2.

  4. The first Anchor receives the packet information from the second Anchor and determines the source of the packet based on the SN and NESN bits. The source and the RSSI are displayed in the console. See Figure 3.

  5. To stop monitoring, run “packetmon stop” shell command on either Anchor (the second one is recommended, as its console is not flooded by packet information messages).

Parent topic:Running the Connection Handover scenario