Impact Subsea’s seaView 3.2 release is the minimum software version required to detect and configure the company’s new Unity Topside Control System and seaMux subsea multiplexer, turning the Windows application into the control point for a more integrated ROV and survey-sensor stack. The update also adds communications monitoring, alarm functions for altimeter and depth applications, new ISP360 profiler outputs, and claimed closer-range ISS360 imaging-sonar operation. Ocean News reported the release on August 3, describing seaView 3.2 as a download that adds support for the two new products. Impact Subsea’s own current Unity and seaMux setup material independently confirms the critical version requirement: operators need seaView 3.2 or newer for the software to detect those devices.
For Windows users operating survey stations, ROV topside systems, or integration benches, the consequential change is not a cosmetic sensor-app update. SeaView 3.2 is now the software boundary between a conventional directly connected sensor installation and a managed subsea-to-surface communications system with powered ports, serial-device bridging, Ethernet devices, and inspection of raw traffic.

ROV control room monitors subsea operations, with an offshore platform and underwater vehicle visible outside.Unity and seaMux bring port management into seaView​

The seaMux is a titanium-housed subsea multiplexer with four communications ports, rated to 6,000 meters, that can carry Ethernet, RS232, or RS485 connections. It can aggregate Impact Subsea instruments as well as third-party serial or Ethernet equipment, with data sent to the surface over Ethernet or VDSL. Unity is the companion topside control system, providing the surface-side connection, power control, logging, and integration point for external survey systems.
Impact Subsea’s current product documentation states that each seaMux port can support Ethernet, RS232, or RS485, while Unity and seaMux can bridge data from a subsea port to a physical Unity port or to a Serial over LAN connection. That means a sensor may remain a non-Impact device and still use the hardware path, rather than requiring its data to be translated into an Impact Subsea-specific format before reaching a survey workstation.
SeaView 3.2 exposes that equipment as distinct communications areas for Unity, seaMux, system ports, Serial over LAN, networks, and monitoring. The vendor’s setup walkthrough shows automatic discovery for the two new devices and connected sensors, as well as per-port configuration and power switching. A Unity-and-seaMux installation is therefore meant to reduce the number of independent USB adapters, serial converters, and point-to-point connections on a topside workstation.
The practical limitation is important: the bridging function shown by Impact Subsea depends on using both seaMux and Unity. A standalone seaMux connected to a PC does not receive the same seaMux-to-Unity port-bridging option. Operators planning to use third-party serial instruments through a subsea multiplexer should not assume that purchasing the subsea unit alone provides the complete routing design described in the launch material.

The Communications Monitor addresses a familiar integration failure​

The new Communications Monitor is arguably the most useful operational addition in the release. Ocean News describes it as a terminal-style feature that lets users view data entering or leaving a port. Impact Subsea’s own Unity and seaMux walkthrough confirms that the monitor can inspect raw receive and transmit data on seaMux ports, Unity ports, and Serial over LAN connections.
That gives technicians a direct way to establish whether a fault lies at the sensor, the subsea multiplexer, the VDSL or Ethernet link, Unity, or the receiving survey system. In an ROV deployment, a serial device can be transmitting valid ASCII data at the vehicle while the topside application sees nothing because of an incorrect bridge, protocol, port mapping, or cable path. Being able to see receive traffic at seaMux and transmit traffic at Unity makes the break visible without adding a separate serial sniffer or inserting another converter into the system.
Impact Subsea demonstrates the feature with an ISA500 altimeter: traffic arrives at seaMux Port 4, is bridged to Unity Port 1, and is visible as received data at the first endpoint and transmitted data at the second. This is a modest feature on paper, but it has a real workflow consequence. It moves first-line connectivity troubleshooting into the same Windows interface used to configure the instruments, instead of requiring a separate terminal package and a working understanding of which physical interface maps to which virtual COM port.
There is still a boundary to what the monitor proves. It can show that bytes are arriving and leaving a given port; it does not by itself certify that a third-party navigation, acquisition, or visualization package is parsing the content correctly. For survey crews, that makes the Monitor a transport-layer diagnostic rather than an end-to-end data-validation tool.

Alarms add immediate operator feedback for depth and altitude​

SeaView 3.2 also adds visual and audible alarms to the altimeter and depth-sensor applications. The release notes cited by Ocean News say users can set an altitude or depth threshold, allowing an ROV operator to be alerted when the vehicle runs too close to the seabed or exceeds an allowed operating depth.
The safety and operational value depends on how the threshold is used. An altitude warning is useful for protecting payloads and maintaining standoff during inspection, while a depth alarm can flag a vehicle approaching a mission or equipment limit. But an application-level alarm is not a substitute for a vehicle’s independent safety controls, depth ratings, pilot procedures, or hardwired interlocks. It is an additional topside cue, and its reliability is necessarily tied to the PC, SeaView session, sensor communications, and the operator being able to hear or see it.
SeaView has long functioned as a common interface for viewing, logging, calibrating, and configuring Impact Subsea equipment. The vendor says it can display and record multiple connected sensors at once, with data saved to CSV and optionally georeferenced through GPS input. Adding alarms makes that multi-sensor screen more active during a live operation, rather than merely a logging and configuration surface.

ISP360 output changes target established survey software​

The release adds output strings for the ISP360 profiling sonar intended for direct connection to EIVA Naviscan and Visualsoft VisualData Logger, according to Ocean News. This is a potentially meaningful interoperability update because the ISP360’s native imaging and profiler data no longer has to be handled only inside SeaView before entering a broader survey workflow.
Impact Subsea’s January 2026 ISP360 manual confirms that the profiler is already operated through seaView and can communicate over RS232, RS485, or Ethernet. It also confirms that seaView automatically scans available communications ports to find the sonar. The update therefore appears to build on an existing sensor-control path rather than replace it: SeaView remains the configuration and operations application, while the new outputs seek to make the profiler’s data easier to consume elsewhere.
Neither Impact Subsea’s public seaView download page nor the ISP360 manual currently documents the precise layout, framing, update rates, coordinate conventions, licensing conditions, or configuration steps for the claimed Naviscan and VisualData Logger strings. That omission matters to survey integrators. “Direct connection” can mean a ready-made driver profile, a selectable sentence format, or simply a serial/Ethernet output that still requires field mapping in the receiving application. Teams should obtain the exact SeaView 3.2 output documentation and test it against the version of their survey package before putting the path into production.
The report also says SeaView 3.2 permits ISS360 imaging down to 10 cm from the sonar. Impact Subsea’s public ISS360 technical introduction confirms the sonar’s SeaView V3 support, but its accessible material does not independently specify the new 10 cm operating claim or identify whether it applies to every ISS360 variant and configuration. Until the vendor publishes a corresponding manual revision or release note, operators should treat 10 cm as the reported capability of the new software release, not a blanket performance specification for every installed ISS360.

Windows requirements are less clear than the new version requirement​

There is a documentation mismatch that Windows administrators should resolve before scheduling an upgrade. Impact Subsea’s general seaView page still says the software requires Windows 7 or later, with a possible .NET Framework 4.5.2 update for Windows 7. But the company’s January 2026 ISP360 manual specifies seaView use on a 64-bit Windows 10 or Windows 11 PC.
Those statements are not necessarily irreconcilable. The broader page may describe the long-running SeaView family and older sensor combinations, while the ISP360 manual describes the supported platform for that newer sonar workflow. However, the public download page does not clearly state the exact operating-system support matrix for seaView 3.2, Unity, seaMux, the new communications stack, or each sensor application.
That is the missing operational detail in an otherwise substantial update. Impact Subsea has established that version 3.2 is necessary to discover Unity and seaMux, but it has not publicly set out a version-specific installer changelog, release date, file hash, rollback path, firmware dependency matrix, or full Windows support statement. The company’s existing SeaView page also groups V3 software by sensor firmware generation, which means a field upgrade should not be treated as a simple application refresh without checking the firmware installed across the vehicle.
For operators, the immediate action is straightforward: validate seaView 3.2 on a Windows 10 or Windows 11 64-bit bench system with the intended Unity, seaMux, and sensor firmware before changing a live ROV or survey workstation. The payoff is cleaner port management and much better visibility into the route data takes from the vehicle to the survey application; the risk is discovering an undocumented compatibility dependency when the vehicle is already on deck.

References​

  1. Primary source: Ocean News & Technology
    Published: 2026-08-03T14:29:05+00:00
  2. Related coverage: impactsubsea.co.uk
  3. Related coverage: impactsubsea.co.uk
  4. Related coverage: oceannews.com