Skip to content

Client and on board Communication

Jump to bottom
Osher edited this page Apr 16, 2021 · 12 revisions

Communication

All messages between client and on-board begin with a command (e.g stream-bike-sensor-data) followed by a colon and then a number of parameters separated by colons.

Streaming Sensor Data From on-board to Client

The on-board collects sensor data from the can-bus, decodes it, and makes it available for the client to stream in real time.

Client stream-bike-sensor-data request

The client can request for the on-board to start/stop streaming sensor data using the following message format:

stream-bike-sensor-data:<start/stop>:<data_identifier_1>:...:<data_identifier_n>

  • stream-bike-sensor-data specifies the type of request (this is a request to stream data)
  • <start/stop> whether to start streaming data or stop streaming data.
  • <data_identifier> identifies the type of sensor data being requested e.g AIR_TEMPERATURE, LEAN_ANGLE etc...

An example request to begin streaming AIR_TEMPERATURE and LEAN_ANGLE data from the on-board would look like:

stream-bike-sensor-data:start:AIR_TEMPERATURE:LEAN_ANGLE

An example stop request would be:

stream-bike-sensor-data:stop:AIR_TEMPERATURE tells the on-board to stop streaming AIR_TEMPERATURE.

NOTE: In this example the on-board will continue streaming LEAN_ANGLE until requested to stop.

To enable the streaming of all available metrics, use stream-bike-sensor-data:start:all.

To stop the streaming of all metrics, use stream-bike-sensor-data:stop:all.

on-board Bike Sensor Data Stream

The on-board data stream consists of regular messages with the following format.

stream-bike-sensor-data:<data_identifier_1>:<data_1>:<timestamp_1>:...:<data_identifier_n>:<data_n>:<timestamp_n>:

  • stream-bike-sensor-data specifies the type of message (this is a bike sensor data stream)
  • <data_identifier> identifies the type of sensor data
  • <data> the sensor data value
  • <timestamp> is the timestamp when the data was recorded

An example data stream in response to the AIR_TEMPERATURE, LEAN_ANGLE example from above might look like:

stream-bike-sensor-data:AIR_TEMPERATURE:34:1618094675:LEAN_ANGLE:34:1618094675 depending on the sampling interview

Streaming Profiling Data From on-board to Client

The client can request profiling data, such as CPU usage and frequency. Using messages of the following format:

stream-profiling-data:<start/stop>:<profiling_data_id_1>:...:<profiling_data_id_n>

  • stream-profiling-data specifies the type of request (this is a request to stream profiling data)
  • <start/stop> whether to start streaming data or stop streaming data.
  • <profiling_data_id> identifies the type of profiling data being requested e.g CPU_USAGE, MEMORY_USAGE etc...

An example might be stream-profiling-data:start:CPU_USAGE

NOTE: as with bike sensor data streaming the on-board will continue streaming until requested to stop.

To enable all profiling metrics, use stream-profiling-data:start:all

To disable one profiling metric, use stream-profiling-data:stop:<profiling_data_id>

To disable streaming of all profiling metrics, use stream-profiling-data:stop:all

on-board Profiling Data Stream

The on-board profiling data stream consists of messages with the following format:

stream-profiling-data:<profiling_data_id_1>:<data_1>:<timestamp_1>:...:<profiling_data_id_n>:<data_n>:<timestamp_n>:

  • stream-profiling-data specifies the type of message (this is a stream of profiling data)
  • <profiling_data_id> identifies the type of profiling data
  • <data> the profiling data value
  • <timestamp> is the timestamp when the data was recorded

An example data stream in response to the CPU_USAGE example from above might look like:

stream-profiling-data:CPU_USAGE:2.354:161809743

Enabling/Disabling Encryption Between Client and On-board

To turn on/off the encryption while the program is running, send encryption:on or encryption:off to the on-board software. The client must reconnect in the correct mode to complete the switch.

Measuring Throughput

The throughput both from client->on-board and from on-board->client can be measured in the following way.

  1. Client sends message start-bandwidth-test to on-board.
  2. Client sends a series of messages to on-board which 1024 bytes each. The messages are constructed bandwidth-test-data<filler_byte_1>...<filler_byte_n>. These are read and ignored by the on-board.
  3. Client then sends a message bandwidth-test-request-confirm signalling that the on-board should confirm to the client the data was received.
  4. On-board then sends confirmation to client bandwidth-test-confirm.
  5. On-board then sends client a series of bandwidth-test-data messages each of 1024 bytes (same format as step 2) each.
  6. On-board then sends client bandwidth-test-request-confirm to request confirmation that the data from step 5 was received.
  7. Client then sends confirmation to on-board bandwidth-test-confirm.
  8. On-board then sends result to client bandwidth-test-result:<throughput_result> where <throughput_result> is a floating point number representing the throughput from on-board to client in kilobytes per second.

Performing Sorting Benchmark

The client can request for the on-board to perform a sorting benchmark. This causes the on-board to sort a list of integers of a given size and then return the time taken.

The protocol is as follows:

  1. Client sends on-board sort-benchmark:<number_of_items> where <number_of_items> is an integer representing the number of items to sort.
  2. On-board performs the requested sort and responds with sort-benchmark-result:<time_taken> where <time_taken> is a float representing the amount of time taken in seconds to execute the sort.
Clone this wiki locally