Ship-Shore Email at the University of Hawaii
by Steve Poulos
Currently the ship's computer autodials a US Robotics Courier modem connected through INMARSAT and long distance lines from California to HNL to a US Robotics Courier modem (matching type) attached to a computer maintained by our group at the University of Hawaii (UH). The ship's computer automatically initiates the call at a time we have put into its crontab.
Mailer Vehicle: Taylor Uucp transfer - freely available on the Internet.
Computers: Currently, the ship is using our Sparc 20/60 but have for quite awhile used a Sparc II or Sparc 4/380. Ashore at UH the computer is still a Sparc II.
Strategy: Basically ashore or aboard, the user composes email just as they would anywhere in the U.S. using mail tools or software like Eudora, etc. and sends it like they normally would. The only difference is that when composed aboard ship it goes into a directory or queue and sits there until there is a connection made with the UH computer. The shipboard Sparc, assigned to email, knows to queue the message up if it doesn't belong to any of the computers aboard. When a connection is established between ship and shore, the two computers both begin transmitting - connection is bi-directional (an improvement over earlier the Taylor Uucp version). The UH Sparc sits on the net and sends incoming email from the ship on its way, just as it does when one composes email on it. Email to the ship gets queued up in a directory on the UH computer until the connection is made and then it too transmits what is in its queue. Each email message is handled separately so if the connection is dropped after say five successful message transfers and there are two more to go, only the last two stay in the queue until the next connection. The five successful transfers get sent their respective ways. Connections can be made (potentially) as often as one wants or can be made manually if email needs to go right away. Statistics are run daily on traffic to alert the system administrator about bounced email problems or long messages that go over a time limit.
Obviously, all of us have honed our systems to minimize the problems, but one problem we have not been able to get around is the long distance line connection between the mainland and UH. Sometimes the connection is great, other times the connection is so noisy the two modems can't talk to each other and the connection times out.
It would be great to be able to have a satellite system like INMARSAT that would know enough to dump HNL traffic directly to a land station here, thereby avoiding the variability in quality of the connection seen in mainland to Hawaii telephone lines. By the way, our email transfer is taking place on our main data logger - the Sparc 20/60 on the ship. Some might suggest that it could be a hazard to data collection if email hangs - but since 1986 we have never lost data due to email problems that I can think of even with a variety of strategies in place. We are very pleased with this setup except like everyone else it would be great if one could afford full time connection.
Questions can be addressed to Steve at:
poulos@poha.soest.hawaii.edu
Ship-Shore Email at the University of Alaska
by Steven Hartz
The HELIX uses INMARSAT A. I would like to upgrade to the B but, that is not in the cards yet. We use a Zxyel modem and use Eudora mail via a PPP connection to a UNIX server in Fairbanks. It's not the fastest way to go but we are PC based on the Helix. One mail box on the server is checked twice a week.
Eudora takes care of breaking up the outbound mail and I deliver the incoming mail. We also use the NODDS weather system via INMARSAT A. Other than being a DOS based program (which works fine with Win95 and not so good with Win3.11) this has been a great means to receive weather information. The HELIX operates in the 'black hole' of SSB communications so weather fax, Marine weather, etc. are often not available.
The bridge uses INMARSAT C. A 300 baud telex that has a gateway server for email. This is a Trimble system and uses Galaxy software. Galaxy software is DOS based. It works well to send those top secret messages that only the captain should see such as when someone's mother has died or the marine technician has been fired.
Questions can be addressed to Steven at: fnsjh@aurora.alaska.edu
Ship-Shore Email at Oregon State University
by Marc Willis
OSU uses a straight dial-up for email, no SLIP/PPP/etc. Telebit modems have their own internal compression protocol which makes the messages go pretty fast, but the overhead on the initial connection can be pretty high (up to 3 minutes to get connected to the right server). The Eudora software package takes care of most of the pain and suffering associated with getting connected. Email is usually transacted twice a day, when the atmospherics are right. Messages from the ship are sent directly to the recipient. Messages to the ship are sent to one of three mail aliases (scientist@, crew@ and technicians@). Eudora takes care of filtering messages incoming to the ship. We have also successfully sent and received messages with various binary attachments, with Eudora doing the decoding offline. This has been a very efficient way to transmit binary and data files (particularly images). Much of the 'top secret' business, and routine ship's business with Ship Operations is done over Inmarsat-C (Trimble Galaxy).
Questions can be addressed to Marc at: willis@oce.orst.edu
Ship-Shore Email at University of Miami
by Chip Maxwell
Email aboard ship has in the past has been handled by issuing the scientists an email address that is an account on a VAX computer in the lab (ashore). Any traffic going to the ship is addressed with the intended recipient's name in the subject field. Once a day we logon from the ship through INMARSAT A and either a Trailblazer T2500 modem or a Hayes Optima 288 V.34 + FAX modem. Using the BLAST protocol we log on to the VAX at the lab, extract the mail into one text file, and transmit that it to the computers on the ship. At the same time we have a program that transfers any mail coming from the ship to an account here in the lab where it is distributed (via batch procedure) to the Internet addresses of the intended recipients.
The only problems with this setup is that you have to manually start the process and someone has to pay for the airtime (usually the Chief Scientist, since it is she who usually requests the information or images). Additionally, accounting information for billing purposes is almost nonexistent.
The nice thing about BLAST is that if you lose the connection, when you reconnect, it remembers where you were and you do not have to resend any files that have already been sent. This protocol works for VMS, Windows/Dos, UNIX and most other operating systems and computers. We do not feature this on every cruise as we have no way of accounting for individual's INMARSAT time. If we had the time to do this and could get people to sign their names to be responsible for any bills incurred, it would be good to have every cruise.
I would really like to get the INMARSAT-B system mentioned at the last RVTEC meeting, like they have on the KNORR.
There are a couple of other ways to e-mail the ship. The easiest is to use the INMARSAT Standard-C terminal to either send or receive messages. The only problem with this is it is not very private and there is a problem sending over 2Kb of information from the ship. We can receive any amount but the transmission is limited to 2KB.
To use this method all that is required to contact someone on the ship (from ashore) is to send an email message to the ship's address. The Captain or Second Mate will distribute the mail as necessary. Composing and sending messages is similar to what everyone does normally for email.
The only other method is through the M-SAT. This is a new system and has not been tested for this configuration, but should be very similar to the INMARSAT-A system described above. The only difference is that the M-SAT is limited to 2400 baud so things take longer but are cheaper by the minute, so the cost should be similar.
Email could also be transacted over a cellular phone line as long as the ship was within range.
Questions can be addressed to Chip at:
wmaxwell@rsmas.miami.edu
New Satellite Communication Systems on the Horizon
[Ed. Note: The following exchange recently came across on the Ocean Tech mailing list. Some or all of RVTEC has probably seen it, but I think it is informative enough to repeat here. Rex spoke with RVTEC at the Monterey meeting last year. Rex Buggenberg is currently working with Andy Maffei and Dale Chayes on the SeaNet project, and is probably the best source of information on satellite communications and ship-shore networking.]
[Original Posting]
Torrey Science (619/552-1052) is a point of contact located here in San Diego.
- - - - SNIP - - - -
[Rex's Reply]
OrbComm is what's called a Little LEO in the Satcom business. There are a couple other particularly useful vendors in the same business. Note that the space industry as a whole is not known for delivering programs on time, so your forecast may be accurate in that you reliably quoted the OSC marketing folks.
The generation following the Little LEOs is (predictably) the Big LEOs. Three consortia have been licensed by the FCC since Feb95 and they are on a three-year timetable (caveat above applies here too). Iridium (Motorola) is the best known; Odyssey (TRW) and Globalstar (Loral/Qualcom) are the other two (note that Qualcom HQ is also there in San Diego).
In all three cases, the constellations are designed to provide a user visibility to at least one satellite all the time. (but there's not much slop or redundancy in these constellations). The three systems are compatible, but not interoperable-an earth station that talks to Iridium won't hand off to an Odyssey bird.
These folks, at least at the marketing public level don't talk data communications and aren't very Internet hip. Their model is satellite based cellular telephone. (The research we're doing here is designed to lower the curve when they wake up and understand what some of your needs other than voice cellphone are).
These, like OrbComm, allow dial-in to the Internet but can't really be considered part of the Internet. Just as your modem-equipped POTS line from home isn't part of the Internet but a means to get to an Internet POP somewhere.
The Big LEOs offer many more channels (in voice telephone slices) than the Little LEOs (because they have a lot more spectrum). For your planning, note that they're not far behind OSC.
The third generation is currently represented by Teledesic (although I'm getting unrepeatable intel that there are other systems in planning) which we should see around 2002. Teledesic got it's spectrum license from FCC last Feb. The company is a spinoff of AT&T, McCaw, and Microsoft.
Of the 840 satellites, you will be able to see at least two at elevation angles of >40 degrees anywhere in the world. Teledesic satellites will have crosslinks (Iridium is the only Big LEO that does this and LEO One is the only Little LEO that does).
We are rapidly reaching the stage where internetworking a ship at sea will be about as difficult as a building or lab ashore today.
(Cont. from page 1)
That's right the RVTEC logo search is on!. Your selection
for a logo could be the one selected to symbolize RVTEC. Remember
to bring your selection to the meeting on a 3.5" disk in
.JPEG or .GIF format for submission.
Progress Being Made On Data Interchange Standards
The RVTEC Data Standards Initiative has produced a demonstration version of a netCDF extraction tool, as agreed upon at the 1995 annual meeting. The extraction tool will use WECOMA netCDF files as input, and has numerous options for output. Executable and source-code versions are available, as well as some documentation of the program. This effort was supported by NSF-OCFS.
The software and documentation will be available after 26 August 1996 as a web page at: http://lubber.oce.orst.edu/netet.html.
Users will be able to FTP the software from this page, as well as view the documentation.
Questions about the software, documentation, etc. can be directed to the developer, Tim Holt (OSU); holtt@oce.orst.edu.
NetCDF and data standards will be a topic of discussion at the 1996 Annual Meeting.
Editor: Marc Willis
Layout: Richard Findley
Asst. Editor: Miguel McKinney