My Issues

Fledermaus Download

Fledermaus 7.8.1 Release

Highlights on this page

Thanks for your feedback


13 March 2018, We're pleased to present Fledermaus 7.8.1


  • This release includes support for Softlock Server licensing. 


Apply Backscatter Corrections

One of the backscatter processing adjustment options from the original Geocoder code was not correctly re-implemented during the rebuild of FMGeocoder into FMGT. The Do TX/RX Power Gain Correction option was not enabled at all in the processing logic, resulting in it having no effect whatsoever on processing. The default configuration internal to the processing logic was to always do these corrections, which is what most users would want to do. This explains why the problem has remained so long without being detected.

We have re-enabled this option correctly now. For clarity, we have also renamed the option. It was previously named Do TX/RX Power Gain Correction and it has been since relabeled to Apply Backscatter Corrections.

Being able to disable the backscatter corrections is particularly helpful when troubleshooting problematic data. You can disable this option to see if any problems that you notice in your mosaics are embedded in the data itself, or if they are being introduced by the backscatter processing that is done in FMGT. That being said, our recommendation is to leave the backscatter corrections application enabled as per the default.

If users decide to disable this option, FMGT will not perform any of the usual backscatter corrections at all. This will give the ability to create mosaics of raw sensor imagery. Note that the raw sensor imagery will be influenced by all of the changes in sensor configuration during acquisition and the data range may deviate significantly from the expected range for backscatter. For non-Kongsberg users, you will also need to adjust the Backscatter Range options to be Uncalibrated and also adjust the signal range to match the raw sensor imagery. For Reson, R2Sonic and Norbit users, this raw range would typically be 0 to 90. For Kongsberg systems, the output range is already in the typical range for acoustic backscatter and no adjustment of the Backscatter Range should be necessary if you decide to try this option for troubleshooting. Disabling this option for Kongsberg systems will give mosaics that will be more consistent with what users observe in real-time sidescan displays during acquisition.

Improvement for Kongsberg ensonified area correction

At the 2015 FEMME conference in Singapore, Kongsberg informed the community that their real-time ensonified area calculations was incorrectly using the reported pulse width in their real-time calculations instead of the effective pulse width. The effective pulse width is 37.5% of the nominal value reported in the datagram packets, this affects only EM2040 systems.  FMGT has been updated to remove the incorrect real-time ensonified area calculation done by Kongsberg and to then compute an improved area correction using the effective pulse width. Users switching to this version will see an increase of about 3 dB as a result and it is not advised to do this with a project that you are mid-way through processing.

Pairing of dual-head .ALL with HDCS

Previously, only single-head pairing was possible with .ALL and HDCS data. Now dual head is supported as well.

Technical Notes

  • FMGT will now check for both LogFile.xml and Process.log for settings when pairing HDCS files.
  • FMGT: Added crash prevention for the case of ARA files being missing or inaccessible.
  • Fledermaus: Contours exported to DXF will now have appropriate elevations for each line.
  • FMMidwater: Norbit watercolumn will now be displayed at the correct depth.
  • Updated drivers for HASP keys were included in the last installer but were found to cause some installation problems, they have been removed for now.

The licensing for Fledermaus 7.8.1 is not backwards compatible with earlier versions of the software. Once you switch to the new licensing (either HASP or Softlock), you will not be able to run earlier versions of Fledermaus.

If you download and install Fledermaus 7.8.1 without having a new dongle or activation code, you will find yourself in a position where you can longer run the software. In this case, you can always uninstall Fledermaus 7.8.1 and then download and re-install version Fledermaus 7.7.9. The Fledermaus 7.8.1 installer will, by default, overwrite your earlier version. Note that during the installation of version Fledermaus 7.8.1, you can choose to install it in a separate location from your previous installation to avoid the scenario that was just described.

Changes to License Contents

The old FlexLM based licensing system was based on individual features stored in the .LIC file. The new licensing system (for both HASP Dongles and Sofltocks) instead uses direct Products and Add-ons. This structure provides a clearer picture of what products and addons are part of your lciense. To help with the transition, the table below describes what Products and Add-ons come from each FM7 bundle. 

FlexLM Licensing

New Licensing
(7.8 and newer)

Product 1Product 2Add-on 1Add-on 2Add-on 3Add-on 4



FledermausQimera CleanFM7Hydro*

FledermausQimera CleanFM7Hydro*OffshoreBackscatterGIS

*FM7Hydro is a legacy add-on that enables the PFM, Area Based Editing, Crosscheck and 3DEditor capability in Fledermaus 7.8.x 

Discontinuation of Support for Third Party plug-in development

FMMidwater and FMGT hosts a number of internally generated plugins that manifest in a variety of locations within the GUI. A plugin is basically a DLL that is dynamically loaded at runtime to extend the capabilities of the baseline application. We use the plugins internally to allow us to create small and simple tools that we can ship to clients as a prototype that does not interfere with the standard installation.  This allows us to be responsive to the need for quick and custom developments independent of our product release cycle.

For a number of years, we have provided a software development kit (SDK) to allow 3rd parties to write their own custom tools that could then be deployed in some of our software. We can no longer support this for a number of reasons, the principle one being that we cannot currently find a mechanism to allow for 3rd party developers to develop plugins within a debug environment that can be tested by launching within our applications. This is due to changes in the core technology that we are using to build plugins with and is out of our control.

We are investigating a new plugin architecture that will be improved based upon the lessons we've learned with the current system. This is not on our immediate roadmap for 2018, and we will look to this for 2019.

Existing custom plugins generated by 3rd parties will continue to run and there is no plan to change the interface between our applications and plugins in the immediate future. If you have further questions about how this might impact your workflows, please contact our support team at