DVLLink

A minimal OMNeT++/INET simulation demonstrating that a DVL keeps the same static address in two operating modes:

• Direct: DVL connected directly to the onboard computer.
• Tethered: DVL and computer connected through the onboard switch, with a router and surface computer on the same LAN.

Motivation

On an autonomous underwater vehicle, the DVL is the sensor that keeps dead-reckoning honest. If the driver can't reach it, the vehicle loses its velocity reference within seconds. The failure mode that motivates this model is mundane and common: the sensor link works on the bench (tethered, with a router and DHCP present) and then breaks in the water, where the tether is gone and no DHCP server exists, or the reverse, where a poolside laptop is handed the sensor's address by the router. Discovery protocols make this worse, not better: they behave differently in the two topologies and fail silently in exactly the situations where nobody can plug in a monitor.

The claim this simulation pins down is that the boring answer is the correct one: give both sensor endpoints static addresses on one subnet, keep those addresses out of any DHCP pool, and rely on zero discovery. The two configs demonstrate that the addressing is identical with and without network infrastructure present, so the configuration validated on the bench is, byte for byte, the configuration that runs untethered.

Address plan

One flat subnet in both modes; the sensor endpoints never renumber:

Device	Address
DVL	192.168.8.148/24 (static)
Onboard computer	192.168.8.170/24 (static)
Router (tethered only)	192.168.8.1/24
Surface computer (tethered only)	192.168.8.100/24

The direct mode has no DHCP server at all, which is exactly why both sensor endpoints must be static. In tethered mode the router's DHCP pool must exclude (or reserve) the two static sensor addresses.

The DVL sends a 230-byte velocity report to the computer every 100 ms (10 Hz). The endpoints are always 192.168.8.148 → 192.168.8.170, regardless of tether state.

Protocol simplification: the real device (Water Linked A50) serves TCP on port 16171: the client connects and the sensor streams JSON reports over the session. This model pushes UDP datagrams at the same rate and size, because only addressing and topology are under test; the port number mirrors the real service port.

Requirements

• OMNeT++ 6.x
• INET 4.6.x

Import and run

1. Install/import INET in the OMNeT++ IDE.
2. Import this directory as an OMNeT++ project.
3. Open Project Properties → Project References and enable the INET project.
4. Ensure the project's NED source folder contains the project root.
5. Open omnetpp.ini.
6. Run either:
   • Direct
   • Tethered

From a terminal configured for OMNeT++ and INET, an equivalent command is:

opp_run -u Qtenv \
  -n .:/path/to/inet/src \
  -l /path/to/inet/src/INET \
  omnetpp.ini -c Direct

Change Direct to Tethered for the switched/tethered topology.

One-command verification (headless)

With OMNeT++ tools on PATH:

INET_ROOT=/path/to/inet ./verify.sh

Runs both configs under Cmdenv and asserts the computer received the full DVL stream (≥289 packets) in each. PASS means the addressing claim holds in both topologies; logs and result files land in results/.

Expected behavior

In both configurations:

• The DVL address displayed by the visualizer is 192.168.8.148.
• The computer's address is 192.168.8.170.
• About 290 DVL packets are received during a 30-second run (transmission begins at one second).
• Adding the router and surface computer in the tethered configuration does not renumber either sensor endpoint, and the surface health traffic reaches the computer over the same LAN.

What this proves and what it does not

This model proves the addressing concept: statically addressed sensor endpoints on one subnet work identically with and without network infrastructure present, with zero discovery.

It does not yet emulate:

• the real TCP session semantics (client-initiated connect to :16171, reconnect behavior, the sensor's concurrent-client limit),
• a second host interface on the same subnet (e.g. WiFi) and the host-route/metric configuration that pins sensor traffic to the wire,
• cable unplugging during a single simulation run,
• DHCP address-conflict scenarios (a pool handing out a static address),
• packet corruption,
• OS network-manager behavior on the actual computer,
• ROS 2/DDS.

Those can be added as the next experiment after this baseline runs. Concrete starting points: INET's ScenarioManager for mid-run cable disconnects, and a second static host deliberately configured with the DVL's address to demonstrate the DHCP-conflict failure mode.

Troubleshooting

• Error: no such NED type: DatarateChannel: the INET project isn't referenced or the -n path doesn't include INET's src/.
• Cannot load library .../INET: INET isn't built, or was built with a different OMNeT++ version; rebuild INET with the same toolchain.
• Icons show as generic boxes: cosmetic only; icon names vary between OMNeT++ versions.
• Zero packets received in Tethered: check that all four hosts got addresses from the configurator (Qtenv: enable the interface-table visualizer, already on in this config); an interface without an address means the XML hosts= pattern didn't match a module name.