EdgeTech Sonar Simulator
The EdgeTech Sonar Simulator simulates receipt and processing of all commands that can be sent to the main sonar application.
The requirements for the simulator are:
•	Windows WinNT, Win2K, WinXP or Vista operating systems. 
•	Valid TCP/IP stack installed.
The following are included in the sonar simulator installed package:
•	Sonar executable and related files.
•	Documentation (eg this file).
•	C++ header files which can be used to interface to the sonar via TCP/IP sockets.
•	Example source code and visual studio project which shows how to connect and send messages.
•	Discover Topside Application
For files such as the C++ headers, go to the install directory (normally (Program Files / EdgeTech).
While the message format remains the same for all sonar configurations, some messages may not make sense for some configurations.  For a multiping-4200 type fish, a topside/controller will normally connect to the Discover application, and Discover connects to the sonar.  In this case the subset of messages supported is defined in the document LimitedControlInterface.doc.  This limitedcontrol interface is also supported in configurations (other than the 4200) – consult Edgetech if you are uncertain of which interface should be used for your application.
For other configurations, a topside/controller will connect to either sonar.exe, or Etsi.exe.  Etsi (EdgeTech sonar interface) is a multi controller application, and is useful when there are two distinct topsides (say a subbottom and sidescan) that both require data.  Etsi would then connect to the sonar.exe and concentrate the commands from both controllers.  Etsi is not included in the simulator package, so for testing and development purposes you should connect directly in the sonar in this case.
The sonar and discover applications need to be configured.  For sonar, the file sonar.ini is used to modify the settings.  When installed 3 shortcuts are provided for sonar, namely, for a subbottom only configuration, for a 4200 multiping configuration, and for a combined subbottom and dual frequency side scan configuration.
For discover, the systemtype.ncf file defines the topside configuration.  A single value at the start of the file is all that is needed to define the configuration type, and there are comments as to the supported types in the file.

TCP/IP Command and Data Interface
The sonar.exe requires to tcp/ip sockets, one for data output and a second for commands.  The data socket is by default 1701 and the command socket is 1700.  There are 2 commented out lines in sonar.ini that can be used to change the socket numbers if desired.  As a tcp/ip server, sonar accepts connections on these sockets, and a controller (or discover) must know the network address that the sonar.exe is running on to connect to it.  In Discover the “Configuration” / “Network “ menu item can be used to specify this value.  If both applications are running on the same machine, the special value 127.0.0.1 (for local host) can be used, and since it is assumed that the command and data sockets are adjacent numbers, only the command socket number needs to be specified.  If connecting to Discover the normal sockets are 1900 and 1901 respectively instead of 1700 and 1701.  When ETSI is used, the socket numbers are normally 1600 and 1601.
For sonar.exe, once the simulator is running, the current configuration can be examined by selecting the menu item File / Show Status. This will display a list box with parameters that can be modified and their current values.  Pressing the Update button will refresh the display. The default parameter set on startup or reset command is defined in the Sonar.ini and SonarSerial.ini (Serial Port Settings).  More details on this display are further down in this document.
You may wish to edit the Sonar.Ini file to change the master configuration type. See the comments in the file about the Config= keyword.
The sonar is controlled via a single TCP/IP socket (1700). The sonar delivers data via a second TCP/IP socket (1701). The sonar program acts as a server on both of its sockets. A topside connects to the sonar, and the sonar accepts connections from a topside. Only a single connection is supported on each socket, and when a second connection is detected the current socket is closed.
Every sonar command sent is preceded by a SonarMessageHeaderType structure. The header contains the number of bytes to follow, among other things. There are 3 types of messages, as indicated by the sonarCommand field. SONAR_COMMAND_SET sets properties of the sonar system. SONAR_COMMAND_GET will result in a reply with the requested parameter. All data coming from the sonar system to the topside is of type SONAR_COMMAND_REPLY. This includes any reply to a GET as well as data on the data socket. The sonar will return a SONAR_COMMAND_ERROR message if the command cannot be executed.
Data is returned in JSF format (see JSFDefs.h) on the data socket by default.  For backward compatibility with topsides that were developed with a previous version of Sonar, the default data format can be specified in the Sonar.ini file via the (TelemetryFormat keywords). Every data message is preceded by a SonarMessageHeaderType field, which indicates the number of bytes of segy header/data to follow.  For JSF data, the message type will be set to SONAR_MESSAGE_DATA.
All message information is expected in Intel format. So, for example, for a 32-bit word, the first byte represents the 8 LSBs. The Sonar system has currently been interfaced to both big-endian and little-endian computers, but on big-endian computers message data must be converted.
The file SonarMessages.h defines the primary messages that can be sent to the sonar. The file JSFDefs.h defines the format of  data returned from the sonar.  Here is example code to turn pinging on:
char *Message;
int Bytes;
SonarMessageHeaderType *Header;
SonarMessageLongtype *Data;
Bytes = sizeof(SonarMessageHeaderType) + sizeof(SonarMessageLongType);
Message = (char *)malloc( Bytes);
Header = (SonarMessageHeaderType *)Message;
Data = (SonarMessageLongType *)(Message + sizeof(SonarMessageHeaderType));
// Fill in the header
Header->startOfMessage = SONAR_MESSAGE_HEADER_START;
Header->version = SONAR_PROTOCOL_CURRENT_VERSION;
Header->sessionID = 0;
Header->subSystem = 0;
Header->channel = 0;
Header->sonarMessage = SONAR_MESSAGE_PING;
Header->sonarCommand = SONAR_COMMAND_SET;
Header->byteCount = sizeof(SonarMessageLongType);
// Fill in the data
Data->value = 1;
// Send the message
bytesWritten = send(socketID, (char *)Message, Bytes, 0);
free(Message);
Here is a recommended minimum set of sonar messages to send to initialize the system.  See SonarMessages.h for more details.
1) SONAR_MESSAGE_PING_LIST (SONAR_COMMAND_GET) : Get the list of all valid pulses.
2) SONAR_MESSAGE_PING_SELECT : Select a pulse from the list returned above.
3) SONAR_MESSAGE_PING_RATE : Set the ping rate for sonar data.
4) SONAR_MESSAGE_DATA_NETWORK_WINDOW : Set the region of interest for returned data.
5) SONAR_MESSAGE_PING : Turn pinging on.
*) SONAR_MESSAGE_ALIVE (SONAR_COMMAND_GET) : Periodically verify that the sonar system is still connected and running.  This message should be sent on the data socket as well if no data has been received recently.  If replys are not received to this message then the connection to the sonar has been lost and a new socket connect should be done.  Note that due to the nature of TCP/IP sockets, the sonar cannot tell when a link has been lost. Unplugging a network cable is a common way to loose a socket connection.
Sonar.exe Application Information
The sonar program has several displays to assist in developing a command interface, these include:

•	List of Messages Received and Sent
•	Current Configuration

To access these, use the menu item “File” / “Show Status”

Sonar Show Status / Configuration

Shown below is this status screen with the option “Configuration” selected for Sub0:

Parameters such as currently selected pulses and ping rates can be seen along with other configuration details.
The “Config Item” combo box is used to select which details to display.
Summary: Overall summary status.  Among that items that can be useful here are the overflow counters which when incrementing indicate that data is being dropped somewhere in the processing chain, and time synchronization statistics.
Serial: Displays statistics of each enabled serial port device.
NMEA: Displays parsing info on NMEA strings.  This data is used to fill in some of the sonar header fields (such as latitude and longitude).
Sub: Displays details on the parameters currently set for a subsystem (eg ping rate).
Net: Displays network connection details.
More details on some items is included below:
Summary / Status Section
This area displays the values that would be returned from a SONAR_MESSAGE_SYSTEM_STATUS message.
128Buffers: This value indicates the total number of 128 sample buffers of data that have been acquired from all sources to date. When pinging for any subsystem is enabled this number should be incrementing over time.
OF Count: This value indicates the total number of errors detected to date.
LastErrors: The error codes from the most recent 10 errors.
Summary / Main
This area summarizes some overall internal variables of the Sonar System.
Simulator: Indicates the behavior of the simulator data. A non-zero value indicates simulator mode. The option DspSimulator in the Sonar.Ini file sets this value.
NetCmd and NetData : Indicates whether these sockets are currently connected.
Summary / Overflow Counters
There is a processing pipeline which begins at a low level data acquisition card and completes with formatted data sent out the network.  At each stage there are performance counters that indicate if there are problems at that stage.  If data cannot be sent to the next stage because a queue is full, an overflow counter is incremented.  The FinalQ counter is the network output queue, and the most common one to have a problem.  When connecting to the sonar, is it important to set the TCP/IP buffers to large values (eg 100,000 bytes on the data socket) because the default sizes are much too small to sustain sonar data rates.  The queue depth values can be used to determine if the throughput is adequate and is an early indication of a throughput problem.  In addition to the network queue, a second queue for local storage of sonar data is also present.
Summary / Time Sync
Most systems have a dedicated processor for real time control of the sonar ping timing as well as a higher level computer.  Since sonar records are time stamped at the lowest level, a sonar application has two time bases.  Time sync between the higher and lower levels is automatic, but a feed back loop is required to keep these in sync.  The time of the higher level computer can be set via NMEA strings or messages on the command socket.  The time sync statistics indicated how well these two time bases are kept in sync.  Min, max, and most recent errors in time sources are displayed here.
Last Delta: Indicates the correction factor in 0.5 ms of the last time sync message from the topside (SONAR_MESSAGE_TIME_DELTA). The LSB of this value is a counter and toggles between 0 and 1 to indicate new message arrivals. Therefore, subsequent messages from the topside will cause this value to change between even and odd numbers.
SUB #N:
This area lists the internal variables of a subsystem. The first subsystem is always 0.
SonarOn: Indicates the current ping state of the subsystem, where 0 is off and 1 is on. SONAR_MESSAGE_PING messages from the topside change this value.
Trigger: Indicates the current trigger mode, where 0 is internal and 1 is external. SONAR_MESSAGE_PING_TRIGGER messages from the topside change this value.
Samp/Ping: Indicates the total ADC samples per ping for internal triggering. The actual ping interval will be this many samples at the current ADC sample rate as specified by IO channel 0. This value is effected by the pulse selected, the current data windows for all channels, and the requested ping rate.
Freq: Indicates the ping rate, as requested by the topside. The actual ping rate may be longer than the requested amount if the data window requested by the topside for any channel requires a longer data collection interval. SONAR_MESSAGE_PING_RATE messages change this value.
Pulse: Indicates the file name of the current pulse. SONAR_MESSAGE_PING_SELECT messages modify this value. Note that any pulse must pass validity checks before it is accepted. This value is the last known good pulse.
SubType: Internal value which indicates the type of hardware used to implement this subsystem.
SubNum: Logical subsystem number which must be present for every topside message which wishes to modify this subsystem.
SUB N IO M:
Configuration details for each IO channel are listed here. The first channel is always 0
NetCnt: Total number of data packets transmitted up to a topside, if connected for this channel. When this value is incremented, new data packs could have been or have been sent to the topside for this channel
DskCnt: Total number of data packets written to local internal disk for this channel.
ADCDecimate, DACRate, ADCRate, FTSize, IFSize, FTDec, SaveSize, DataType, FirstCoef, MinSave, Anhilate, PulseSize, PulseType, PulseOffset, DacGain0: Internal data acquisition and processing parameters which are affected by the current pulse selection.
AGC: When set to 0 the automatic gain control algorithm is disabled. When set to 1 the AGC is enabled. SONAR_MESSAGE_ADC_AGC messages modify this value.
ADCGain: Log2 of the current ADC gain. The minimum gain is 0. SONAR_MESSAGE_ADC_GAIN messages modify this value.
DACGain: Outgoing pulse attenuation factor. SONAR_MESSAGE_PING_GAIN messages modify this value..
CalConst: Calibration constant. This value scales all data sent to the topside. SONAR_MESSAGE_PROCESSING_CALCONST message modifies this value.
TVGDelay: Time variable spherical correction factor. A value of -1 will disable TVG. 0 applies the normal spherical correction factor to data. A positive value will initiate the spherical correction factor at that count. SONAR_MESSAGE_PROCESSING_PAKDELAY modify this value.
AGCDelay: Number of samples to ignore at the start of a pulse for the AGC algorithm. These samples represent the direct path. Modified by the SONAR_MESSAGE_PROCESSING_DIRECT_PATH message.
Disk On: When 1 data to be sent to the disk queue for internal hard disk storage.  Note that the disk recording must be turned on (separately) or this disk queue data will be discarded. When 0 data is not stored.
Disk Window: Current data window for disk storage. The values are the sample and ping decimation factors, first sample to save, total samples to save, and max packet size.
Net On: When 1 data is sent up the network to a topside. When 0 data is not sent to the topside.
Net Window: Current data window for network data. The values are the sample and ping decimation factors, first sample to save, total samples to save, and max packet size. Modified by the SONAR_MESSAGE_DATA_NETWORK_WINDOW message.
Actual(DAC ADC): Internal parameters for locating resources for pulse transmission and acquisition.
MinBlock MaxBlock: Internal parameters for region of interest for acquired data. This is effected by the current data windows and the ping rate.

Sonar Show Status / Messages

Shown below is the status screen with the option “Messages” selected.

All command messages received, and their replies is shown with the most recent at the top.