Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cunixf.cc.columbia.edu!lamont!dale
From: dale@lamont.ldgo.columbia.edu (dale chayes)
Newsgroups: sci.electronics
Subject: Re: More Data xfer UNDERWATER !
Summary: How about throughput requirements?
	 .
Message-ID: <3565@lamont.ldgo.columbia.edu>
Date: 4 Apr 91 15:20:02 GMT
References: <446.27f9b921@brb.isnet.inmos.co.uk>
Organization: Lamont-Doherty Geological Observatory N.Y.
Lines: 99

In article <446.27f9b921@brb.isnet.inmos.co.uk>, robw@brb.isnet.inmos.co.uk 
told us more about the requirements for his underwater data com system
including distance, depth, potential multipath problems, the kind of 
data being collected/transmitted, the requirement for some kind of
multistation protocol, and a baud rate.

However, he did not actually tell use what kind of throughput was
required to do the job i.e.: the number of bytes per second. On top of
the data requirement, you have to add whatever protocol for
multistation addressing plus the overhead of error detection and or 
correction.

> 
> Thanks to all who have responded.  A lot of responses have been questions
> requesting more information so here is a more detailed requirement.
> 
>   The data being gathered is water temperature, currents, light levels
>   and depth.

	so we need to add up the number of bits/bytes:

	Temperature: 		16 (if you limit the expected range?)
	Current speed: 		8 < x < 16 perhaps
	Current direction: 	approximately 8, depends on sensor
	Light level:  		8 < x <= 16 ? I'm guessing here
	Depth:			What resolution do you need 1 meter,
				.1 meter?

	then multiply the sum by the sample rate (once per minute, once
per second, once per hour) and that by the number of stations, and you
get the requirement for data throughput. (Assuming you use binary
coding, if you want ASCII coding, then multiply by a suitably bigger
number)
> 
>   The unit will be operated down to depths of around 100 meters.

	Be sure you do the pressure case design right, or you'll end
up with expensive scrap. Seawater is about 0.445 POUNDS-per-SQUARE
INCH per FOOT of depth. (Sorry about the units, thats what been stuck
in my head for too long.)

> 
>   I need a bandwidth capable of supporting 1200 baud.

	See above.
> 
>   I need two types of units one capable of transmitting about 10 feet
>   the other about 50 feet.  

	It might simplify the overall system design if you specify
only one kind that can do the whole range.

> 
>   There will be a few operating at the same time sending data to a 
>   central unit. So I need to use some sort of coding.

	One of the easiest ways to handle this is to assign each one
an address and poll them from the central, master station. It also
simplifies the problem of assigning time of sample to the data. In
addition, it allows you to keep track of failing sensor stations and
abort the experiment if you are not getting enough data to do it right.

> 
>   Some units may be hidden from the main unit by small rocks, hence
>   not always in line of sight.

	I guess I've been assuming all along that the solution would
be an acoustic link, where this problem can be alleviated to some
extent by use of sufficient power and coding to handle multipath
problems.

> 
>   FM (FSK) would perhaps be the best modulation technique, AM is
>   rather prone to noise.
> 
	It can be difficult to FM acoustic transducers because in
general, they are not broadband. But it can be done, especially for
very low (bit per second or less) data rates used for acoustic control
links.

> 
>   I hope this stimulates more discussion.
> 
>     Rob Wadsworth.

	Its interesting for me. I don't mean to squash your
enthusiasm, but there are commercial solutions to similar problems. If
you are interested, I could provide some pointers on vendors.

Dale
===================



-- 
Dale Chayes Lamont-Doherty Geological Observatory of Columbia University
Route 9W, Palisades, N.Y.  10964	dale@lamont.ldgo.columbia.edu
voice:	(914) 359-2900 extension 434	fax: (914) 359-6817