[sci.electronics] More Data xfer UNDERWATER !

robw@brb.isnet.inmos.co.uk (04/03/91)

>I need to transmit some data between two systems about 10 feet apart
>without being physically connected.  
>They will not always be line-of-sight, and they may be UNDERWATER !

>Any suggestions ?

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.

  The unit will be operated down to depths of around 100 metres.

  I need a bandwidth capable of supporting 1200 baud.

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

  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.

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

  FM (FSK) would perhaps be the best modulation technique, AM is
  rather prone to noise.


  I hope this stimulates more discussion.

    Rob Wadsworth.

-----------------------------------------------------------------------------
Rob Wadsworth   Inmos Ltd Newport GWENT UK   | EMail:  robw@isnet.inmos.co.uk
    Tel +44 633 413443 ext 269               |  
    Fax +44 633 412925                       | My own thoughts etc...........
-----------------------------------------------------------------------------

dale@lamont.ldgo.columbia.edu (dale chayes) (04/04/91)

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

phil@b11.ingr.com (Phil Johnson) (04/05/91)

In article <446.27f9b921@brb.isnet.inmos.co.uk> robw@brb.isnet.inmos.co.uk writes:
>>I need to transmit some data between two systems about 10 feet apart
>>without being physically connected.  
>>They will not always be line-of-sight, and they may be UNDERWATER !

  This response is made with the assumption that the data collection stations
  are underwater.

>  The data being gathered is water temperature, currents, light levels
>  and depth.

   If you are gathering current water termperature, vertical and horizontal
   current direction and velocity, ambient light level, and sensor platform
   depth with an associated time stamp the data should fit into a 50 to 100
   ASCII bytes packet (including the unit id tag field). If you sample (again
   making assumptions) at 1 second intervals and transmitting the sample data
   every minute to the master station the transmitted sample (uncompressed)
   would be approximately 3000 bytes long.  Utilizing a compandar (compress/
   expander) technique (hardware or software) this packet should be reduceable
   by at least 50 % to a size of approximatelly 1500 bytes.  Transmit this
   compressed data packet via a low frequency sonar system, such as the old 
   UQC underwater telephone.  This type of setup should provide transmission
   ranges up to 2 miles.  I don't believe the 1200 baud bandwidth will be a
   problem using this type of system.  The operational depth is of concern
   mainly for selecting the specific transducer.  Perhaps you could acquire
   UQC transducers from a used supply dealer.  The UQC transducer definitely
   worked below 100 meters. 

-----------------------------------------------------------------------------


-- 

//////////////////////////////////////\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| Philip Johnson                           net: phil@ingr.com                |
| Intergraph Corporation                   fax: 205-730-6445                 |

tonyb@titania.juliet.ll.mit.edu ( Tony Berke) (04/05/91)

In article <3565@lamont.ldgo.columbia.edu> dale@lamont.ldgo.columbia.edu (dale chayes) writes:

     ...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.

I'm not a marine biologist, but I would thing you might be inviting a
shark-feast (or a porpoise mating, or an octopus dance, or...) with
LF acoustic material of high amplitude.

But seriously, if the experiment has anything to do with animals,
I'd worry about blasting the tunes too loudly -- you might change
whatever it is you're trying to observe, even if you don't get mistaken
for an ailing tuna fish and get eaten by a shark first.

-- Just a dumb programmer.