Navi - Scan Reference Manual
Navi - Scan Reference Manual
Reference
Manual
NaviScan Reference Manual Page 2
1. INTRODUCTION ....................................................................................................................................... 4
1.1 SENSORS ................................................................................................................................................... 4
1.2 SERIAL AND NETWORK INTERFACING ....................................................................................................... 5
1.3 UTILITY AND OFFLINE PROGRAMS ............................................................................................................ 5
1.3.1 NaviScan Setup ............................................................................................................................... 5
1.3.2 XYZ Convert.................................................................................................................................... 5
1.3.3 XTF Convert ................................................................................................................................... 6
1.3.4 Extract ............................................................................................................................................ 6
1.3.5 Contour Patch Test ......................................................................................................................... 6
2. SENSOR FORMAT .................................................................................................................................... 7
2.1 ECHOSOUNDERS ........................................................................................................................................ 7
2.2 SIDESCAN ................................................................................................................................................. 8
2.3 PIPETRACKER ............................................................................................................................................ 8
2.4 POSITION ................................................................................................................................................... 9
2.5 GYRO ........................................................................................................................................................ 9
2.6 MOTION .................................................................................................................................................. 11
2.7 BATHY .................................................................................................................................................... 12
2.8 DOPPLER LOG .......................................................................................................................................... 13
2.9 GPS TIME ................................................................................................................................................. 14
2.10 LOGGING CONTROL ............................................................................................................................ 14
2.11 THEORETICAL PROFILE ....................................................................................................................... 14
3. DETAILED SONAR DATA FORMAT .................................................................................................. 15
3.1 MBE FORMATS ....................................................................................................................................... 15
3.1.1 Reson SeaBat 9000 ....................................................................................................................... 15
3.1.2 Reson SeaBat 8000 ....................................................................................................................... 15
3.1.3 SIS3000 ......................................................................................................................................... 17
3.1.4 Odom Echoscan ............................................................................................................................ 18
3.1.5 SeaKing (and ST1000) Profiler .................................................................................................... 18
3.1.6 EM3000 Raw range and beam ...................................................................................................... 19
3.1.7 SM2000 ......................................................................................................................................... 21
3.1.8 Hyspec modular scanner MK-II.................................................................................................... 21
3.1.9 STN Atlas Fansweep15 ................................................................................................................. 22
3.1.10 STN Atlas Fansweep20 ............................................................................................................ 22
3.1.11 STN Atlas TPE telegram .......................................................................................................... 22
3.1.12 Seabat 7k Telegrams ................................................................................................................ 23
3.1.13 Elac Hydrostar ......................................................................................................................... 27
3.1.14 Imagenex DeltaT ...................................................................................................................... 27
3.1.15 MS1000 profiler ....................................................................................................................... 29
3.1.16 BlueView .................................................................................................................................. 30
3.1.17 Odom ES .................................................................................................................................. 30
3.1.18 R2Sonic 2000 ........................................................................................................................... 30
3.2 SIDESCAN ................................................................................................................................................ 34
3.2.1 Reson SideScan (8000) ................................................................................................................. 34
3.2.2 Reson Snippets (8000) .................................................................................................................. 34
3.2.3 Stn Atlas ........................................................................................................................................ 36
3.2.4 Hugin XTF .................................................................................................................................... 36
3.2.5 EM3000 Compact ......................................................................................................................... 36
3.2.6 Seabat 7k Sidescan........................................................................................................................ 36
3.2.7 Elac Hydrostar.............................................................................................................................. 36
3.2.8 Benthos Imux 200 ......................................................................................................................... 36
3.2.9 Benthos C3D ................................................................................................................................. 37
3.2.10 EdgeTech.................................................................................................................................. 40
3.2.11 R2Sonic 2000 ........................................................................................................................... 40
1. Introduction
The NaviScan data acquisition software is designed specifically for the multi-beam echo
sounder and sidescan sonar technology. A wide range of echosounders, sidescans, pipetrackers
and supporting positioning instruments are supported. EIVA offers the optimal solution for
vessel and ROV surveys.
The basic purpose of NaviScan is to collect data from the Echosounder sensors and generate a
file with exact positions of each scan. To do this navigation information is needed along with
roll/pitch/heave, bathy sensor and gyro. To improve positions, NaviScan includes support for
Doppler Velocity Log. Another feature is included; combine echosounder data and pipe-tracker
to get the best pipeline survey.
The NaviScan package contains programs to convert the raw logged data to motion corrected
data which can be used in processing software packets. During this conversion phase, data is
corrected for pitch, roll, heading, C-0 etc., and all low-quality data is filtered out.
All NaviScan programs can be executed on one PC, as the multitasking environment allows
simultaneous execution of more programs without interfering with the on-line data time-
tagging: this very important process is placed in a dedicated real-time queue. For larger set-
up‟s, the system can be split on more computers
The NaviScan system works on a PC platform which is simple, easy-to-handle and involves
minimum mobilisation time. The system is flexible and user friendly. It offers precise time
tagging and maximum up-time for continuous operation. The system configuration is based on
the client/server philosophy and consists of one or more PC's (connected via a local area
network (LAN)). The system is divided into two parts; one is dedicated to on-line data collection
and logging and the other is used for off-line data conversion, filtering, editing, and
configuration set-up and data transportation.
The collected data is displayed on the screen so the operator can supervise the system; inspect
the quality of incoming data and to make sure that none of the sensors are dropping out.
Data collected for each survey line will be stored in a file named by the operator. When the line
is ended (on a signal from the navigation system or by operator) the file is closed.
1.1 Sensors
The echosounder sensors transfer information to NaviScan each scan. The scan information
includes timing, depths and ranges.
An integrated navigation system is used for the identification of current system position.
NaviScan can use data from any system giving Easting and Northing in a CR/LF terminated
serial string. A special input is included for EIVA's NaviPac online navigation system, which
furthermore allows remote control, DAL/DOL and KP information and on-line coverage
information.
For ROV jobs, a Doppler Velocity log can be used to improve the positioning accuracy; a filter
combining position long-term stability with Doppler short-term accuracy, gives a very accurate
solution.
To compute the exact position of each beam, NaviScan needs heading (gyro) information. The
system accepts any CR/LF terminated string giving the heading in decimal degrees.
Also the heave, roll and pitch data is needed for movement correction of each scan. NaviScan
accepts data in any CR/LF terminated string giving Roll and Pitch in decimal degrees and Heave
in cm.
When mounted on a ROV, the NaviScan system needs a bathy sensor giving the exact depth of
the ROV. NaviScan accepts data in any CR/LF terminated string giving depth in decimal
meters.
NaviScan supports integrated use of Pipe- or cable-tracker data; range to pipe can be combined
with multi-beam data to give the ultimate pipe survey solution.
The online NaviScan program reads the incoming sensor data from a special intelligent serial
communication board so that data I/O can be performed without interference from logging of the
data, computations and presentation.
Network is also used for interfacing primarily sensors with heavy data loads or time tagged data.
NaviScan supports both UDP and TCP communication
1.3.4 Extract
The NaviScan Extract Utility is used to generate windows EXCEL compatible files on basis of
data extracted from the raw logged data files. Consequently, graphs and tables over selected data
can easily be created. This feature is mainly of interest during the calibration and quality control
phase
2. Sensor Format
NaviScan supports I/O for a number of predefined sensors, and gives the opportunity to
define new sensors as long as it outputs a fixed terminated string and the information is
located with a given offset from the beginning of the received string.
Hereafter are listed the different possible sensor types in the SBD format. The enum id and
the corresponding static char string identities the different sensors, and we try to keep these
updated, after that follow a frame of the same and some extra information, but possibly new
sensor may not be updated in the frames.
The field “SBD id” has been added, so that it‟s possible to convert an id in the SBD file to the
type. See Header Record. The order of these ids will never change; new sensors will always
be added at the end.
The definitions are per January 2011
2.1 Echosounders
NaviScan supports the following MBE systems. The type number will be of interest if you
want to decode the SBD files
static char echosoundertypes[ENUMBER][30] = {
"No echosounder system", // 0
"SeaBat S9001 R-Theta", // 1
"SeaBat S9002 R-Theta", // 2
"SeaBat 81xx", // 3
"SIS-3000", // 4
"Odom Echoscan", // 5
"SeaKing Profiler", // 6
"SeaKing Profiler Dual head", // 7
"ST1000 Profiler", // 8
"ST1000 Profiler Dual head", // 9
"EM3000 (Raw Range&Beam only)", // 10
"SeaBat 81xx(2-Heads)", // 11
"SM2000", // 12
"Hyspec modular scanner MK-II", // 13
"ATLAS FANSWEEP15", // 14
"EM3000 Dual head (Raw R&B)", // 15
"EM3000 Special (Hugin)", // 16
"ATLAS FANSWEEP20", // 17
"Benthos C3DMBE", // 18
"Reserved", // 19
"Reson Seabat7K", // 20
"Reson Seabat7KDual", // 21
"ATLAS HYDROSWEEP", // 22
"Elac Hydrostar", // 23
"Elac HydrostarDual", // 24
"Imagenex DeltaT", // 25
"Imagenex DeltaTDual", // 26
"MS1000 profiler", // 27
"BlueView", // 28
"BlueViewDual", // 29
"Odom ES3", // 30
2.2 SideScan
NaviScan supports the following SideScan systems. The type number will be of interest if
you want to decode the SBD files
2.3 Pipetracker
NaviScan supports the following pipetracker systems
2.4 Position
NaviScan supports the following position data inputs:
2.5 Gyro
NaviScan supports the following heading data inputs:
Type String Lay-out Note SBD id
FREE Ex. "ggg.g<CR><LF>" Any fixed terminated 0
serial string (max. 90
characters) giving the gyro
as decimal degree.
NMEA “$??HDT,ggg.g…<CR><LF> 6
NMEA(jic) “$HCHDM,ggg.g...<CR><LF>" 7
CDL H123.45P+12.345R+123.456 22
M123W1234.56U12.3<cr><lf>
MDL H1234P+1234R+1234<cr><lf> 23
Edgetech Binary 27
2.6 Motion
NaviScan supports the following attitude data inputs:
Seatex MRU-5/6 Coded information giving roll, pitch and heave as Set-up to give 2
binary floats. continuously output
"qltRRRRPPPPHHHH" (minimum 10 times a
second) in the given order
(Roll, Pitch, Heave)
N/A 20
CDL H123.45P+12.345R+123.456 21
MDL H1234P+1234R+1234<cr><lf> 22
2.7 Bathy
NaviScan supports the following bathy/height data inputs:
HoneywellPPTR20 #01CP=p.ppp<cr> 23
PosmvGGA GpsHgt", binary telegram – height from psotion packet LAN only 24
Echosounder (MBE and scanning sonars) data logged as received, and is raw data that must
be interpreted according to the manufactures specification; in this document we have inserted
how Eiva interprets some of the possible echosounder (the first interfaced ones). Eiva can
provide our own header files for all interfaced echosounders.
If the system uses SeaBat 9002, it will be implemented as two separate interfaces giving the
above information.
For details on how to interpret the data please refer to relevant Reson documentation
// address
BYTE sonar_model[2]; // coded model number of sonar
BYTE frequency[2]; // sonar frequency in KHz
BYTE velocity[2]; // 2 bytes velocity of sound m/s
BYTE sample_rate[2]; // 2 bytes sample rate in ms
BYTE ping_rate[2]; // 2 bytes pings per second
BYTE range_set[2]; // 2 bytes range setting for SeaBat (meters)
BYTE power[2]; // 2 bytes power setting for SeaBat
// bits 0-4 power (0 - 8)
// bit 15 0 = manual, 1= auto
BYTE gain[2]; // 2 bytes gain setting for SeaBat
// bits 0-6 gain (0 - 45)
// bit 14 0 = fixed, 1 = tvg
// bit 15 0 = manial, 1 = auto
BYTE pulse_width[2]; // 2 bytes transmit pulse width microsec
BYTE tvg_spread; // 1 bytes spreading coef. for tvg * 4
BYTE tvg_absorp; // 1 bytes absorption coef. for tvg
BYTE projector; // 1 bytes projector setting ???
3.1.3 SIS3000
typedef struct SIS3000InputPacket
{
float ping_number;
float packetSize; // size of entire packet [bytes]
float portErrorIndex; //CPU_A1_OverRun_Error;
float data[1];
float PORT_Angle[SIS3000_UPLOAD_SIZE]; // degrees
float STBD_Angle[SIS3000_UPLOAD_SIZE]; // degrees
float Slant_Range[SIS3000_UPLOAD_SIZE];
float Time_Index[SIS3000_UPLOAD_SIZE]; // in seconds from start
float Sub_Bottom_Data[SIS3000_UPLOAD_SIZE];
} SIS3000_PACKET;
/**This datagram replaces the previous Raw range and beam angle
f datagram for the new multibeam models (starting with EM
710). All receiver beams are included, check detection info and
real time cleaning for beam status (see note 3 and 4).*/
// applied) 2U 0 to 65534 --
float signallen; //Signal length in s 4F -- --
float txdelay; //Sector transmit delay re first TX pulse, in
//s 4F -- --
float centrefrq; //Centre frequency in Hz 4F -- --
USHORT absorpcoef; //Mean absorption coeff. in 0.01 dB/km 2U --
BYTE waveformid; //Signal waveform identifier 1U 0 to 99 1
BYTE txsector; //Transmit sector number 1U 0 -- --
float signalbw; //Signal bandwidth in Hz 4F -- --
} EM3000RAWSECTOR4E;
//followed by EM3000RAWBEAM4E
3.1.7 SM2000
The packet shown below is the one supported. It is not supported to change the number of
beams to anything else but maximum.
TYPEDEF STRUCT SM2000INPUTPACKET
{
BYTE START[4]; // 4 BYTES 0XFF 0XFF 0X00 0X00
BYTE TYPE[1]; // 1 BYTES 0X10
BYTE SUBTYPE; // 1 BYTES 0X01 --> (MPB OR MPH TYPE)
// 0X02 --> (MAB OR MAH TYPE)
BYTE TIMEDAY[4]; // 4 BYTES TIME AND YEAR
BYTE PINGNR[4]; // 4 BYTES PINGNUMBER (LSB FIRST)
BYTE MONTH; // 1 BYTE CURRENT MONTH (1..12)
BYTE PINGTIME[4]; // 4 BYTES PINGTIME (LSB FIRST, 50 US UNITS)
BYTE DAY; // 1 BYTE CURRENT DAY (1..31)
BYTE VELOCITY[2]; // 2 BYTES VELOCITY OF SOUND M/S (LSB FIRST)
BYTE LATENCY[2]; // 2 BYTES DELAY IN MS (LSB FIRST)
BYTE SAMPLE_RATE[2]; // 2 BYTES SAMPLE RATE IN HERTZ
BYTE SCANWIDTH; // 1 BYTE TRANSDUCER SCAN WIDTH (120,180) DEG
BYTE TOTALNUMOFBEAMS; // 1 BYTE TOTAL NUMBER OF BEAMS, NORMALLY 128
BYTE STARTBEAMNR; // 1 BYTE START BEAM NUMBER. (0..127)
BYTE NUMOFBEAMSUSED; // 1 BYTE NUMBER OF BEAMS USED (1..128) NB
BYTE NUMOFRETURNS; // 1 BYTE NUMBER OF RETURNS (1..4) NR
BYTE ATBEAMWIDTH; // 1 BYTE ALONG TRACK BEAM WIDTH I 1/10 DEGREE UNITS
BYTE SYSTEMRANGE[4]; // 4 BYTES SYSTEM RANGE IN CENTIMETERS
BYTE BEAMS[2*128*4]; // 1024 BYTES MAX
// AMOUNT = 2 * NR * NB
} SM2000_PACKET; // 36 BYTES HEADER + UPTO 1024 BYTES DATA
Range packet:
M-10 ( setup packet)
M-11( packet 1)
M-11( packet 2)
...
struct TPE_Results_BLK {
Block_No block_no;
long block_cnt;
Dtime data_time;
long nofResults;
long beamno[20];
double dX[20];
double dY[20];
double dZ[20];
double dpos[20];
double fDsize[20];
double dTPEMax;
double fDsizeMin;
double pTPEMax;
};
struct TPE_Results_IP {
Info_Block infob;
TPE_Results_BLK tperesb;
};
The TPE telegram is sent from another IP address in the sidescan processor than M-10 , M-11
etc . which means that the user will have to enter this different IP address, together with the
port for the TPE telegram in the STN Atlas.ini file. See the setup manual.
}S7KNETWORKFRAME;
}S7KDATARECORDFRAME;
}S7400RECORD;
}S7500RECORD;
}S7008RECORD;
}S7008BI;
UNION
{
S7400RECORD TIMEREC;
S7500RECORD CTRLREC;
S7000RECORD SETTINGREC;
S7001RECORD CONFIGREC;
S7004RECORD ANGLEREC;
S7006RECORD RANGEREC;
S7007RECORD BACKSCATREC;
S7008RECORD BEAMDATAREC;
S7027RECORD RAWDETECTREC;
S7028RECORD SNIPPETREC;
}DATA;
}S7KDATARECORD;
}S7KNETWORKPACK;
{
char
hinfo[3]; //3 "83P"
BYTE
version; //1 3 = v1.03
WORD
numbytes; //2 total num of bytes
char
reserved1[2];//2
char
date[12]; //12 telegram time "DD-MMM-YYYY"
char
time[9]; //9 telegram time "HH:MM:SS"
char
hsec[4]; //4 telegram time ".hh"
char
lat[14]; //4 _dd.mm.xxxxx_N
char
lon[14]; //4 _dd.mm.xxxxx_E
BYTE
shipspeed; //1 Speed = (Byte 61)/10 in knots
WORD
shipheading; //2 Heading * 10 (in degrees)
WORD
ompitch; //2 (Pitch Angle*10) + 900 (in degrees)
WORD
omroll; //2 (Roll Angle*10) + 900 (in degrees)
WORD
omheading; //2 (Roll Angle*10) + 900 (in degrees)
WORD
numbeams; //2 num beams
WORD
samplesprbeam;//2 samples per beam
WORD
sectorsize; //2 sector size in degrees
WORD
startangle; //2 [Start Angle (in degrees) + 180] * 100 (beam 0)
BYTE
angleincr; //1 Angle spacing per beam = (Byte 78)/100 in deg
WORD
acoufrq; //2 Acoustic Frequency (in kHz)
WORD
acourange; //2 Acoustic Range (in meters)
WORD
soundvel; //2 Sound Velocity (in meters/second) * 10
WORD
rangeres; //2 Range Resolution (in millimeters)
WORD
reserved2; //2 Reserved always 0
WORD
tiltmount; //2 Profile Tilt Angle (in degrees) * 10 + 1800
// (mounting offset)
WORD reptrate; //2 Repetition Rate (in milliseconds)
DWORD pingno; //4 ping number
char reserved3[3];//3 Reserved always 0
float xoffset; //4 Sonar X-Offset (in meters)
float yoffset; //4 Sonar Y-Offset (in meters)
float zoffset; //4 Sonar Z-Offset (in meters)
// from here only valid for .83P file
char msec[5]; //5 Milliseconds system time, null terminated
// string (5 bytes) ".mmm"
BYTE hasintens; //1 Intensity Bytes Included 0 / 1
WORD pinglatency; //2 Ping Latency (in units of 100 microseconds)
WORD datalatency; //2 Data Latency (in units of 100 microseconds),
//Time Since Ping = Data Latency - Ping Latency
char reserved[134];//134 Reserved - always 0
}IMG83S;
//WORD range[n]; hereafter (to be swapped before usage
//256 to xxx Sonar Header #X and Profile Ranges for current ping (2 range
bytes / beam) xxx = 256 + (2 * number_of_beams) – 1
3.1.16 BlueView
Same as Reson 7K
3.1.17 Odom ES
Same as Imagenex DeltaT
// section G1: 8-bit gate positions, arbitrary paths (present only during
// "verbose" gate description mode)
typedef struct _R2SGATE2SECTION
{
u16 G1_SectionName; // 'G1'
u16 G1_SectionSize; // [bytes] size of this entire section
f32 G1_ScalingFactor;
struct
{
u8 RangeMin; // [seconds two-way] = RangeMin *
// G1_ScalingFactor
u8 RangeMax; // [seconds two-way] = RangeMax *
// G1_ScalingFactor
} G1_Gate[1]; // [H0_Points]
// u16 G1_unused[H0_Points & 1]; // ensure 32-bit section size
} R2SGATEVERBSECTION;
3.2 Sidescan
Sidescan data is logged as received, and is raw data that must be interpreted according to the
manufactures specification; in this document we have inserted how Eiva interprets some of
the possible sidescans (the first interfaced ones). Eiva can provide our own header files for all
interfaced sidescans.
Some of the first interfaced sidescans raw datagram‟s:
struct SNP0 /* ping header (there are BEAMS snippets per ping) */
{
unsigned long ID; /* identifier code */
unsigned short HeaderSize; /* header size, bytes */
unsigned short DataSize; /* data size following header, bytes */
unsigned long PingNumber; /* sequential ping number */
unsigned long Seconds; /* time since since 00:00:00, 1.1 1970 */
unsigned long Millisec;
unsigned short Latency; /* time from ping to output (ms) */
unsigned short SonarID[2]; /* least significant four bytes of
Ethernet address */
unsigned short SonarModel; /* coded model number of sonar */
unsigned short Frequency; /* sonar frequency (kHz) */
unsigned short SSpeed; /* programmed sound velocity (m/sec) */
unsigned short SampleRate; /* A/D sample rate (samples/sec) */
unsigned short PingRate; /* pings per second, 0.001 Hz steps */
unsigned short Range; /* range setting (meters) */
unsigned short Power; /* power */
unsigned short Gain; /* gain (b15=auto, b14=TVG, b6..0=gain) */
unsigned short PulseWidth; /* transmit pulse width (microseconds) */
unsigned short Spread; /* TVG spreading, n*log(R), 0.25dB steps
*/
unsigned short Absorp; /* TVG absorption, dB/km, 1dB steps */
unsigned short Proj; /* b7 = steering, b4..0 = projector type
*/
unsigned short ProjWidth; /* transmit beam width along track, 0.1
deg steps */
unsigned short SpacingNum; /* receiver beam spacing, numerator,
degrees */
unsigned short SpacingDen; /* receiver beam spacing, denominator */
short ProjAngle; /* projector steering,
degrees*PKT_STEER_RES */
unsigned short MinRange; /* range filter settings */
unsigned short MaxRange;
unsigned short MinDepth; /* depth filter settings */
unsigned short MaxDepth;
unsigned short Filters; /* enabled filters: b1=depth, b0=range */
struct /* one byte containing eight status flags
*/
{
unsigned Spare : 12;
unsigned SnipMode : 3; /* menu item setting */
unsigned RollStab : 1; /* bit0: roll stabilization enabled */
} bFlags;
short HeadTemp; /* head temperature, 0.1C steps */
unsigned short BeamCnt; /* number of beams */
};
typedef struct
{
DWORD RunningCounter; // (W,M) Increments with each ping put into
// circular buffer
WORD Year; // (W,M) Time of day for the ping. Note that
// this exactly
WORD Month; // (W,M) mimics the SYSTEMTIME structure.
WORD DayOfWeek; // (W,O) Not used in Isis.
WORD Day; // (W,M)
WORD Hour; // (W,M)
WORD Minute; // (W,M)
WORD Second; // (W,M)
WORD Milliseconds; // (W,O) Thousands of seconds for time of day
DWORD MillisecondTimer; // (W,O) GetTickCount() value at time of ping
WORD HideFlag; // (W,O) Set to 1 if this ping should not be
// displayed (hide this ping)
WORD SonarStatusWord; // (W,O)
SERIALDATA SerialData; // (W,O) Telemetry data (pitch, roll, etc)
// that changes with each ping
char Reserved[64]; // reserved for future expansion
int NumChannels; // (W,M) Num channels in this ping, max 32
char ChannelTypes[32];
// (W,M) For each channel: 0=SUBBOTTOM,
// 1=PORT, 2=STBD
char BytesPerSample[32];// (W,M) 1 or 2 bytes per sample
int SamplesPerChannel[32];// (W,M) Number of samples in each channel
// (usually all the same)
float DelayPeriod[32]; // (W,O) Amount of time elapsed from trigger
// to first sample (usually 0.0)
float TimePeriod[32]; // (W,M) amount of time represented in each
// channel in milliseconds
float PingRate[32]; // (W,M) Amount of time from trigger to
// trigger in milliseconds. Usually equal to
// TimePeriod.
float AlongTrackSize[32];// (W,O) Used primarily for focused
// multibeam sonars. The amount of along-
// track distance (in meters) to be assigned
// to this ping. If 0.0, Isis will compute
// this value based on range scale and fish
// speed.
IMUXEXTRAPAC xtrpac;
// The image data follows here, each channel one after the other.
} IMUXMODPINGINFO;
typedef struct
{
unsigned int MsgCounter;
float SoundVelocity; //1002 latest received data
float SensorSpeed; //1004 latest received data
float SensorDepth; //1006 latest received data
float SensorAltitude; //1008 latest received data
int SonarRange; //1110 latest received data
int SonarOnOff; //1104 latest received data
int SubBottomPowerControl; //1106 latest received data
BYTE ChannelGainControl[32]; //1108 latest received data
char TelemetryPacket[256]; //1036 latest received data
char SystemTypePacket[32]; //1038 latest received data
}IMUXEXTRAPAC;
#pragma pack( 1 )
typedef struct
{
long RunningCounter;
short Year;
short Month;
short DayofWeek;
short Day;
short Hour;
short Minute;
short Second;
short Milliseconds;
double MillisecondTimer;
double Latency;
short HideFlag;
short SonarStatusWord;
unsigned char Reserved[PINGRESERVEDBYTES1];
int NumChannels;
unsigned char ChannelTypes[32];
unsigned char BytesPerSample[32];
int SamplesPerChannel[32];
double DelayPeriod[32];
double TimePeriod[32];
double PingRate[32];
double PulseLength[32];
double SamplePeriod[32];
unsigned char Reserved2[PINGRESERVEDBYTES2];
} C3DPINGINFO;
For each ping, each channel is saved in a contiguous block after the ping header. The type of
data, number of samples etc., for each channel is saved in the ping header for the same ping.
For C3D data the ping header parameters are used as follows (note that SamplesPerChannel
can vary between pings and between channels). NI indicates not implemented:
ChannelTypes:
50 -> RANGEDATA[SamplesPerChannel[CHANNEL]] = Sample Index data, Segment 0 Port
51 -> RANGEDATA[SamplesPerChannel[CHANNEL]] = Sample Index data, Segment 0 Stbd
52 -> RANGEDATA[SamplesPerChannel[CHANNEL]] = Sample Index data, Segment 1 Port
53 -> RANGEDATA[SamplesPerChannel[CHANNEL]] = Sample Index data, Segment 1 Stbd
54 -> RANGEDATA[SamplesPerChannel[CHANNEL]] = Sample Index data, Segment 2 Port
55 -> RANGEDATA[SamplesPerChannel[CHANNEL]] = Sample Index data, Segment 2 Stbd
56 -> RANGEDATA[SamplesPerChannel[CHANNEL]] = Sample Index data, Segment 3 Port
57 -> RANGEDATA[SamplesPerChannel[CHANNEL]] = Sample Index data, Segment 3 Stbd
60 -> ANGLEDATA[SamplesPerChannel[CHANNEL]] = Angle data, Segment 0 Port
61 -> ANGLEDATA[SamplesPerChannel[CHANNEL]] = Angle data, Segment 0 Stbd
62 -> ANGLEDATA[SamplesPerChannel[CHANNEL]] = Angle data, Segment 1 Port
63 -> ANGLEDATA[SamplesPerChannel[CHANNEL]] = Angle data, Segment 1 Stbd
64 -> ANGLEDATA[SamplesPerChannel[CHANNEL]] = Angle data, Segment 2 Port
65 -> ANGLEDATA[SamplesPerChannel[CHANNEL]] = Angle data, Segment 2 Stbd
66 -> ANGLEDATA[SamplesPerChannel[CHANNEL]] = Angle data, Segment 3 Port
67 -> ANGLEDATA[SamplesPerChannel[CHANNEL]] = Angle data, Segment 3 Stbd
70 -> AMPDATA[SamplesPerChannel[CHANNEL]] = Amplitude data, Segment 0 Port
71 -> AMPDATA[SamplesPerChannel[CHANNEL]] = Amplitude data, Segment 0 Stbd
72 -> AMPDATA[SamplesPerChannel[CHANNEL]] = Amplitude data, Segment 1 Port
73 -> AMPDATA[SamplesPerChannel[CHANNEL]] = Amplitude data, Segment 1 Stbd
74 -> AMPDATA[SamplesPerChannel[CHANNEL]] = Amplitude data, Segment 2 Port
75 -> AMPDATA[SamplesPerChannel[CHANNEL]] = Amplitude data, Segment 2 Stbd
76 -> AMPDATA[SamplesPerChannel[CHANNEL]] = Amplitude data, Segment 3 Port
77 -> AMPDATA[SamplesPerChannel[CHANNEL]] = Amplitude data, Segment 3 Stbd
90 -> QCDATA[SamplesPerChannel[CHANNEL]] = QC data, Segment 0 Port NI
91 -> QCDATA[SamplesPerChannel[CHANNEL]] = QC data, Segment 0 Stbd NI
92 -> QCDATA[SamplesPerChannel[CHANNEL]] = QC data, Segment 1 Port NI
93 -> QCDATA[SamplesPerChannel[CHANNEL]] = QC data, Segment 1 Stbd NI
94 -> QCDATA[SamplesPerChannel[CHANNEL]] = QC data, Segment 2 Port NI
95 -> QCDATA[SamplesPerChannel[CHANNEL]] = QC data, Segment 2 Stbd NI
96 -> QCDATA[SamplesPerChannel[CHANNEL]] = QC data, Segment 3 Port NI
97 -> QCDATA[SamplesPerChannel[CHANNEL]] = QC data, Segment 3 Stbd NI
100 -> SSDATA[SamplesPerChannel[CHANNEL]] = Sidescan data, Port
101 -> SSDATA[SamplesPerChannel[CHANNEL]] = Sidescan data, Stbd
255 -> SARAINFO[1024] = SARA sonar parameters data structure (1024 bytes,
proprietary)
254 -> CAATIINFO[1024] = CAATI processing parameters data structure (1024 bytes,
proprietary)
/*
Channel Data Types
*/
char SARAINFO[1024];
char CAATIINFO[1024];
unsigned short RANGEDATA[];
signed short ANGLEDATA[];
unsigned short AMPDATA[];
unsigned short SSDATA[];
char QCDATA[]; /* NI */
char SERIALDATA[];
char STATUSDATA[];
Example:
NumChannels = 10;
ChannelTypes = {255,254,50,60,70,51,61,71,100,101,253};
BytesPerSample = {1024,1024,2,2,2,2,2,2,2,2,1};
SamplesPerChannel = {1,1,e,e,e,f,f,f,g,g,k};
// where e is the number of 3D sidescan samples
// for port, f is number of stbd 3D sidescan output samples,
// g is the number of port and stbd 2D sidescan samples
// and k is the number of ascii status bytes
DelayPeriod = {h,h,h,h,h,h,h,h,h,h,h};
// where h is the delay in ms after transmit to the first
// sample
PingRate = {i,i,i,i,i,i,i,i,i,i}; // i=time between transmits in ms
TimePeriod = {j,j,j,j,j,j,j,j,j,j,j}; // j=total time rep by each channel (ms)
Data follows the ping header and is organized as 2 blocks of proprietary information (channel
types 255 and 254) followed by 6 blocks of 3D sidescan data (with a variable number of short
integer values in each block), followed by 2 blocks of 2D sidescan data, followed by one
block of ASCII status information.
3D sidescan blocks corresponding to the same AOA segment have the same number of
samples. Currently only one segment (segment 0) is used and contains all 3D sidescan data.
3.2.10 EdgeTech
This section describes the format of the raw data files and an example of the disk space required
for logging.
1. Header Record
2. Multibeam echosounder Record
3. Doppler Velocity Record
4. Pipetracker Record
5. Position Record
6. Filtered position Record
7. Sound velocity profile Record
8. Theoretical profile Record
9. Sidescan image Record
10. Target Record
From ver 7.7 the Huge packet disappears again as the new header has 4byte size
Old version huge packets:
For the “C” Huge Sidescan one must pay special attencion to the change of nSubPacket and
size fields. If the C specifier is used in the file (for the time being only for Benthos C3D
sidescan), the filereader must first look at the specifier and the decide the packet size, for
each packet in the file. For C spec the following header is valid:
Start time : Gives the start date and time for current line. Given in C notation
SYSTEMTIME
NB setup : Specifies the current system set-up. Copy of NaviScan.bin
Version : Gives the current NaviScan version number in ASCII
#pragma pack(push,1)
POSITIONSETUP8_2 PositionSetup[MAX_MULTIPLE_SENSORS];
// Array of additional position sensors setup structure
GYROSETUP8_2 GyroSetup[MAX_MULTIPLE_SENSORS];
// Array of additional gyro sensors setup structure
MOTIONSETUP8_2 MotionSetup[MAX_MULTIPLE_SENSORS];
// Array of additional motion sensors setup structure
BATHYSETUP8_2 BathySetup[MAX_MULTIPLE_SENSORS];
// Array of additional bathy sensors setup structure
AUXILIARYSETUP8_2 AuxiliarySetup[MAX_MULTIPLE_SENSORS];
// Array of additional aux interpreted sensors setup structure
RAWDATASETUP8_2 RawdataSetup[MAX_MULTIPLE_SENSORS];
// Array of rawdata sensors setup structure
} MULTIPLESENSORS8_2;
// =====================================================================
// Setup of Sensors
// =====================================================================
MULTIPLESENSORS8_2 multiplesensors;
} NBSETUP8_2;
Note the byte alignment is default 8 byte in Eiva, and overruled locally to (eg.1) for securing
backwards size compatibility when the char -future[16] has been replaced with something
else, (eg. char Bfuture[16];).
contain the names into the former char AddFuture[256] array, and this way implement user
names without changing the size and outlay of the NBSETUP7_2 structure, for maintaining
backwards comp ability. Therefore it has not been necessary to change the name of the
structure, while incorporating this latest change.
At the same time we have changed the Doppler log setup to include Doppler mounting offset
angles and position. These offset can only be hold in the setupfile, but will for now not be
used for any calculation and any view in NaviScan. Again we have reused half of the char
Bfuture[16] and the char DLfuture[16], for this, thereby maintained the same size and outlay
of the NBSETUP7_2 structure, with respect to backwards compatibility.
// --- Doppler Log ---
#pragma pack(push,1)
float DRollOffset;
float DPitchOffset;
#pragma pack(pop)
#pragma pack(pop)
of this type is stored in this record and in the sub packages to ensure backwards
compatibility.
4.5.1 Layout
typedef struct GyroLogPacket
{
short Seq; // Sequence number of sensor (1 - x)
float Gyro; // Interpreted value
float Corr; //speed or RTK corr without meridian corr
float MeridianCorr; //meridian corr
float Spare; //for future use
short Raw_length; // Length of raw package (Normally not used)
char pRaw[1]; // Pointer to raw package (Normally not used)
}GYRO_PACKET;
4.6.1 Layout
typedef struct MotionLogPacket
{
short Seq; // Sequence number of sensor (1 - x)
float Roll,
Pitch,
Heave; // Interpreted values
short Raw_length; // Length of raw package (Normally not used)
char pRaw[1]; // Pointer to raw package (Normally not used)
}MOTION_PACKET;
4.7.1 Layout
typedef struct BathyLogPacket
{
short Seq; // Sequence number of sensor (1 - x)
float bathy; // Interpreted depth (m)
float altitude; // Interpreted altitude
float presure; // Interpreted pressure (dBar)
short Raw_length; // Length of raw package (Normally not used)
char pRaw[1]; // Pointer to raw package (Normally not used)
}BATHY_PACKET;
4.8.1 Layout
typedef struct PositionLogPacket // Only used with packettype "P "
{
short Seq; // Sequence number of sensor (1 - x)
double dEasting; // Interpreted Easting pos
double dNorthing; // Interpreted Northing pos
short Raw_length; // Length of raw package
char pRaw[1]; // Pointer to raw position string
}POS_PACKET;
4.9.1 Layout
typedef struct RawdataLogPacket // Only used with packettype "R "
{
short Seq; // Sequence number of sensor (1 - x)
short Raw_length; // Length of raw package
char pRaw[1]; // Pointer to raw data string
}RAWDATA_PACKET;
4.10.1 Layout
typedef struct AuxiliaryLogpacket{
float Vals[8]; // interpreted custom data values, unused vals filled with FLT_MAX
short Seq; // Sequence number of sensor (1 - x)
short Raw_length; // Length of raw package (Normally not used)
char pRaw[1]; // Pointer to raw package (Normally not used)
} AUXILIARY_PACKET;
4.11.1 Layout
// Primary parameters
char sEllipsoidName[128];
double SemiMajorAxis; // [meters]
double InverseFlattening;
unsigned char ProjectionType;
double OrgScale; // Pointscale factor at the ellipsoid origin
double FirstParallel; // First parallel in Lamberts conical [degrees]
double SecondParallel; // Second parallel in Lamberts conical [degrees]
double OrgLambda; // Origin lambda (lon) on the reference ellipsoid [degrees]
double OrgPhi; // Origin phi (lat) on the projection ellipsoid [degrees]
double OrgEasting; // Origin easting on the projection plane [meters]
double OrgNorthing; // Origin northing on the projection plane [meters]
// Secondary parameters
unsigned char UTMzone; // Derived from "OrgLambda" [1..60]
// Raw string
short Raw_length; // Length of raw package
char pRaw[1]; // Pointer to raw string
}PROJELLIP_PACKET;
4.12.1 Layout
typedef struct DatumShiftLogPacket
{
float Tx; // Transformation parameter X - meters
Float Ty; // Transformation parameter Y - meters
float Tz; // Transformation parameter Z - meters
short method; // How to perform the shift
double Rx; // Rotation parameter X - [degrees]
double Ry; // Rotation parameter Y - [degrees]
double Rz; // Rotation parameter Z - [degrees]
double PPM; // scaling factor transformation - 1/1000000
// Raw string
short Raw_length; // Length of raw package (Normally not used)
char pRaw[1]; // Pointer to raw string
}DATUMSHIFT_PACKET;
4.13.1 Layout
}UTILITY_PACKET;
4.14.1 Layout
}LOGCONTROL_PACKET;
The raw data must be interpreted according to description from the echo sounder
manufacturer, and Eiva can provide a set of header files, describing how Eiva interprets the
raw data.
long nWidth;
long nHeight;
char strFilename[1];
} TARGET_LOGPACKET6_0;
Targets create during logging is placed in the file at the time they were created. Targets
created during playback are added at the end of the file. This means that if you want to know
about the targets while reading the file, you will need to parse the file for targets first.
Each incoming echosounder scan is logged to the raw data file as:
Each incoming Doppler packet is logged to the raw data file as: 1 HEAD_LOGPACKET, 1
SUBPACKET + the raw doppler string which occupies about 150 bytes. The EDO 3050 is
sending one packet a second.
Running a line for 1 hour; the raw data file will have the following size:
1: SeaBat 9001 with Doppler-log and pipetracker (9002 will be about twice as big)
5. Time stamping
The design of NaviScan has been performed with special consideration to time tagging, since
it is of highest importance that each scan is corrected with motion and heading values from
exactly the same time the scan was collected.
The most trust worthy result is achieved when values from different sensors are collected at the
same time. Since the single units supply data with different intervals this is not possible in
practice. Consequently, as a minimum the system must calculate an average value, at the
corresponding time of the controlling unit, e.g. SeaBat.
Data is time tagged relative to the internal pc clock with an accuracy of a few milliseconds.
Sub packets are produced with time interpolated value, and logged but also used for online
correction for the displayed scans.
Finding interpolated values:
Let echosounder supply data corresponding to the times T0 T1 T2 T3 etc. and the gyro
corresponding to the times t0 t1 t2 t3 etc. What gyro value must be used for SeaBat value
to the time Ti. If a j with Ti=tj exists, the gyro value corresponding to the time tj is used. If
this is not the case the system must find a k so that tk<Ti<t(k+1) and a gyro value is
calculated as follows:
Gyro(ti) = Gyro(tk) * (ti-tk+1)/(tk-tk+1) + Gyro(tk+1) * (ti-tk)/(tk+1-tk)
To make sure that the interpolated values are trustworthy it is required that all packages
from the various units are tagged on the PC immediately upon receipt of the 1st. byte.
DataProc Timetag on
arrival of last Correct time to:
Input Serial
character. Time for arrival of
(Ascii)
(timeGetTime first character.
format *)
Timetag on
arrival of data.
(timeGetTime
format *) timeGetTime format :
Time in milliseconds
since windows started.
Online
Save data :
(time = reference time - Input time)