Page Comparison

TCP Message Types

Signature

The 16 byte signature differs very slightly from the older Navtech RMB protocol. This does enable existing software to differentiate between the two protocols if required.

The new signature is as follows:

The TCP Message Body

This payload will be variable length, the size being specified in the message header. The rest of this document describes the message types.

Configuration Message

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.

The size of this message body is specified by the payload size field in the header. The size of the Protocol Buffer message can be calculated by subtracting the size of the fixed length fields from the payload size (i.e. Payload Size – 22 bytes). A configuration message is always sent when a client first connects and is also sent in response to a request from the client.

Configuration Message Structure

union v {
	float f;
	uint32_t i;
};
v value;
value.f = 186.4f;
uint32_t networkData = htonl(value.i);

Configuration Protocol Buffer Payload

Configuration Request Message

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

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

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

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

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

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

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

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

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

This message is used to set the threshold for the navigation system

Set Navigation Threshold Message Structure

Set Navigation Gain and Offset

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].

Set Navigation Gain and Offset Message Structure

FFT/High Precision Data Message

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.

FFT/High Precision Data Message Structure

Navigation Data Message

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.

Navigation Data Message Structure

Health Message

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.

Contour Update Message

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

Log Levels Get/Set Messages

The log levels get and get 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].

Log Levels Structure

Log Levels Buffer Payload

Calibrate Accelerometer Message

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

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

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

This message contains the three angles representing the tilt of the radar, Θ (theta), Ψ (psi) and ɸ (phi).

Accelerometer Data Message Structure

Navigation Alarm Data

This messages contains the six alarm states of the SafeGuard Lite feature

Navigation Area Rules

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

public static class Utility
{
	public static uint SwapUInt32(uint value)
	{
		return (uint)((SwapUInt16((ushort)((value & 0x000ffff))) << 0x10)) | (SwapUInt16((ushort)((value >> 0x10) & 0xffff)));
	}

	public static ushort SwapUInt16(ushort value)
	{
		return (ushort)(((value & 0xff) << 8) | ((value >> 8) & 0xff));
	}
}

public class NavVector
{
	public NavVector() { }

	public NavVector(float x, float y)
	{
		X = x;
		Y = y;
	}

	public float X { get; set; }
	public float Y { get; set; }

	public byte[] ToBytes()
	{
		var x = (short)(X * 10.0f);
		var y = (short)(Y * 10.0f);
		var data = (uint)(x << 16) | (uint)y;
		return BitConverter.GetBytes(Utility.SwapUInt32(data));
	}
}

public class NavArea
{
	public NavArea()
	{
		Points = new List<NavVector>();
	}

	public List<NavVector> Points { get; set; }

	public byte[] ToBytes()
	{
		var data = new List<byte>();
		data.AddRange(BitConverter.GetBytes(Utility.SwapUInt16((ushort)Points.Count)));
		Points.ForEach(point => { data.AddRange(point.ToBytes()); });
		return data.ToArray();
	}
}

public class NavAreaRule
{
	public NavAreaRule()
	{
		Enabled = true;
		InvertBreakLogic = false;
		ThresholdDelta = 0.0f;
		BreakAllowance = 16;
		AllowanceCurveDecrement = 4;
		AreaToCheck = new NavArea();
	}

	public byte Id { get; set; }
	public bool Enabled { get; set; }
	public bool InvertBreakLogic { get; set; }
	public float ThresholdDelta { get; set; }
	public ushort BreakAllowance { get; set; }
	public ushort AllowanceCurveDecrement { get; set; }
	public NavArea AreaToCheck { get; set; }

	public byte[] ToBytes()
	{
		var ruleData = new List<byte> { Id, Enabled ? (byte)1 : (byte)0, InvertBreakLogic ? (byte)1 : (byte)0 };
		ruleData.AddRange(BitConverter.GetBytes(Utility.SwapUInt16((ushort)(ThresholdDelta * 10.0f))));
		ruleData.AddRange(BitConverter.GetBytes(Utility.SwapUInt16(BreakAllowance)));
		ruleData.AddRange(BitConverter.GetBytes(Utility.SwapUInt16(AllowanceCurveDecrement)));
		ruleData.AddRange(AreaToCheck.ToBytes());
		var data = new List<byte>();
		data.AddRange(BitConverter.GetBytes(Utility.SwapUInt32((uint)ruleData.Count)));
		data.AddRange(ruleData);
		return data.ToArray();
	}
}

public class NavUpdateAreaRules
{
	public NavUpdateAreaRules()
	{
		Rules = new List<NavAreaRule>();
	}

	public List<NavAreaRule> Rules { get; set; }

	public byte[] ToBytes()
	{
		var data = new List<byte> { (byte)Rules.Count };
		Rules.ForEach(rule => { data.AddRange(rule.ToBytes()); });
		return data.ToArray();
	}
}

Related information