Faster. Ever faster.

There are around 180 devices on the submarine that the Opto hardware needed to communicate with.

Since every signal could not have its own physical wire, all the devices used a serial protocol. Each device had an address and a set of registers that could take commands or report their status back to the control program.

The interior of the pilot sphere remained at atmospheric pressure (around 14 psi), so there was no decompression requirement for the pilot. The outside of the sphere however took the full brunt of the mass of all the water above it. At the Mariana Trench, that was around 16,000 psi.

Serial data, power, and video camera feeds went in and out of the sub via very (very) special connectors called penetrator ports, electrical and fiber optic cables that had been cast in glass.

Since pretty much every system was built for redundancy, each part of the sub was split into roughly 5 parts.

Port (left), starboard (right), top, middle, and bottom. This way, if any one system failed, it did not take the whole system it was connected to with it. This meant we had many serial ports, 12 physical and 2 or 3 UDP/TCP network ones from memory.

The system needed to be tuned to take any command, be it one from the pilot's touch screen or one from any of the pilot controls, and convert it to the appropriate device's serial address and command register.

On top of that, the software had to take into account any device failures.... For example, here is one of the power switching boxes after a deep dive and some water ingress.

Here are 3 vertical and three horizontal thrusters. (Only two of the verticals are visible in this shot).

Like every other device, the thrusters were on more than one serial bus. Each thruster could be commanded for a given RPM (thrust) and data on its status could be requested - things like what it thought its current RPM was, its DC current draw, water ingress sensor status, temperature, and so on.

At first the thruster response was rather laggy. Like most throughput issues, there is often no one ("magic") fix; it's a combination of things.

First up, the joysticks were connected to an analog input module. They started out using the 8 input module, which has a data freshness of 280 ms. We swapped it for the 4 input module as it has a data freshness of only 20 ms.

By turning off the control engine in the PAC-R controller and using it as a high-speed I/O rack from the main PAC-S2 controller, we picked up some more speed.

Putting the PAC-R and the S2 on their own network rather than the sub's Ethernet network picked up some more. (This is just one of the many cool things you can do with Opto 22 controllers, since each has two separate Ethernet ports).

Ensuring the software never waited longer than the usual healthy time for a response helped as well.

Bit by bit, we got the speed of the system to the point where the pilots were very happy with the response time. The changes we made ensured that it stayed consistent throughout the whole dive program.

The need for speed

Not every system needs to run "fast." Air-conditioning in an event hall simply does not need millisecond response times. Neither did Deepsea Challenger for that matter. Sure, it needed better than the ~800 ms we started with, but there was no need to get it much below 100 ms.

As tempting as it is to always run everything flat out, it's worth stepping back now and then and asking "Just how fast does this really need to be?"

In Part 3 we will take a look at the graphic interface the pilots used via a touch screen to control a lot of the functions of the submarine.

Till then, cheers Mate.