Define config protobuf message type

[oliverlee]

This is a build configuration option and can vary for different binaries. We should add the tick frequency to the protobuf message so that we can obtain timing information correctly and other fields related to the ChibiOS configuration.

tentative config schema

enum EnumSetupType {
    SIMULATOR = 0;
    STEERBYWIRE = 1;
}

enum EnumProjectType {
    UNSPECIFIED = 0;
    FLIMNAP_AREND = 1;
    FLIMNAP_KINEMATIC = 2;
    FLIMNAP_WHIPPLE = 3;
    FLIMNAP_ZERO_INPUT = 4;
}

message pbConfig {
    optional EnumSetupType setup = 0;
    optional EnumProjectType project = 1;
    optional FirmwareVersion gitsha1 = 2;
    optional bool build_ndebug = 3;
    optional bool ch_st_resolution_32 = 4; // 16-bit if false
    optional uint32 ch_st_frequency = 5;
    optional uint32 ch_rtc_frequency = 6;
    optional uint32 heartbeat_period = 7; // to be used for two-way communication?
}

[mickvangelderen]

Or you could scale timing information.

[oliverlee]

Right now we record:
timestamp - units of system ticks (10 kHz in current master f2c686b, but I want to increase it to 100 kHz in PR #152)
computation time - units of realtime counter ticks (168 MHz)
transmission time - units of realtime counter ticks (168 MHz)

We could scale to microseconds and transmit. The issue that I can think of is if we reduce the size of the unsigned int use to store/transmit timing information from uint32_t to uint16_t or uint8_t, we'd have to be careful about overflow.

With uint32_t the timestamp will overflow in 4.97 days at 10 kHz and 11.9 hours at 100 kHz.

[mickvangelderen]

The way I see it now there are three options:

1. leave as is, read clock frequencies from .h files
   • 👍 simple
   • 👎 fields do not have a consistent unit
2. scale to a unit that works for all possible clock frequencies
   • 👍 fields have a consistent unit
   • 👎 chosen scaling might not work well if the clock frequency changes to a non-anticipated value
3. transmit the counter frequencies
   • 👍 values can be expressed in consistent unit
   • 👎 lots of duplication in the output
   • 👎 mimicking what the exponent in a float does for you

[oliverlee]

1. leave as is, read clock frequencies from .h files

One issue that could arise is if we use different clock frequencies in different headers/projects, we would need to know which is the right frequency when decoding.

3. transmit the counter frequencies

I think we could just send the clock frequency once in the first message

[mickvangelderen]

2. scale to a unit that works for all possible clock frequencies

Floats are precise up to 6 significant digits (23 bits give steps of ).

Usually relative timestamps can be represented by a float but an absolute timestamp cannot. The value must be < 2^23 to prevent loss of precision.

I think we could just send the clock frequency once in the first message

If we can send a few extra bytes per message to make each message individually interpret-able we should.

[oliverlee]

We already do this (dependent messages) for model stuff since we would be retransmitting a lot of data that doesn't change with each message. On Mar 23, 2017 12:55, "Mick van Gelderen" <[email protected]> wrote: 1. scale to a unit that works for all possible clock frequencies Floats are precise up to 6 significant digits (23 bits give steps of [image: 2^{-23} \approx 1.19\cdot10^{-7}] <https://camo.githubusercontent.com/6f1545b90841c60597ff1a8c45f08eada0b96aa9/68747470733a2f2f6c617465782e636f6465636f67732e636f6d2f6769662e6c617465783f322535452537422d3233253744253230253543617070726f78253230312e313925354363646f7431302535452537422d37253744> ). Usually relative timestamps can be represented by a float but an absolute timestamp cannot. The value must be < 2^23 to prevent loss of precision. I think we could just send the clock frequency once in the first message If we can send a few extra bytes per message to make each message individually interpret-able we should. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#153 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AC0-J7e57Xo0aiADCeycwozWNmW_Cu1aks5rol2WgaJpZM4MZd_f> .

[oliverlee]

I think we need to fully define the protobuf message types, specifically the "configuration type", and the corresponding fields.

This is related to #181

[oliverlee]

I'm also in favor of dropping the Message suffix and replacing it with a pb prefix until namespaces are supported.

[mickvangelderen]

Just thought of something. We should include a session number because that might come in handy. There was a RNG unit on the microconroller right?

[oliverlee]

Let's try to switch to proto3 when implementing this and two-way communication, but fall back to proto2 if it doesn't work.