Interface
The section documents the serial interface.
The device supports a serial interface that can be accessed using the USB connection (see Modes of operation). The interface can be used to communicate with the device in real-time.
Note
See the product webpage for tools supporting the serial interface.
Serial protocol
Warning
The specification of the serial interface protocol below is for advanced users only
The serial protocol consists of three simple layers:
Physical layer (PHY)
Data-link layer (DLL)
Application layer (APL)
The layered model ensures effective and robust communication between the device and the host (e.g. PC).
In the following sections, the protocol layers will be described.
Physical layer
The USB connection creates a virtual serial interface with the following configuration:
Bit-rate: 115200 bit/s
Data bits: 8
Stop bits: 1
Parity: None
Flow control: None
Note
The settings above are in practice not used as the serial port is virtual via USB.
Data-link layer
The purpose of the DLL is to ensure safe and error-free transmission of message frames between the device and the host. The DLL ensures that the start/stop of a message frame can always be uniquely identified and that the integrity of the data payload can be verified by the receiver.
The design of the DLL is heavily inspired by the widely used HDLC specification with the following frame structure.
Start flag |
Payload |
CRC |
Stop flag |
|
|---|---|---|---|---|
0x7E |
… |
MSB |
LSB |
0x7E |
Frame identification
The start and end of a frame are always uniquely defined by the start/stop flag with a unique one-byte value 0x7E.
Byte stuffing is used to avoid that the start/stop byte appears randomly in the message payload or CRC fields. The device uses a control byte with value 0x7D to escape occurrences of the unique start/stop byte in the data.
To decode he message frame, the receiver shall examine the data between the start/stop flags. If the control byte is detected, the received shall perform the following actions:
Discard the control byte (
0x7D)Restore the following byte by complementing its 5th bit (indexed from zero)
Frame integrity verification
When the frame has been destuffed, the integrity of the data can be verified using the CRC field. To verify the integrity of the payload, the receiver shall perform the following actions:
Calculate the CRC16 checksum over the Payload
Compare the calculated checksum with the checksum stored in the CRC field (2 bytes)
If the calculated and the stored values are equal, the frame is valid
The CRC16 calculation uses the standard CRC-16 polynomial[1] (also known as CRC-16-IBM): \(x^{16} + x^{15} + x^2 + 1\)
The details of the CRC calculation are beyond the scope of this manual.
Example: Decoding of received message frame
The following message frame is received on the serial interface, indicated by the start/stop byte pair:
Start flag |
Stuffed frame data |
Stop flag |
|---|---|---|
0x7E |
AA BB CC 7D 5E DD EE FF A3 84 |
0x7E |
Scanning the bytes in between the start/stop flags reveals one occurrence of the control byte 0x7D. By following the destuffing steps, the control byte is removed and the following byte restored to the original value (the value before the stuffing performed by the device) by complementing the 5th bit:
Start flag |
Destuffed frame data |
CRC |
Stop flag |
|---|---|---|---|
0x7E |
AA BB CC 7E DD EE FF |
A3 84 |
0x7E |
To CRC16 is now calculated to validate the integrity of the payload data:
CRC16(AA, BB, CC, 7E, DD, EE, FF) = A384
The validation shows that the payload is valid as the calculated and the stored CRC values are equal.
Application layer
The decoded DLL payload becomes the APL frame.
The APL is the decoded Payload of the DLL and contains an application ID (1 byte) and the application data:
The APL frame format is:
ID |
Application data |
|---|---|
1-3 |
… |
The interpretation of the application data is defined by the ID field:
ID |
Description |
Direction |
|---|---|---|
1 |
CAN-bus message received |
Device to PC |
2 |
CAN-bus message transmitted |
Device to PC |
3 |
CAN-bus transmission request |
PC to device |
The following describes above listed application data interpretations.
ID 1 - CAN-bus message received
The application data contains a CAN-bus message received by the device.
ID |
Application data |
||||
|---|---|---|---|---|---|
1 |
Time |
Time ms |
Message ID |
Data length |
Data |
4 byte |
2 byte |
4 byte |
1 byte |
0-8 byte |
|
The Time field is encoded as epoch seconds. The message ID is extended if bit 29 (indexed from zero) is set. Multi-byte fields shall be interpreted MSB (Most-Significant-Byte) first.
ID 2 - CAN-bus message transmitted
The application data contains a CAN-bus message transmitted by the device based on the configuration file.
Note
Note that messages transmitted based on interface transmission requests (via USB) are not included.
ID |
Application data |
||||
|---|---|---|---|---|---|
2 |
Time |
Time ms |
Message ID |
Data length |
Data |
4 byte |
2 byte |
4 byte |
1 byte |
0-8 byte |
|
The Time field is encoded as epoch seconds. The message ID is extended if bit 29 (indexed from zero) is set. Multi-byte fields shall be interpreted MSB (Most-Significant-Byte) first.
ID 3 - CAN-bus transmission request
The application data contains a CAN-bus message to be transmitted by the device.
ID |
Application data |
||
|---|---|---|---|
3 |
Message ID |
Data length |
Data |
4 byte |
1 byte |
0-8 byte |
|
The message ID is extended if bit 29 (indexed from zero) is set. Multi-byte fields shall be interpreted MSB (Most-Significant-Byte) first.