The Ethernet Interface

The Tracker 650 has a tiny implementation of Internet Protocol. It can send and receive using User Datagram Protocol (UDP) which is used for commands and messages, and Transport Control Protocol (TCP) which is used only for mavlink2rest. In addition, it supports a subset of Address Resolution Protocol (ARP), a subset of Dynamic Host Configuration Protocol (DHCP) to obtain an IP address and supports a subset of the Ping protocol of Internet Control Message Protocol (ICMP). Additionally, the Tracker 650 supports an Ethernet Discovery protocol on port 30303, which is compatible with the Blue Robotics Ethernet discovery protocol.

When powered up, the Tracker 650 looks for a link status on the Ethernet physical layer. After a few seconds, if no link is present the DVL abandons the Ethernet interface and continues with only the serial link. The DVL does not circle back later to re-check link status. NOTE: link status is a physical layer property and is usually satisfied by connecting to a powered Ethernet switch or a powered Ethernet adapter. Even if the host on the other end of the Ethernet cable is still booting, the physical layer normally establishes the link by itself. Thus, if the electronics are connected and powered, the link usually establishes.

As shipped, the DVL wakes up and requests an address using DHCP protocol. If an address is not received within 60 seconds, the DVL will use a fallback IP address of 192.168.2.3, port 50000. You can set a different fallback address once in communication with the DVL or via the serial interface.

You can also set any valid static IP address for the DVL, and it will use the static address on startup and skip the DHCP request.

A common trouble situation has symptoms of (a) CeruleanTracker seems to be receiving some or all of the information from the DVL, and (b) it seems like you can’t send any commands to the DVL from CeruleanTracker. This is the result of having the DVL on a different IP subnet than the host PC that is running CeruleanTracker. Windows will helpfully (and silently) suppress outgoing traffic to networks it thinks are unreachable (such as addresses on a different subnet). Windows uses the IP subnets to figure out which networks are reachable via which physical interfaces. Here are a few ways this happens:

• Your firewall is blocking traffic to the DVL (this isn’t really a subnet problem, but the symptoms are often the same).

• The DHCP server might be unavailable, and the DVL uses the fallback address, which might be on a different subnet.

• You switch to using a USB Ethernet adapter instead of the Ethernet port on your laptop dock, and the USB Ethernet adapter is on a different subnet.

• You have set your DVL, ROV and computer up while on the office network, and then move the show out onto the water.

  o The DHCP server might be unavailable, and the DVL uses the fallback address, which might be on a different subnet.

  o You switch to using a USB Ethernet adapter instead of the Ethernet port on your dock, and the USB Ethernet adapter is on a different subnet.