Home

Welcome to the Chorus-RF-Laptimer wiki!

Device communication protocol

Each Solo device Receives and Transmits data. Here's how the communication flow is organized from a Solo device standpoint.

Basic concepts:

1. Each Solo device connected into a Chorus has its ID (order number), which is assigned dynamically upon initialization of the Chorus device from a communicating application. Normally enumeration starts with 0.
2. Each data chunk is a plain string terminated with "\n" character (ASCII=10) and having a predefined structure.
3. There are 3 types of data chunks:

• Requests
• Responses
• Pass-through data

4. Almost each Request produces a Response
5. Pass-through data is either a request to a different Solo device, or response which needs to pass through current device to reach the Bluetooth dongle and be transmitted to App.

Requests

There are 3 types of requests:

1. Device enumeration: (3 characters) "N" + <first_ID> + "\n". Example: "N0\n"
2. Command/Request: (4 characters) "R" + <device_ID> + <command> + "\n". Example: "R1T\n"
3. Calibration: (11 characters) "C" + <device_ID> + <time_long_HEX_value> + "\n". Example: "C00000010A\n"

In any "R" request: <device_ID> may be set to "*", which means the request is addressed to all devices (broadcast), and each should provide a response. Example: "R*A\n"

Note: for broadcast requests the order of responses from different devices is not defined. Example: "S1R1\nS0R1\nS2R1\n"

Responses

Response structure: "S" + <device_ID> + <response_type> + <data> + "\n" Each response type has its own predefined length depending on size of data to be transmitted.

Correspondence of Requests to Responses (API)

The most recent version of the API is in the docs folder (MS Excel format).