...
Introduction
The radar acts as a TCP/IP server and therefore listens for connections once started. The server will support up to 3 concurrent client connections, therefore the first 3 clients attempting to connect will succeed, but subsequent attempts from other clients will fail. The radar supports a primary IP address and streams data over a single port, which, by default, is the IANA allocated port of TCP 6317. The IP addresses and the port are all configurable via the radar management software. Please refer to reference Vertex documentation for more information.
...
This payload will be variable length, the size being specified in the message header. The rest of this document describes the message types.
Keep Alive Message
Message | ID | Direction |
|---|---|---|
Keep alive | 1 | From radar |
Keep-alive messages are sent by the radar to monitor client connections. If a client connects to a radar, but does not request radar data (FFT, health messages, navigation data, etc.) the radar will send a keep-alive message every 5 seconds. Once a client requests any data from radar, the radar will stop sending keep-alive messages to that client. Similarly, should a client disable all radar data requests, the radar will resume sending keep-alive messages to the client.
The keep-alive message has no payload. Clients are not required to process, or respond to, keep-alive messages.
Configuration Message
Message | ID | Direction |
|---|---|---|
Configuration | 10 | From radar |
The configuration message contains all the relevant information a client application needs to process raw data from the radar. The message provides all critical data in fixed length fields at the beginning of the message. These values are the minimum required in order to successfully configure a client. These fields can be accessed using the normal process of decoding a byte stream coming across the network. The remainder of the message is made up from a variable length Protocol Buffer message which contains additional information about the radar, such as serial numbers and service dates. Advanced customer applications would be expected to decode this message data however the information is optional.
...
Configuration Request Message
Message | ID | Direction |
|---|---|---|
Configuration request | 20 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will respond by sending a single configuration message.
Start FFT Data Request Message
Message | ID | Direction |
|---|---|---|
Start FFT Data | 21 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will respond by starting the raw radar data stream.
Stop FFT Data Request Message
Message | ID | Direction |
|---|---|---|
Stop FFT Data | 22 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will respond by stopping the raw radar data stream.
Start Health Message
...
Message | ID | Direction |
|---|---|---|
Start Health Messages | 23 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will start sending regular health messages. By default the interval is every 5
seconds.
Stop Health Message
Message | ID | Direction |
|---|---|---|
Stop Health Messages | 24 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will stop sending regular health messages.
Reset RF Health Check System
Message | ID | Direction |
|---|---|---|
Reset RF Health | 25 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will reset the long term health check system.
System Restart Message
Message | ID | Direction |
|---|---|---|
System Restart | 76 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will reboot.
Start Navigation Data Message
Message | ID | Direction |
|---|---|---|
Start Nav Data | 120 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will start sending navigation data messages.
Stop Navigation Data Message
Message | ID | Direction |
|---|---|---|
Stop Nav Data | 121 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will stop sending navigation data messages.
Set Navigation Threshold
Message | ID | Direction |
|---|---|---|
Set Nav Threshold | 122 | To radar |
This message is used to set the threshold for the navigation system
...
Field | Type [Size] | Description |
|---|---|---|
Threshold | uint16_t [2] | Threshold to use for navigation data. This should be a value between 0 - 96.5 dB multiplied by 10 e.g 75.6dB is 756 |
Set Navigation Gain and Offset
Message | ID | Direction |
|---|---|---|
Set Nav Rage Gain and Offset | 124 | To radar |
This message is used to set a gain and offset that is used when by the onboard navigation system, this gain and offset are applied to the ranges found using the formula [(Target Range * Range Gain * Range Resolution) + Offset].
...
Field | Type [Size] | Description |
|---|---|---|
Gain | uint32_t [4] | Gain multiplied by 1000000 |
Offset | uint32_t [4] | Offset multiplied by 1000000 |
...
Offset multiplied by 1000000 |
FFT/High Precision Data Message
Message | ID | Direction |
|---|---|---|
FFT Data | 30 | From radar |
High Precision FFT Data | 31 | From radar |
The FFT Data message contains all the necessary information to process the amplitude data for a specific azimuth. The packet consists of 4 fixed length fields and a variable length byte array of amplitude data. Each byte of amplitude data represents a range bin. The total number of reported range bins can varying per packet depending on the radar configuration. The size of this message body is specified by the payload size field in the header. The FTT Data length can be calculated by subtracting the fixed length field sizes from the overall payload size (i.e. Payload Size – 14 bytes). FFT Data messages need to be switched on before they are sent. Once activated, FFT Data messages will be sent continuously for each sampled azimuth. FFT data will continue to be sent until the radar receives a message to stop. Clients should honour this mechanism and, where possible, send the radar a stop message before disconnecting.
...
| Info |
|---|
For HDR units this point is the line running from the rear hole to the middle hole of the three on the base of the radar: |
...
Navigation Data Message
Message | ID | Direction |
|---|---|---|
Navigation Data | 123 | From radar |
The Navigation Data message contains the targets found for an azimuth that were above the threshold. The packet consists of 3 fixed length fields and a variable length byte array containing target information. The size of this message body is specified by the payload size field in the header. The Navigation Pairs Data length can be calculated by subtracting the fixed length field sizes from the overall payload size (i.e. Payload Size – 10 bytes). Navigation Data messages need to be switched on before they are sent. Once activated, Navigation Data messages will be sent continuously for each sampled azimuth. Navigation data will continue to be sent until the radar receives a message to stop. Clients should honour this mechanism and, where possible, send the radar a stop message before disconnecting.
...
Field | Type [Size] | Description |
|---|---|---|
Range | uint32_t [4] | Range in metres multiplied by 1000000 |
Power | uint16_t [2] | Power of target dB multiplied by 10 e.g 75.6dB is 756 |
Health Message
Message | ID | Direction |
|---|---|---|
Health | 40 | From radar |
The health message includes critical health information about the radar. The payload consists of a number of health status structures, each one provides data on a specific metric, for example temperature, and includes details on the current measurement and whether the metric is within expected bounds or not. The health message payload is a Protocol Buffer serialised byte array. In order to de-serialise the message the client will need to use the Google library as described in reference [2]. Metrics may be added or changed within the content of the Protocol Buffer message. This would not result in a new protocol version for this message. Client applications consuming this message will need the latest Protobuf definition file from Navtech. These are available on request. Health messages need to be switched on before they are transmitted. Once active, health messages will be sent every 5 seconds. Messages will continue to be sent until the radar receives a message to stop. Clients should honour this mechanism and, where possible, send the radar a stop message before disconnecting.
...
Field | Type [Size] | Description |
|---|---|---|
Network state | Enumeration | Current network state - UP, DOWN or UNKNOWN |
Duplex | Enumeration | Network duplex - HALF or FULL |
Speed | uint32 | Network speed |
Contour Update Message
Message | ID | Direction |
|---|---|---|
Contour Update | 50 | To radar |
The Contour Update message controls the contour mode and contour map. The contour map is held on the radar and provides a mechanism to restrict the radar detection area. The map consists of a variable range per degree (i.e. 360). When a contour map is active, data is sent out from the radar for each degree up to the range specified. If the range is zero then no data is sent for that bearing. If the contour map is disabled or in its default configuration then the full range of data is sent for every azimuth (i.e. all data). There is also a test mode which can be set on the radar – this activates a pre-configured map which exhibits a distinctive data pattern. To disable the contour map the client should send an empty update message (just header). This will leave the contour configuration intact but tell the radar to stop using it. Alternatively the client can send a full contour map, in other words a maximum range value for each azimuth. This will have the same effect. The contour map, once active, restricts the amount of data sent over the network. The more restrictive the contour map, the less data that is sent.
Contour Update Message Structure
...
.
Contour Update Message Structure
...
Log Levels Get/Set Messages
Message | ID | Direction |
|---|---|---|
Logging Levels Request | 100 | To radar |
Logging Levels | 90 | From radar |
The log levels get and set messages enable a user to get the logging levels and set the logging levels of the radar software. The LoggingLevelRequest message is an empty payload message, the radar will respond with a LoggingLevel message that contains a Protocol Buffer object which is a list of Log Levels. The get log levels payload is a Protocol Buffer serialised byte array. In order to de-serialise the message the client will need to use the Google library as described in reference: https://developers.google.com/protocol-buffers/.
...
Field | Type [Size] | Description |
|---|---|---|
Items | List of LogLevel PB Messages | A list of Log Level Items |
Calibrate Accelerometer Message
Message | ID | Direction |
|---|---|---|
Calibrate Accelerometer | 125 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will start start the calibration process and store the values in the NVRAM.
Start Accelerometer Data Message
Message | ID | Direction |
|---|---|---|
Start Accelerometer | 126 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will start sending accelerometer data messages.
Stop Accelerometer Data Message
Message | ID | Direction |
|---|---|---|
Stop Accelerometer | 127 | To radar |
This message contains no body / payload. The message is sent just as a header. On receiving this
message the radar will start sending accelerometer data messages.
Accelerometer Data Message
Message | ID | Direction |
|---|---|---|
Accelerometer Data | 128 | From radar |
This message contains the three angles representing the tilt of the radar, Θ (theta), Ψ (psi) and ɸ (phi).
...
Field | Type [Size] | Description |
|---|---|---|
Θ (theta) | float [4] | Angle around axis running perpendicular to zero/north - +ve Tilted Forward, -ve Tilted Backward |
Ψ (psi) | float [4] | Angle around axis running from base to stop of radome |
ɸ (phi) | float [4] | Angle around axis running through radar zero/north - +ve Tilted Right, -ve Tilted Left -ve Tilted Left |
Navigation Alarm Data
Message | ID | Direction |
|---|---|---|
Navigation Alarm Data | 143 | From radar |
This messages contains the six alarm states of the SafeGuard Lite feature
...
Navigation Area Rules Get/Set Messages
Message | ID | Direction |
|---|---|---|
Request Navigation Area Rules | 206 | To radar |
Navigation Area Rules | 144 | From radar |
This message configures the SafeGuard Lite feature with up to six areas that can cause an alarm state if a target is detected above the area threshold inside the area.
...
Navigation Configuration Get/Set Messages
Message | ID | Direction |
|---|---|---|
Navigation Configuration Request | 203 | To radar |
Navigation Configuration | 204 | From radar |
Set Navigation Configuration | 205 | To radar |
The Navigation Configuration Get/Set message allows the client to request the current Navigation Configuration from the Radar, and provide an update to supersede the current configuration. This is only supported by NavOS radars running firmware version 3.0.0.131 or later. A Navigation Configuration Request message is an empty payload message sent to the Radar, to which the Radar responds by sending a Navigation Configuration message. The client may sent an update of the Navigation Configuration parameters by sending a Set Navigation Configuration message.
...
Field | Type [Size] | Description |
|---|---|---|
Bins to operate on | uint16_t [2] | Defines the search window in bins for peak detection. |
Minimum bin | uint16_t [2] | The earliest bin for which peak detection will be enabled. |
Navigation Threshold | float [4] | The threshold level for target detection. This should be a value between 0 - 96.5 dB multiplied by 10 e.g 75.6dB is 756 |
Max Peaks Per Azimuth | uint32_t [4] | The maximum number of detection peaks that will be reported. Once the maximum number of peaks have been detected, further peaks will be ignored. |
Sector Blanking Message
Message | ID | Direction |
|---|---|---|
Sector Blanking |
...
Update | 51 | To radar |
A Sector Blanking message allows the client to update the set of blanking sectors for the Radar.
...
Time Source Status Get/Set messages
Message | ID | Direction |
|---|---|---|
Request Time Server Status | 207 | To radar |
Time Server Status | 208 | From radar |
The Time Source Status request message allows the client to query the current status of the NTP and/or PTP time source for the radar.
...
Field | Type [Size] | Description |
|---|---|---|
NTP enabled | bool [1] | Is the NTP service enabled (specifically, does the radar have its NTP remote address configured correctly) |
NTP synchronised | bool [1] | Is the time service on the radar synchronised with its time server |
NTP remote address | uint8_t[4] [4] | The address of the NTP remote. |
PTP enabled | bool [1] | Is the PTP service enabled |
PTP synchronised | bool [1] | Is the time service on the radar synchronised with its PTP server |
PTP remote address | uint8_t[4] [4] | The address of the PTP remote. If the PTP server is not enabled the IP address will be set to 0.0.0.0 |
Time seconds | uint32_t [4] | The radar’s clock time at the point of request. |
Time nanoseconds | uint32_t [4] | The nanosecond component of the radar’s clock time. |
Start / Stop radar
Message | ID | Direction |
|---|---|---|
Start Radar | 209 | To radar |
Stop Radar | 210 | To radar |
The Stop Radar message will stop the radar motor and disable the radar’s transmitter (if enabled) and stop the radar from rotating.
The Start Radar message will start the radar rotating and enable the transmitter.
A change in the radar’s state using these messages will persist after following a reboot or power-cycle. For example, if a running rotating radar is stopped via a Stop Radar message, then rebooted or power-cycled, the radar will power up restart in the stopped non-rotating state.
The default state of the radar (rotating) can be restored by performing a field reset on the radar.
...