UNOLS RVTEC

Interface July 1995

UPDATE FROM THE CHAIR
Rich Findley, University of Miami

UNOLS NEWS

At the April UNOLS Council meeting NSF brought up a discussion 
concerning the size of the fleet and overall financial support by all 
agencies  Downsizing or fleet redistribution and how that might be 
accomplished were also discussed.  In general, the entire picture is 
clouded by uncertainties in government funding.  Additional 
complications are brought on by the status of NOAA and the 
future of its fleet.  In any of these cases changes in the 
UNOLS fleet will have an impact on the maintenance of 
experienced technical groups.

The Fleet Improvement Committee is concerned about safety issues 
aboard UNOLS vessels and has asked that our group get involved in 
making suggestions for safety improvement.  An example cited by one 
scientist concerned piston coring operations that had not been 
performed aboard that particular ship in some time.  The technician 
that had been available onboard the vessel was no longer employed by 
the institution.  Fortunately, one of the crew members onboard 
had observed piston coring operations before and was able to help.

We have a good start in addressing both the issues of 
downsizing/redistribution and safety through technician exchange 
programs and subcontracting of technical support  As a group, we 
need to continue these efforts and seek additional methods to make the 
best use of the available funding, instrumentation, and technical 
expertise.

1995 ANNUAL MEETING 

The 1995 annual meeting will be held at the Monterey Conference 
Center on October 16- 18.  A block of rooms has been reserved at the 
Casa Munras Garden Hotel for arrival on Sun., October 15, 1995  and 
departure on Wed., October 18.  Rates are $69 (1 bed  single or double 
occupancy), $89 (2 beds), $89 preferred  rooms (1 or 2 beds), $99-119 
Fireplace rooms (1 or 2  beds).  You must make your reservations 
(California:  800-222-2446, Nationwide 800-222-2558) by September 
15 and identify yourself as being with the RVTEC Group to qualify for 
these rates.

I have started the agenda and am I am seeking your input.  Please send 
agenda items to the RVTEC distribution list or give me a call (305 
361-4175) ext. 9). 

EDITOR'S NOTE
Tim Pfeiffer, University of Delaware

This is our first attempt at publishing the newsletter electronically.   
We've sent out a copy via email to the RVTEC mailing list and it is 
also available via gopher and the World Wide Web.  Gopher access is 
through  and the URL for WWW access is 
 or  .  Please let 
us know how you feel about the electronic version of the newsletter 
compared to paper.

This issue contains:
-  an article from Steve Rabalais, LUMCON, discussing the 
possibility of a dissolved oxygen seminar for the meeting
-  a discussion of an underwater splicing technique from Tom 
Wilson, Stonybrook
-  a description of the Distributed Oceanographic Data 
System by George Milikowski at the University of Rhode Island
-  a note describing a winch monitor display from Tim Deering, 
University of Delaware
-  and a description of a PC to gyroscope synchro outputs by 
Mike Hill, OSU

TECH TRAINING 
Steve Rabalais, LUMCON

I suppose it's time for the Tech Training (Entertainment) Committee  
to begin searching for an appropriate topic for a training session at the 
next meeting. If you have a particular topic that you would like 
explored (keep it clean) now's the time. I anticipate a session similar 
to  the standard sea water lecture at the Miami meeting, but I 
am open for ideas.

My Suggestion: 

I recall there being some interest at the Miami meeting in a training 
session on  dissolved oxygen measurements; their importance to marine sciences, the state of the art in new probe technology, proper 
techniques for conducting calibrations, etc., etc. 

We do a lot of work with coastal oceanographers on our ship. These 
guys are a bit obsessed with hypoxic/anoxic bottom waters and depend 
on our instruments to give them the DO data that they so desperately 
crave. Are we doing a good job?  Some instruction from experts versed 
and knowledgeable in the field certainly couldn't do any  harm.

I don't know how many of you actually calibrate your instruments with 
Winklers, we do end points at the beginning and end of each cruise 
and assume that the scientists are doing  their own calibrations. End 
points, of course, are useless if you are interested in absolute  numbers.
Now, it has been a long time (back when dirt was still on the periodic 
table) since I did a Winkler, but as I recall it's not a straight forward 
measurement; in other words,  your techniques can lead to poor 
calibration data. Is the answer automatic  titrators?  I've never used 
one so I can't really say.  But, I am certainly willing get some pointers 
from the experts on how and when to calibrate our instruments. 

Ken Lawson and his group at Sea Bird have been working for 
sometime on a new probe and have quite a bit of time invested in the 
subject. Bob Millard at WHOI may also be a  potential source of 
information.  If this sounds good to you and you know of another guru 
that you think could put new life into the old question of DO, let me 
know.  I would also appreciate some ideas on the burning DO 
questions that are confronting you, does your  probe depolarize 
prematurely, are your Winklers out of winkle ? 

 Of course we are not tied to the DO problem. If you have another pet 
topic that you would like kicked around, let me know.  For instance, 
there is still the unresolved issue surrounding the Sea Tech 
transmissometer and temperature/depth compensation.  Perhaps some 
guidance in one form or the other on how these babies work could 
shed some light on the issue.  How many of you are using OBS's?  We 
have one on our CTD but I'll damned if I can ever recall anyone 
calibrating the thing or showing any interest at all in seeing the data. 
The subject of towed CTD's is also one that I am particularly interested 
in right now.  We have a grand plan to convert an old CTD winch into 
a "Sea Soar" winch and fly an Endeco/YSI wing and SeaBird CTD 
using the winch in the "automatic mode" to keep the instrument at a 
desired depth.  We've seen it work on other applications and we think 
we can make it work as a standard part of our ship's scientific 
sampling suite.
 
So there you have it, let me know what tickles your fancy and we'll get 
the ball rollin'.  Operators are standing-by.    


A SIMPLE SPLICING TECHNIQUE FOR UNDERWATER CABLES
Updated: 22 June 1994.
Thomas C. Wilson, Jr. and J. David Lucyk 
Electronics and Ocean Instrument Laboratory 
Marine Sciences Research Center

State University of New York Stony Brook, NY 11794-5000
Tel: 516-632-8706 * FAX: 516-632-8820 
Internet: Twilson@ccmail.sunysb.edu 

INTRODUCTION
A simple technique has been developed for the splicing of underwater 
electrical cables commonly used in oceanographic instrumentation.  
This method can be performed in the field with materials easily 
carried in a technician's toolbox.  Materials can be obtained at most 
professional electrical supply houses.  Splicing can be accomplished 
much more quickly than with poured resin splices.  A typical splice 
can be made and placed in service in one to two hours.  The splicing 
technique works well on both neoprene- and polyethylene-jacketed 
cables/wires.  Durability of the finished splice is such that our 
technical group uses it as our primary splicing method.  Splices using 
this technique have performed at depths of up to 1500 meters, after 
immersions of up to three years, and over hundreds of pressure cycles 
with no discernible degradation.

This splicing technique depends on forming a watertight flexible seal 
over the conductors, covering that seal with a layer of relatively soft 
and compressible elastomer, and finally "preloading" the compressible 
elastomer with a final layer of electrical tape.  The finished splice has 
no air voids.  As pressure on the splice increases, it simply squeezes 
tighter to the conductors, affording no entrance to the water.  In this 
way, the splice behaves much like a pressure balanced connection.

MATERIALS AND TOOLS NEEDED
All brand names and trademarks are property of their respective 
owners.

As this splicing technique has evolved, we have located better and 
better materials for performing the splice.  Accordingly, we will list in 
some cases our current choice for "best" material or technique and one 
or more alternative materials.  In our experience, the technique is quite 
robust, and experimentation with alternative materials is encouraged.

REQUIRED MATERIALS AND TOOLS
1.  Sealant.  This is used to provide the initial seal over the 
conductors. Our first choice is Scotchkote, manufactured by 3M 
corporation.  It is a tarry goo, usually sold in metal quart cans with a 
brush built into the cap.  It is available at most electrical supply 
houses.  A second choice is liquid neoprene, sold under the trade name 
of "Liquid 'Lectric Tape" at boating supply stores.  It takes longer to 
dry than Scotchkote, and the fumes are somewhat more offensive (to 
the authors, at least).
2.  Self amalgamating tape.  This tape is known to electricians as 
"rubber tape", and is sold in major electrical supply houses.  It looks 
like thick electrician's tape.  When it is stretched out to its elastic limit 
(about two times its unstretched length), then wrapped around an 
object, it slowly joins to itself, forming essentially one piece of rubber.  
Our preferred rubber tape is Scotch/3M Type 2242 Linerless Splicing 
Compound.  Other rubber tapes will work, but many have a thin 
plastic "snakeskin" liner between the layers of tape on the roll that 
must be peeled away before use.
3.  Vinyl electrician's tape.  This tape should be of the highest quality 
available.  It is important that the tape be highly elastic.  Our choice 
for this application is 3M/Scotch Super 33+ vinyl electrical tape.  
Scotch 88, touted by some for its extended flexibility in low 
temperatures, is not recommended because it is thicker and does not 
stretch as well as Super 33+.4.  Cleaner.  Methyl ethyl ketone (MEK - 
available bottled from chemical supply houses or in spray cans as 
automotive carburetor cleaner, trade name "Gumout" or similar) is 
excellent for heavy duty cleaning of cables before splicing.  A supply 
of ethyl or isopropyl alcohol is also recommended, and alcohol or flux 
stripper can substitute for MEK if MEK is not available.
5. Tooling.  Standard small wireworking tools, pliers, cutters, 
strippers, solder and iron.

RECOMMENDED MATERIALS AND TOOLS
The following additional materials are recommended for best results 
and/or quicker splicing:6. Heat shrink tubing.  Shrink tubing in a size 
appropriate to fit over the insulation of individual wires (and shrink 
to the size of the conductor inside the insulation) is good to have.  
Sealant will add to the diameter of the insulation, so tubing should be 
a little loose on the insulation before shrinking.  Clear tubing is 
recommended to allow visual inspection for voids under the shrunken 
tubing. 7.  Heat gun.  Use of a heat gun will speed up the drying time 
of the sealant (and is needed as well if heat shrink tubing is used).
8.  Wire crimp splices.  For butt connection of conductors.  These can 
be either standard electrical butt splice connectors with the insulation 
cut off, or short sections of small diameter copper tubing (available in 
many hobby stores).
9.  Nylon cable ties.  These are used in the final layer as a "splint" to 
prevent excessive bending of the finished splice.

METHOD
1. Cable preparation.  Lay the cables out and determine which 
conductors are to be joined.  It is recommended that individual 
connections be staggered along the cable, separated by an inch or so, 
as opposed to making all connections side by side.  Strip back any 
cable jacketing, allowing two inches from any connection to the 
remaining cable jacket.  Clean all insulation with a paper towel and 
MEK (second choice alcohol or flux stripper).  Particularly waxy or 
dirty cable jackets should be scraped clean with a knife blade and then 
chemically cleaned.  Raising a little "tooth" on outer cable jackets by 
scraping with a knife is also recommended. 
2.  Electrical connections.  If heat shrink tube is to be used, slip 
lengths of it over the conductors now.  Minimum length of the heat 
shrink should be length of the stripped conductor plus 1/2 inch.  
Connect desired conductors in such a fashion as to produce a smooth 
void-free cylindrical connection with the wires exiting in opposite 
directions.  This can be accomplished with a common butt splice 
crimp connector (cut the insulation off first and solder after 
crimping), by inserting the wires into opposite ends of a short (3/8 
inch) length of small diameter copper tube and soldering, or by simply 
bringing the wires together from opposite directions, twisting the 
stripped ends together while keeping them parallel to the conductors, 
then soldering.  After soldering, deflux the connections with a little 
alcohol or defluxing spray.
3.  First sealant layer.  Apply a coating of sealant to exposed 
connections and to one inch of adjacent insulation.  Let sealant dry.  A 
heat gun may be used gently to speed up the process provided that you 
do not prematurely shrink the heat shrink.  A little bubbling of the 
Scotchkote is not cause for concern.  Keep individual conductors apart 
so that they do not stick together.
4.  Conductor covers.  If using heatshrink, slip tubing over connections 
and shrink it down.  Shrinking from one end to the other is 
recommended.  If after shrinking a large void exists above the 
conductor, cut the heatshrink off, apply rubber tape directly to the 
sealant coated conductor to build up the diameter (see below for 
method), brush a coat of sealant on top of the rubber tape, then shrink 
the heatshrink over that (or use electrical tape to avoid having to 
unsolder and resolder the connection).If not using heatshrink, a layer 
of electrical tape should be added at this point if there is any 
possibility of conductors coming in contact by migrating through the 
rubber tape.  Apply a thin layer of rubber tape over each conductor, 
then a layer of electrical tape.
5.  Void-filling. (usually not needed).  Place conductors together as 
they will be in the finished splice.  If large gaps or voids might appear 
between conductors in the finished splice, make up a little "snake" of 
stretched and rolled rubber tape and insert it into the void area, or 
wrap conductors in the void area with a layer of rubber tape.
5.  Second sealant layer.  Apply a second coat of sealant over the 
whole splice area and two or three inches onto the outer cable jackets.  
Work the sealant inside the cut ends of the cable jackets and between 
conductors in the splice area.  Arrange conductors tightly together and 
allow sealant to dry, helping with a heat gun if desired.
6.  Rubber tape layer.  Hold the splice in gentle tension and apply 
several thicknesses of rubber tape to the entire splice area, extending 
1 inch or more over the outer jackets.  To apply rubber tape, take a 
length (removing the snakeskin liner if necessary) and stretch it to its 
elastic limit (approximately 2 times unstretched length).  Holding the 
tape at its elastic limit wrap it around the splice, overlapping adjacent 
wraps by 50% or so.  Many layers of rubber tape can be used to build 
up a desired thickness and form "Y" splices, etc.  Use of several short 
pieces of rubber tape improves control and does not impair the 
finished product, although it is suggested that ends of rubber tape 
sections be placed away from connections and the ends of the splice.  
The finished rubber tape layer should be smooth, even, and at least the 
diameter of the original cable jackets.
7.  Electrical tape layer.  Apply two layers of electrical tape over the 
rubber tape layer.  Tape should be tensioned as tightly as practicable 
and adjacent wraps overlapped about 50%.  Extend the electrical tape 
about 1 inch beyond the rubber tape on the cable jackets.  Slack off the 
tension to zero on the last few wraps to prevent the tape from 
unraveling.
8.  Splint layer.  Cut the ends off three or four nylon cable ties.  
Using electrical tape, fasten the ties to the outside of the splice so 
as to stiffen and "splint" the areas of electrical connection.  Use of 
the splints will extend the life of the splice by prevent flexing and 
breaking of the soldered connections.Splicing is now complete.  After 
testing for electrical continuity and insulation integrity, the cable can 
be deployed immediately.


DISTRIBUTED OCEANOGRAPHIC DATA SYSTEM (DODS)
George Milikowski, University of Rhode Island

It doesn't take long using the World Wide Web (WWW) to discover 
many hundreds of scientific datasets that are currently available on-
line to researchers.  For oceanographers the volume and diversity of 
data from national archives, special program offices or other 
researchers that is of potential value to their research is overwhelming. 
However, while a large number of oceanographic datasets are on-line, 
from the research oceanographer's point of view there are significant 
impediments which often make acquiring and using these on-line data 
anything but easy.  What are the problems?

To begin with, the storage format of data is many times system specific 
making it difficult to view or combine datasets from different systems. 
Also, a majority of data archives have developed their own data 
management systems with specialized interfaces for navigating their 
data resources. With the notable exception of NASA's EOSDIS 
Version 0 Information Management System (NASA's EOSDIS V0 
IMS provides a single interface to 8 NASA earth science data centers 
and the CIESIN social science data center), none of these data systems 
interoperate with each other, making it necessary for a user to visit 
many systems and `learn' multiple interfaces in order to acquire data.  
Finally, even after the data has been successfully transferred to the 
researcher's local system in order to use the data a researcher must 
convert that data into the format that his or her data analysis 
application requires or alternatively modify and recompile the analysis 
application's source code. 

To address these distributed data access problems, researchers at the 
University of Rhode Island and the Massachusetts Institute of 
Technology are creating a network tool that, while taking advantage of 
WWW data resources, resolves the issues of multiple data formats and 
different data systems interfaces.  This network tool, called the 
Distributed Oceanographic Data System or DODS, enables 
oceanographers to interactively access distributed, on-line science data 
using the one interface that a researcher is already most familiar with, 
his or her own personal data analysis application.  The architecture 
and design of DODS will make it possible for a researcher to open, 
read, subsample and import directly into his or her data analysis 
applications scientific data resources over the WWW.  The 
researcher will not need to know either what format is used to store the 
data or how the data is actually accessed and served by the remote data 
system. 

DODS: An extension to existing interfaces

The Distributed Oceanographic Data System is not a data management 
system, nor is it used for creating data base schema and inventories.  
Rather, DODS is a specification for directly accessing, representing 
and transferring data on a network (the Internet).  It is a data access 
protocol which defines both a common functional interface to data 
systems and a data model for representing data on those systems.  It is 
designed to be integrated with already existing user applications and 
resource management systems, not to replace them.  DODS extends 
the operational capabilities of existing systems in two important ways; 
first, through its network interface it transforms a user's application 
into an agent of a distributed client-server system and second, it 
provides a system independent, integrated view of their resources.

For transforming a user's analysis application into network client 
DODS includes client libraries which when linked with the application 
provide the client-server network interface and necessary client-side 
operations supporting client-server communications.  The key to 
providing an integrated view of data resources is the DODS data 
model.  The DODS data model defines a set of data types and 
constructs which are used to represent the content and structure of data 
files (analogous to data types that are used in programming languages such as C and FORTRAN). All data transferred by a server to a DODS 
client is first translated into a canonical representation using the 
DODS data model.  When the client receives the data it then translates 
the DODS canonical representation to the data representation that is 
valid for the application.  For any new data format to be supported by 
DODS two translators need to be created.  One that translates from the 
data format to the DODS data model and one to translate from the 
DODS data model to the format.  The benefit of this approach is that 
newly created client DODS-to-application translator can immediately 
access any DODS data resources regardless of the format used by the 
remote system for storage of the data.  Likewise, a new server format-
to-DODS translator will immediately support access by already 
existing DODS client applications.  

Systems wishing to use DODS as a means of providing access to their 
data resources and/or in accessing other's resources through DODS do 
so through the implementation of the DODS client-server libraries.  
The server libraries enable data systems developers to install servers 
which: 

-  Utilize httpd as the network server for client-server interactions.
-  Define a DODS network server interface to the remote system that 
then allows DODS client applications to query and access a server's 
data resources.
-  Provide detailed information on the structure and attributes of a 
server's data resources.
-  Translate data resources utilizing the DODS data model into a 
DODS canonical representation for transfer. 
 
DODS compliant user applications use client libraries developed for 
specific common Application Programmers Interfaces or APIs (An 
API is itself a software tool that is typically a discrete set of procedures 
or commands which provide a formal method of access to a 
computational resources such as a disk file, a data management system 
or a device such as a display screen).  For a DODS compliant API the 
software libraries provide:
-  A DODS surrogate library which maps API procedure calls to 
DODS API procedure calls.
-  Means for encoding of user query for transmission to DODS servers 
-  Customized translators for decoding from the DODS canonical 
representation of data to API specific data format.

DODS: A Means of Accessing PI Data

One of the motivating factors leading to the development of DODS 
was the desire to access researcher held datasets as well as the data 
resource of large data centers.  The large data systems being developed 
by agencies within the government were previously seen as focusing 
only on the data resources of those agencies and having no integrated 
plan to include datasets of individual researchers.  Datasets that are 
considered scientifically valuable to the research community.  The 
model for these large data systems was that researchers were data 
users and the agencies data providers.  Within DODS researchers are 
seen as both data providers and data users.  Therefore, designing a 
system which provides an effective option for researchers to serve as 
well as access data is one of the primary goals of DODS. 

Status of DODS Development

A beta version of a NetCDF/DODS client-server libraries is now 
available.  In the very near future JGOFS/DODS libraries will also be 
distributed.  The client libraries are easily linked with existing 
applications without the need to modify application source code (i.e., 
the API procedure call names that are used by an application remain 
the same in DODS, relinking the application with the DODS client 
libraries causes the procedure calls to reference the DODS surrogate 
procedures).  DODS server libraries are installed behind a system's 
httpd server with a minimum of effort.  Binaries for DEC/ULTRIX, 
DEC-ALPHA/OSF, SUN/OS, SUN/SOLARIS, SGI/IRIX and 
IBM/AIX will be available.  Detailed technical information, how to get 
binaries or source code for the client-server libraries and papers 
documenting the development of DODS are available via the WWW at 
http://dcz.gso.uri.edu/.

The DODS is being developed to help address the need within the 
oceanographic community for researchers to easily access and serve 
data resources over the Internet.  DODS developers are creating a data 
access protocol based on a client-server architecture in order to take 
advantage of and promote the availability of on-line research data.  
Two unique aspects of the DODS system design are that it transforms 
researchers' data analysis applications into client agents within DODS 
and that it provides a system  independent view of the data resources 
available through its servers.  Rather than trying to replace or build a 
system from scratch, DODS is purposefully designed to be integrated 
with already existing data systems and user applications, taking 
advantage of and extending those systems' capabilities.


WINCH MONITOR DECK DISPLAY
Tim Deering, University of Delaware

We needed a new deck display for our trawl winch monitor and in 
addition to the winch data we wanted to display time, depth, position, 
and some of the SAIL data.  Since we couldn't find a unit that would 
fit the space we had available and do all that we wanted we decided to 
build our own.  We used a two line by twenty character LCD display 
module and a four key keypad module, both of which have RS 232 
interfaces built in.  We used two of the keys to zero the two drums of 
the trawl winch, one of the spare keys runs a stopwatch for timing 
plankton tows, and the last key cycles through several display screens 
with the navigation and SAIL data.  We've just finished assembling 
the display and it worked well on the first cruise.  I'll be happy to 
provide more detailed construction information to anyone interested.


P. C. SYNCHRO INTERFACE
Mike Hill
Mar Tech Group
OSU-COAS

Abstract:  An interface is presented for the acquisition of shipboard 
earth referenced heading information.  The target system is the Sperry 
line of gyro's equipped with a 1:1 synchro follower.  The design uses 
commercially available components and "glue logic" to provide 12 bit 
resolution and acquisition speeds of at least 20 Hz.

I.  INTRODUCTION

Baseline shipboard data acquisition must include earth referenced 
heading information for conversion of ship referenced relative 
headings.  On R/V WECOMA this earth referenced data is provided 
by the ship's Sperry gyrocompass.  Output to shipboard systems is via 
a 70 VDC stepper motor which provides information about the relative 
heading of the ship in 0.33 degree increments.  By aligning the system 
to the true heading of the vessel (read in the viewing window of the 
gyro), systems then track with the stated accuracy of the system.  For 
science systems, another method is used 

The gyro is fitted with the optional synchro which follows the 
gyrosphere, driven by mechanical gearing with a ratio of 1:1.  By exciting the synchro with an AC (60Hz, 90 volt) signal absolute 
position of the sphere may be directly determined.  Thus, no initial 
heading determination must be made by the user.  This method 
provides true heading at the stated accuracy of the gyrocompass used 
(with an offset due to initial synchro alignment.)  For the Sperry 
gyrocompass aboard the WECOMA the absolute accuracy is 
approximately 1 degree in low sea states decreases as the sea state 
increases.  Synchro to digital conversion accuracy specifications are 
scaled to this figure.

A search found converter resolution in the 12-bit range available at 
reasonable prices.  The converter selected provides +/- 8.5 minutes of 
accuracy.  This ensures the data provided is limited by the sensor 
accuracy and not by the measurement system.  

II.  CONVERTER SELECTION

After specifications are considered, empirical data entered into this 
decision.  I chose a converter from a company whose products have 
never failed during use aboard WECOMA since 1985 and are still in 
daily use today.  This particular device is a "black box", with synchro 
data in and 12 bit data output.  Signal lines are provided for easy 
interface to any bus structure.  Manufacturer options include scaling 
for the 90 VAC excitation normal to Sperry gyrocompasses 
eliminating the need for external scaling resistors.  No special 
precautions are needed to isolate synchro inputs to the "black box" 
prior to power up.  

III.  BUS INTERFACE

The simplest method of attaching the "black box" to a particular bus is 
through the use of prototype cards.  The card selected should provide 
buffered access to PC bus signals of the following types:
-  address bus:  Where the PC bus is trying to access
-  data bus:  For moving data to/from the device
-  I/O:  signifies selection of I/O mapped ports as compared to memory 
mapped I/O.
-  RD:  Signifies selection of direction of data flow. (toward the CPU)
-  WR:  Signifies selection of direction of data flow (toward the 
selected device).
-  BoardSelect:  Signifies I/O and address is true.  
Normally selects a block of I/O addresses(8 or 16 to which the board is 
mapped

Transfers of synchro data are done in 8 bit bytes, therefore the 
prototype card need not be of the 16 bit variety.  Sufficient board area 
must be available for the mounting of the "black box" and the 
necessary "glue logic".

No recommendations are made for a specific prototype card, but ask 
for documentation prior to purchase!  if there is none available or you 
can't understand it...don't buy it.  There are enough jumpers to set to 
get the card running that the documentation is vital.

IV.  GLUE LOGIC

There are three steps necessary to reliably transfer the synchro data.  
First, the converter must be prevented from updating its output while 
getting data from it.  Second, get the lower 4 bits of data.  Third, get 
the upper 8 bits of data.  Chip types are suggested to accomplish the 
necessary tasks.  

Since more than one control signal is necessary to select specific 
signal outputs, it is necessary to further decode the I/O addresses.  
This is accomplished by using the address lines A0, A1,  A2 and the 
board select signal.

A 74LS138 uses the address lines A0..A2 to provide o1 of 8 decoding.  
The output of the '138 is AND'ed with the board select line( using a 
74LS32) to further specify the output signals.  There are now eight 
signals available for use with the synchro converter.  Include a 74LS04 
inverting buffer if needed.  

To ensure that the synchro data is valid during read operations, use 
one of the signals to trigger a 74LS122 retriggerable on-shot to 
provide an inhibit signal to the converter.  Set the output pulse length 
so that the system can perform two read operations before switching 
states.  A pulse length of 1 ms. is a good starting value.

Two other signals are used to select either High Byte or Low Byte 
converter data.  Connect the converter outputs to the board's data lines.


V.  CONSTRUCTION TIPS.

Use CAUTION in preventing the 90 VAC synchro signal from coming 
in contact with other boards or the case!  Solder all the connections.  
Use a connector which cannot be plugged into anything else for 
bringing the signals into the synchro card.  Cover the back-side of the 
prototype card with a plastic or metal shield.  Shielding the card is a 
good idea as the 0 Hz signal will couple to A/D or other acquisition 
cards in the system.  Make sure the excitation for the synchro is fused 
and switched.  Again, CAUTION!  One slip can melt down a PC!

VI.  CODE

In English the code goes like this.

BASE ADDRESS = I/O address that selects the card
OUTPUT TO BASE ADDRESS    (trigger the LS122 which inhibits 
the converter
INPUT BASE ADDRESS + 1 (read the synchro data)
INPUT BASE ADDRESS +2 (get the rest of the data)

When averaging the data remember to consider that 359.9 + 0.1 /2 
samples = 180 degrees average heading....Wrong answer!  ) degrees is 
the right answer.  Using vector averaging is on good way to handle the 
average heading data.

VII.  CONCLUSION
I have used this general approach for both the STD and ISA (PC) 
busses with success.  Circuit diagrams will be different for each 
specific prototype board used but the general approach works.  The 
current acquisition system aboard WECOMA collects 4 Hz heading 
data (and 13 other parameters), vector averages and reports pertinent 
stats for 1 minute averages.  This speed is well below the fastest 
rate possible using the 386-25 system.