5.1 Operation Modes Overview

The Eddystone protocol defines three frame-type formats (referred to as “frames”), which are transmitted by the beacon device as described in Table 1.

These frames are described in more detail in the Eddystone protocol specification. Each frame represents an advertising packet, up to the maximum 31-byte payload defined by the Bluetooth 4.2 core specification.

The Eddystone Beacon defines two modes of operation: regular advertising mode and an optional URL configuration mode. These operating modes are related by five individual operational states. In regular advertising mode, the beacon operates as a traditional broadcaster sending non-connectable advertisements consisting of UID, URL, or TLM frames. In URL configuration mode, the beacon transmits connectable advertisements to allow a client to connect, and if authorized, update the URL content and the system parameters through the URL configuration service.

The operating state transitions for these modes of operation are depicted in Figure 1, along with the corresponding actions used to transition states in the SimpleEddystoneBeacon example project. States shown with a grey circle represent URL configuration mode, while the other states represent regular advertising mode.

The Eddystone protocol does not specify the type, when, or how often a particular frame is transmitted, or the actions that trigger a particular state transition. These details are implementation-specific. An Eddystone Beacon may, for example, transmit only URL frames, or a combination of all three frames at different intervals.

In this design, the beacon device sends either UID frames or URL frames regularly, and TLM frames intermittently, while in regular advertising mode. The state transitions between UID and URL are toggled by a RIGHT button press. For practical reasons, TLM frames are expected to be observed less frequently than UID or URL frames, so in this design, they are sent only every 10th advertise of UID or URL.

URL configuration mode can be entered by entering the config mode advertising state in this design. It is triggered by a LEFT button press. Exiting configuration mode can be caused by a LEFT button press, or any type of termination of the connection. Generally, the central terminates the connection when the beacon is finished updating, to let the beacon resume regular advertising mode.

To use a button press to trigger some of the transitions, the key event handler must be implemented. Button press handling is implemented slightly differently by hardware platform. In this implementation, functions in board_key.c are used for the CC2650 LaunchPad. In any case, SimpleEddystoneBeacon_keyChangeHandler() is registered as the callback and eventually the key event SEB_KEY_CHANGE_EVT is handled by SimpleEddystoneBeacon_handleKeys().

For the CC2650 LaunchPad, all RIGHT btn presses correspond to BTN-2, and all LEFT button presses correspond to BTN-1.