DSV Turtle

Turtle (DSV-3) is a 16-ton, manned deep-ocean research submersible owned by the United States Navy. It is sister to Alvin (DSV-2), and also an Alvin class deep-submergence vehicle.

DSV Turtle hoisted from the deck of the support vessel MV Dolores Chouest

History

Turtle (DSV-3) was designed and built by the Electric Boat division of General Dynamics Corporation at Groton, Connecticut. Turtle and her sister Sea Cliff (DSV-4) were launched on December 11, 1968. Turtle was named after Turtle Town, a small community in Polk County, Tennessee. Her name also pays tribute to the American submarine Turtle which served in the American Revolution. Turtle was accepted by the US Navy on September 25, 1970 at Woods Hole, Massachusetts.

Turtle was designed to dive to 6000 feet. When DSV-2 Alvin installed a new titanium hull, the Alvin steel hull was installed in the Turtle. The Turtle depth rating was then increased to 10,000 feet. It has a hull 2 inches thick, and a hatch about 3-1/2 inches thick held in place by the pressure of the water above it (it is tapered, narrower inward). The Alvin-class DSV's were designed to replace older DSV, such as the less maneuverable Trieste-class bathyscaphes.

Turtle spent her career as a unit of the U.S. Navy's Submarine Development Group 1 in San Diego, California.

The Turtle was retired from active service on October 1, 1997. It was stricken from the US Navy Register on April 15, 1998 and is now is on display at the Mystic Aquarium in Mystic, Connecticut.

Awards

In fiction

In fiction, she was featured in the 1980 film Raise the Titanic; she was one of several submersibles in the salvage fleet, and one of two (along with the fictional NUMA submersible Deep Quest) that actually discovered the wreck.

Alvin class DSV
gollark: Tape Shuffler would be okay with it, Tape Jockey doesn't have the same old-format parsing fallbacks and its JSON handling likely won't like trailing nuls, no idea what tako's program thinks.
gollark: Although I think some parsers might *technically* be okay with you reserving 8190 bytes for metadata but then ending it with a null byte early, and handle the offsets accordingly, I would not rely on it.
gollark: Probably. The main issue I can see is that you would have to rewrite the entire metadata block on changes, because start/end in XTMF are offsets from the metadata region's end.
gollark: I thought about that, but:- strings in a binary format will be about the same length- integers will have some space saving, but I don't think it's very significant- it would, in a custom one, be harder to represent complex objects and stuff, which some extensions may be use- you could get some savings by removing strings like "title" which XTMF repeats a lot, but at the cost of it no longer being self-describing, making extensions harder and making debugging more annoying- I am not convinced that metadata size is a significant issue
gollark: I mean, "XTMF with CBOR/msgpack and compression" was being considered as a hypothetical "XTMF2", but I'd definitely want something, well, self-describing.

See also

References
    This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.