SpringCore Direct over Bluetooth

Overview

SpringCore Direct is a versatile protocol that allows the host to control the SpringCore device independently of its operating mode and independently of its communication interface (USB, BLE, ...).

This chapter details the implementation of SpringCore Direct over the Bluetooth (BLE) interface.

The higher level protocol is documented in its own chapter: Direct Protocol.

Controlling the device's user interface (and many other features) is detailed in Direct Protocol : Control Class and operating the device in Smart Reader Mode in Smart Reader Operation : Protocol and API.

Services and list of characteristics

Bound service

This service is to be used when the host and the device are bound by a persistent BLE connection (bonded mode).

UUID Access See chapter
60D4CEE8-5E58-4338-876E-D71B48C732DD Bonding is mandatory
E19FB276-2114-46A2-AB69-CAE47B60EF4C Direct_Command Write only See Direct Protocol and Direct protocol over BLE below
8DE3AD7E-8A21-4E03-9E9E-B0098E0638B9 Direct_Response Read, indicate See Direct Protocol and Direct protocol over BLE below
2B09ECF6-0BE3-4FCB-8E02-1B2917BEEAC0 Direct_Events Read, indicate See Direct Protocol and Direct protocol over BLE below

Open service

This service is to be used when the host and the device are connected by a temporary BLE connection (connected mode). This service may be disabled by configuration (in order to force the hosts to use bonded mode only).

UUID Access See chapter
7A4385C9-F7C7-4E22-9AFD-16D68FC588CA Free
18227CA8-9574-4D92-850C-B55F84C6B577 Direct_Command Write only See Direct Protocol and Direct protocol over BLE below
94382D3F-FD0F-4EE4-998C-046A6CDC67D6 Direct_Response Read, indicate See Direct Protocol and Direct protocol over BLE below
23D33996-E604-4F8B-BAF7-547944030552 Direct_Events Read, indicate See Direct Protocol and Direct protocol over BLE below

Direct protocol over BLE

Every message starts with a PCB (Protocol Control Byte), followed by the CLAss, then the LENgth and the payload. The length is expressed on 2 bytes, hence limiting the payload to 64kb.

Frame format

Byte Name Description
0 PCB Protocol Control Byte - see section "PCB" below
1 CLAss Class of command or response
2-3 LENgth Length of payload minus 1 (0000 = 1 to FFFF = 65536), MSB-first
4-N Payload Up to 64kB

PCB for Direct_Command and Direct_Response characteristics

Bit Name Description
7 Way 0: host to device
1: device to host
6 Channel must be 0 for bulk
5 Secure must be 0 for plain communication
4 Header type 0: short header (LENgth on 2 bytes)
3-0 Sequence Sequence number. Incremented by the host (modulo 16) and echoed by the device.

PCB for Direct_Events characteristics

Bit Name Description
7 Way 1: device to host
6 Channel must be 1 for interrupt
5 Secure must be 0 for plain communication
4 Header type must be 0
3-0 Sequence Sequence number. Incremented by the device (modulo 16).

Rules for the Direct_Command and Direct_Response characteristics

Chaining

If the header + payload don't fit within the MTU (max transfert unit) of the BLE link, chaining is implicitely performed by the underlying BLE layers.

Half-duplex communication

All messages go as command/response pairs:

  • the host sends a command over Direct_Command,
  • the device processes the command and sends its response over Direct_Response.

The host SHALL NOT send a new command before it has received a response to the previous one, or a timeout has occurred (timeouts are defined in next section).

The device SHALL NOT send a response without having received a valid command.

Timeout

The timeout for Direct_Command to Direct_Response response is fixed to 1000ms.

If the device is not able to terminate the execution of the command within 1000ms, it SHALL anyway send a response using the PROTOCOL Class and the TIME_EXTENSION_REQUEST Status.

The host SHALL then send a TIME_EXTENSION_ACK Instruction or a CANCEL Instruction.

The device SHALL NOT send another response before having received either Instruction.

Rules for the Direct_Events endpoint

Chaining

If the header + payload don't fit within the MTU (max transfert unit) of the BLE link, chaining is implicitely performed by the underlying BLE layers.