* - low_battery: The vehicle battery has a low charge and will die soon * - full_battery: The vehicle battery is fully charged * The state of a vehicle recorded in the advertising packet. Unsigned char name // UTF8: 12 bytes + NULL. * - name: User-defined name in UTF-8 encoding * - version: Firmware version running on the vehicle * NOTE: Changes to the vehicle state will cause the LOCAL_NAME value * Vehicle information packed in the LOCAL_NAME string record This strategy of including additional information in the LOCAL NAME field enhances the user interface experience in the Anki Drive app, but may result in the LOCAL_NAME data changing during repeated advertisements if, for example, a vehicle is removed from a charger. This should be accounted for when parsing the data. However, the remaining data could be NULL, which would still satisfy the requirement for a UTF-8 encoded string. The vehicle state and firmware version will always be non-null values in the ASCII range from (0x01 - 0x7f). The LOCAL_NAME advertised by Anki Drive vehicles consists of the vehicle state ( state), firmware version ( version) and a user-defined vehicle name ( name). To ensure that the entire LOCAL_NAME is available during advertising, Anki Drive vehicles only use up to 20 bytes of LOCAL NAME data.
#Anki overdrive Bluetooth
However, Bluetooth LE devices may only advertise up to 20 bytes of the LOCAL NAME data ( Bluetooth 4.0, Part C, 11.1.2). The Bluetooth 4.0 specification requires that the LOCAL_NAME field be a UTF-8 encoded string of up to 248 bytes, with shorter values terminated by a NULL (0x0) byte ( Bluetooth 4.0, Part C, 3.2.2.3, 12.1). * - product_id: Value identifying the vehicle as Anki Drive hardware * - model_id: The model type of a vehicle * - identifier: Unique identifier for a physical vehicle * Vehicle hardware information encoded in the MANUFACTURER_DATA This value specifies the 'make/model' of the vehicle ( model_id) and a unique identifier for each vehicle of the specified model ( identifier). The manufacturer data is a uint64_t value that uniquely identifies each vehicle. This UUID can be used to identify vehicles during scanning, or as a handle to discover the read and write characteristics after connecting to a vehicle. The service_id for an Anki Drive vehicle is defined in the GATT profile for the vehicle, and will always be the same 128-bit UUID. * service_id: Anki Vehicle UUID (128-bit) * local_name: parsed data from the LOCAL_NAME string bytes * mfg_data: parsed data from the MANUFACTURER_DATA bytes * Vehicle information present in Bluetooth LE advertising packets. Vehicle advertisements consist of the Anki Drive service UUID ( service_id), along with a unique identifier ( mfg_data), name and state information ( local_name). The Anki Drive SDK provides methods to parse EIR data into records and toĮxtract vehicle information from specific types of records. These records types are defined as part of the GATT profile specification. If raw scan data from the Extended Inquiry Response (EIR) is available, it needs to be parsed to obtain the LOCAL_NAMEĪnd MANUFACTURER_DATA.
On Linux and Android, the raw scan bytes are exposed via the bluetooth API ( BlueZ, Linux android.bluetooth, Android) and must be parsed to obtain the GATT profile data members of interest. On iOS, CoreBluetooth parses this data internally and provides an NSDictionary containing the profile data.
Vehicles broadcast identifying information and service definitions in the form of advertising packets.Īn advertising packet contains binary data in a parsable format defined by a generic attribute profile (GATT).ĭepending on the bluetooth API available on the central, this information may be exposed in different ways. Once connected, a central device can communicate with vehicles using the Anki Drive message protocol outlined below. This document describes the format of the vehicle advertisement data, which can be used to decode the vehicle identifier, name and model. The protocol is conceptually similar to a client-server architecture, in which a client device (central) can connect to and communicate with a server device (peripheral).įor more information on Bluetooth 4.0, see the Bluetooth 4.0 Core specification.Īnki Drive vehicles are Bluetooth low energy peripheral (server) devices.Īny device capable of acting as a central (client), such as a smartphone or computer, can discover, connect to and control vehicles.Įach vehicle advertises identifying information and a service that consists of characteristics for sending and receiving data. The Bluetooth 4.0 specification defines a wireless communication protocol for use with low energy devices.
0 kommentar(er)
