STFishFinder API  API version 0.0.0, Documentation version 3 -PRELIMINARY-
Porting the STFishFinder API to a New Platform
System requirements
The STFishFinder API may be ported to virtually any hardware platform and operating system that meets the following requirements.
The platform must be able to:
  • build the STFishFinder API as a library using C++11-compliant build tools, and link that library to the application program and/or to a wrapper layer written in the predominant programming language for the platform.
  • provide hardware drivers for the communication link to the black box fish finder. For example, the FE2 fish finder uses TCP/IP over an 802.11b/g (Wi-Fi) wireless link. The hardware drivers should be able to turn the Wi-Fi radio on, and open a TCP socket and a UDP socket to the FE2. Platform support for Zeroconf (Bonjour) will allow for easy connection and configuration of an FE2 black box with the application program.
  • provide a system timer that can call an API function at an approximately 10 Hz rate
  • (recommended) provide support for multi-threading, to allow API operations to proceed unimpeded by other processes in the system (such as a graphical user interface (GUI)).

Wrapper functions
It is planned for the STFishFinder API to be provided with wrappers for iOS, Android, CLI (Windows), and Linux. The API may be ported to other environments by using the following guidelines.
The following functions need to be written in order to interface the STFishFinder API to the hardware and the application program. Descriptions of the functions follow.

OpenSession()
Wrapper function OpenSession() must be written to perform the following operations specific to the platform:
  • Establish a connection to the black box hardware using the facilities afforded by the platform.
  • Create and initialize a STFF::STFishFinder class object.
  • Initiate communication with the black box.
Further details of the operations that must be performed by OpenSession() are provided in the section How To Connect to a Black Box Fish Finder.

CloseSession()
Wrapper function CloseSession() should be written to provide an orderly takedown of the session established with function OpenSession(). In short:

Event Handler for Received Data
An event handler must be written that is called by the system when a packet of data has been received over the open connection from the black box. This handler function must pass that data to API function STFF::STFishFinder::ParseFFInputStream().

Callback StreamDataToFF()
This callback is called when the API needs to send a buffer of data to the black box fish finder. Arguments containing a pointer to the data and the number of characters in the buffer are provided in the call to the callback. The callback function should pass the data to the appropriate system driver or handler that sends data over the open connection to the black box.
See: STFF::Callback_StreamDataToFF_t.

Callback OnDataItemReceived()
This callback is called by the API when a data message has been received from the black box. Data messages can include Depth, Speed, Temperature, Battery Voltage, Image data, and detected Fish targets.
This callback can be used by the application to trigger a redraw of visual indicators that display the corresponding data items.
In general, this callback should check the value of the FF_DataType_t argument to determine what kind of data has been received, and then call the getter function corresponding to that data item to retrieve the new data value.
See: STFF::Callback_DataItemReceived_t.

Callback OnSettingChanged()
This callback is called by the API in two situations:
  1. An API setter function has been called by the app in order to initiate a setting change. In most cases, this results in a message being sent to the black box to request the setting change. This callback is then called by the setter function.
  2. The black box announces that a setting has changed. This might be as a response to a previous request from the API (as described in case 1), or it might be as a result of another display device requesting a master setting change, or it might be as a result of the black box automatically initiating a setting change (e.g. a range change because Auto Range is enabled).
The purpose of this callback is to inform the application when a setting has changed. The action(s) taken by the callback will depend on the needs of the application, and the overall design of the application. In typical fish finder applications, certain settings are often prominently displayed onscreen, such as the range limits, indicators for Auto Range and Auto Gain, and depth alarm settings. This callback can be used to trigger the update of graphical elements that depend on such settings.
As described in the section Setters, this callback is usually called twice with each user-initiated setting change: the first time when a "change setting" message is sent to the black box, and the second time when a response is received from the black box. This behavior can be used to provide visual feedback that a setting change initiated by the user within a dialog has been accepted by the black box. On the first call to the callback, the graphic indicator representing the setting within the dialog can be drawn as dimmed or highlighted, indicating that the change is pending. On the second call to the callback, which occurs as a result of receiving a response from the black box, the graphic indicator can be redrawn in its normal state, using the validated setting value provided by the black box, which would confirm to the user that the setting change was accepted.
In general, this callback should check the value of the FF_SettingType_t and FF_Frequency_t arguments to determine which setting is being changed, and then call the getter function corresponding to that setting to retrieve the new setting value.
See: STFF::Callback_SettingChanged_t.

Callback OnDepthAlarmStateChange()
This callback is called by the API when either the shallow depth alarm or the deep depth alarm changes state. There are four possible states for each alarm:
When this callback is called, it should call STFF::STFishFinder::GetDepthAlarmState() to determine the current state of the depth alarms. Based on the information provided by that function, the callback should then either trigger the appropriate audible alert and/or visual indicator to notify the user of the alarm condition, or silence the alarm, as appropriate.
See: STFF::Callback_DepthAlarmStateChange_t.

Callback OnFishAlarmTrigger()
This callback is called if the Fish Alarm is enabled and a fish is detected. The callback should trigger the generation of a brief "fish detected" audible alarm.
See: STFF::Callback_FishAlarmTrigger_t.

Adapter Functions
If the programming language used to develop the application program is unable to easily and directly call the C++ setter and getter functions of the STFishFinder class, then adapter functions (known as a "thin wrapper layer") may need to be written for each API function so as to present an interface that is compatible with the application program.

Timer
A background task should be coded to establish a system timer event that calls the API function STFF::STFishFinder::TimerTick() approximately every 100 milliseconds.

Remarks
C++ features employed within the internal code of the STFishFinder API that are specific to the 2011 revision of the C++ standard (C++11) include:
  • std::function
  • std::unordered_map
  • std::shared_ptr
  • std::mutex
  • std::lock_guard