Skip to content

Home

Jump to bottom
Andrey Voroshkov edited this page May 17, 2018 · 39 revisions

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
  1. Almost each Request produces a Response
  2. 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).

High-level communication process

Setup

  1. Run "N0" command to enumerate modules (REQUIRED!). Read response to learn the number of modules in the device. Modules numbering will start from zero. (Note: you may send N1 to start numbering from 1)

  2. Set the "Minimal Lap Time" duration which must be less than the fastest possible lap time during the upcoming race. This will make sure that Chorus won't report false laps if accidentally catches VTX RSSI peak from a nearby drone. Also you should plan the track to avoid situations when drones fly in close proximity to the Chorus before the end of a lap.

  3. Set Frequency into each node using either "Set Frequency" command or "Set Channel" + "Set Band" (2 commands). Note: it's the responsibility of the race control software to remember which node is monitoring which frequency to further match Chorus responses to pilots in each heat.

  4. Calibrate Arduino Timers (optional step, but increases accuracy of measured lap times during the race across nodes). The calibration process is as follows:

    1. Send "Start Calibration" command to all nodes: "R*I"
    2. Wait for some time (about 10 seconds). Let's note this time in milliseconds as "tc".
    3. Send "End Calibration" command to all nodes "R*i". Chorus will respond with measured times from each node:  S1I00002710, S0I00002715 ... Let's note a time from some node as "tn"
    4. Perform the following calculation for each node: cc = tc/(tc - tn), if tc - tn = 0, then set cc = 0; Here cc would mean something like "what time measured by this arduino should be increased/decreased by 1ms". E.g. cc=1000 means that each second measured by arduino gives an error of -1 millisecond, so this millisecond should be added by arduino to compensate the error.
    5. Send calculated cc values to each corresponding node (note it must be a signed 32bit value)
    6. You're done
Clone this wiki locally