User Guide

102 | 127 © 2021 LeddarTech Inc.
Both the request and answer headers have the same format as in concept A, which prevents compatibility
breaks if a given server updates its protocol from concept A to concept B.
In this concept, instead of having only one set of data accompanying a given request, it is possible to have
several chunks of data, called “elements.” Each element has a header that identifies the element and its
accompanying data size. The element data is optional.
Here are general rules for this protocol concept:
1. There can be any number of elements following a request or answer header.
2. Usually, elements can be placed in any order in a request or answer. Therefore, if a given request needs
three elements for correct execution, the sensor should never assume a given order for them, as the
order could change from one firmware version to another one. If a specific order is required, it is
specifically mentioned in the request’s description.
3. The elements code is unique and usually has an associated data format that will never change over time.
For example, if a given element is defined as being encoded on 2 bytes, it will not change over time. If it
later needs to be increased to 4 bytes, a new code will usually be created instead.
4. When the sensor receives an unsupported element with a request, it should ignore that element without
throwing any error. This is an essential rule for allowing backward compatibility over time.
For example, let’s assume a firmware version 1 that supports a given request requiring a given element
specified to be on 2 bytes for correct execution. Now, let’s assume a newer firmware version 2 supports
that same request but needs the element to be on 4 bytes instead of 2 bytes. In this case, a new element
code would be created for that new element.
Noteworthy here is that to support all firmware versions, the host would simply have to send the request
with both elements present. In this case, the older firmware version would simply ignore the unsupported
element, which is on 4 bytes, while the newer firmware version would ignore the unsupported element
code that is on 2 bytes.
5. Following the rule above, it is very important for the host or sensor to always accept all elements data
loads (specified by the headers) even if it does not support any element for a given request in order to
prevent communication protocol errors.
Supported Server Protocols
The Ipv4 communication protocol is based on the client-server model. For all communications with a
Leddar™ device, the device is the server. The client is typically a program running on a computer or
processing board used for the device configuration, control, and monitoring of the Leddar device.
Currently, the Ipv4 communication protocol defines three different kinds of client-server links that fulfill three
separate purposes:
• Identification
• Configuration (also for control and status monitoring)
• Real-time data transfer
Each client-server link is assigned a separate port. Note that TCP and UDP communication may be held
simultaneously on the same port and separate client-server links. The packets are directed to the program
according to the packet type (TCP or UDP).
The identification server is connectionless (UDP), the configuration server is connection-oriented (TCP),
while the real-time data transfer (data server) can be of either type (see section 10.5.3 on page 73).
Identification Server
The identification server’s purpose is to allow a client to broadcast requests to all sensors on the network.
This is useful when the client wants to list all sensors present on a given network.