## 3 Description of the Maritime Data Transfer Protocol
### Messages from the Maritime Data Transfer Protocol
These bits are used to further define the kind of PDU that is sent within the 7 PDU types that have been defined previously. 4. _Sequence Operation (8 bits)_: randomly generated number used to relate petitions and responses. 5. _Data (480 bits)_: 60 bytes available to transfer data. Depending on the message type and subtype, some of these data bytes may be empty. The timestamp associated to this data will be provided by the INFO_TS submessage of the DDS message. \begin{table}
\begin{tabular}{c c c c c} \hline Euler Angles (Pitch) & Degrees & 32 bits & Float & 0.000–360.000\({}^{\circ}\) \\ \hline Euler Angles (Roll) & Degrees & 32 bits & Float & 0.000–360.000\({}^{\circ}\) \\ \hline Euler Angles (Yaw) & Degrees & 32 bits & Float & 0.000–360.000\({}^{\circ}\) \\ \hline Distance to seabed & m & 16 bits & Unsigned short & 0–4095.875 m \\ \hline Azimuth & Degrees & 32 bits & Float & 0.000–360.000\({}^{\circ}\) \\ \hline Vehicle speed & m/s & 32 bits & Float & 0.0–127.99609375 m/s \\ \hline Bearing & Rad & 32 bits & Float & \([-\pi,\pi]\) \\ \hline Gain & & 32 bits & Float & \\ \hline Altitude & m & 8 bits & Float & \\ \hline GSM & m/s & 32 bits & Float & \\ \hline X & m & 32 bits & Float & \\ \hline Y & m & 32 bits & Float & \\ \hline Target Yaw & Degrees & 32 bits & Float & 0.000–360.000\({}^{\circ}\) \\ \hline Target depth & m & 16 bits & Unsigned short & 0–4095.875 m \\ \hline \multicolumn{4}{c}{**Others**} \\ \hline Algorithm Identifier & \multicolumn{1}{c}{8 bits} & Octet & \\ \hline \end{tabular}
\end{table} 
Table 3: _Cont._  
\begin{table}
\begin{tabular}{c c c c c c c} \hline
**Message Type** & **Actions Involved** & \multicolumn{4}{c}{**FPOs Involved**} \\ \hline
As it was previously mentioned, Figure 3 is containing all the information regarding how PDUs look like in the Open Splice DDS version of DDS. This is an open source iteration of the DDS standard that contains the fields that were mentioned in Section 3.3:  
1. RTPS: this field is used to include the RTPS version that is used by the PDUs included in a DDS iteration. 2. Protocol version: used to include the protocol version used in this iteration. 3. Vendor ID: an identifier of the vendor that has developed the DDS iteration. 4. GUID prefix: it is the Globally Unique Identifier used to characterize the message that is sent via DDS. 5. Submessage INFO_TS: contains information about the timestamp of the message that was sent. 6. Submessage data: contains the information transferred. 7. Submessage heartbeat: used to control the periodicity of the information. At the same time, the PDU that is used for the CoreDX version developed by Twin Oaks has roughly the same fields (as it is an implementation of a standard), but there is an additional one used to include vendor-specific information from the developer. In addition to that, the data submessage is 40 bytes smaller, due to the fact that is not containing the inline QoS information that the OpenSpliceDDS version had. These characteristics have been depicted in Figure 4.  
It can be seen that despite claiming that there is interoperability between the Open Splice and CoreDX versions of DDS, both PDUs are of very different characteristics. This is due to the fact that they are different iterations of the DDS standard. Nevertheless, the tests that have been carried out guarantee that information has been transferred with no issues regarding the different features of OpenSpliceDDS and CoreDX.