NOPP P.I.
Meeting Minutes
July 7, 1998

Present: Rollie Barnaby (UNH), Ann Bucklin, chair ( UNH), Ken Ekstrom (MIT), Bob Groman (WHOI), Hartley Hoskins (WHOI), Dave Hosom (WHOI), Brad Moran (MIT), David Moundtain (NMFS), Joe Novello (Alpha-Tron), Craig Pendleton (NAMA - Portland Fish Exchange), Peter Wiebe (WHOI), Gary Williams (Clearwater Inst.)

A meeting of the Project LENA investigators was held July 7, 1998 at Clearwater Instrumentation, Inc. in Watertown, MA. The meeting began at 10:00am.

Ann prepared an agenda for the meeting and asked Bob to be the meeting recorder. The meeting minutes need to be ready within two weeks.

Discussion of Sensor System Design

We used as the basis for the sensor system design discussion Joe's LENA Hardware Concept diagram. Joe reviewed his plans to have water tight input power conditioners for both 12/24volts and 110v A/C power. A question was raised about handling 32v input and Joe said it could be done if necessary, but had not planned on it. The processor subsystem is also water tight and includes a temperature control unit to take care of temperature and humidity issues. We had a lively debate about what processor would be required. Joe felt that a 486-50MHz cpu (PC104 motherboard) would be sufficient, although others thought it necessary to use a Pentium-based processor. Hartley suggested that we prepare a list of software that would be run on the system along with each software's requirements for processor speed and bandwidth before selecting the processor. We agreed that we needed this information to help make the decision.

The processor subsystem included an I/O port for testing the system, hard drive, and port(s) for the GPS and the telecommunications transmit/receive (T/R) unit(s). Joe thought that the GPS and T/R unit would be in a single, off the shelf, package, but that still needs to be determined. The Trimble unit was mentioned.

There is also a possible need to interface to an existing boat locator system via serial interface but this was not decided. [Note sure about this.]

Input from sesveral sensors would also be supported including "alarm", "bilge high water", and "sink". No engine sensors are included at this time but could be optional.

The display panel would either be a VGA or SVGA flat panel or customer supplied CRT display (with appropriate caveats). The system would also support a keypad or a keyboard. There was a lively debate about the best input device. Joe felt strongly that a keypad would offer the simplist user interface and be much more acceptable to the fisherman he knows. Rollie and Craig felt that the fisherman they knew would want the added functionality (e.g. creating e-mail messages) that a keyboard would provide. Joe said that the system would support both, so that both types of users could be accommodated. It was noted that a mouse would be necessary too if a windows based operating system (or software application) were used.

The memory size, disk size, I/O ports, display interface, BIOS and Watch dog timer still need to be determined. Also, the ability to support an external floppy disk or CD-ROM drive for software updates and software add-ons still needs to be discussed.

We discussed what operating system should be running. Many felt that Windows 95 or Windows NT would be required in order to handle the multi-tasking operations such as data acquision, telecommunications and user applications. Bob noted that the operating system was likely to be the software package requiring the most system resources and that if we chose either Windows 95 or NT then a Pentium processor would be best. Selecting the operating system was also deferred pending feedback from the fisherman about what features they would like.

We also discussed what navigation tracking software would be used. There are several off-the-shelf packages including NAVTRACK, Captain, DataTech, etc. Peter thought that there existed a standard user file format that one or more of these packages supported. This allowed additional information such as temperature along the track or temperature along the bottom to be displayed as well. He will look into this.

We realized that as be finalize our plans for the system design that certain components may cost more than originally budgetted. We agreed to work together and agreed to equallly share the financial burden of these design changes.

Possible Products - Initiate Conversations with Fishermem

We briefly discussed what products fishermen might want. Hartley felt that, to be useful, requests for products from a boat should be satisfied within three (3) hours of the request. Some things mentioned include:

It was noted that the actual implementation of modeling results was not part of this proposal. It was also noted that there could be liabilities invovled if the information provided back resulted in a problem or accident.

People were aware of the sensitivity of the fishermen that their locations while fishing not be available to competitors. The implication was that data products could not show actual boat locations in any form other than to the the originator.

Rollie, Joe, and Craig will be contacting fishermen for their thoughts and suggestions about possible products. A sample user interface design (implemented on the Web) will be provided to Rollie, Joe, and Criag by Peter and Bob, based on the suggestions from this meeting. This sample user interface will better enable a demonstation of the system's capabilites. They need this material as well as some on-line documentation within the next few weeks.

Rollie, Joe, and Craig will prepare a list of questions that they will pose to the fishermen for the group's review and comments within the next few weeks.

They hope to complete their informal survey of fishermen before our next meeting in mid August.

Wheelhouse System Flowchart

Ken presented his prelimlinary Wheelhouse System Flowchart for review and comment. At start-up the system initialization takes place, including gear sensors, IMET sensors, SST sensor, GPS sensor and satellite and other sensors. The system clock is updated with UTC time from the GPS system. There are then two concurrent processes taking place:

Data acquisition takes place every 60 seconds and includes getting the metadata, and IMET and SST sensor data, and querying the gear module for data if available. Every 60 minutes transmit the data back to shore if the satellite is available.

[Editor's note: Not discussed was the process necessary for getting messages (e.g. e-mail) from shore. This might be a separate step or occur whenever the data transmission steps are done.]

Trawl Wire Data Acquisition

Gary outlined his plans for the sensors and interface for the gear data (temperature and pressure). The unit would consist of sensors and transmission unit mounted on the trawl, and a receiver unit and interface to the computer acqusition system mounted in the boat. He will provide more details, including drawings, witin the next several weeks.

We discussed both the fishermen and science needs. They are somewhat different. For example, the fishermen do not require temperature information as often, either in the water column or along the bottom. Science would like the data during the start and end of the trawl to see the data in the water columns at both locations. We discussed at what interval to record the data. Brad suggested a scheme that would look at the change of pressure first (to collect vertical profiles each meter) and, if there are no changes, to then look at elapsed time to get the data along the bottom. Acquisition along the bottom could occur about every 30 meters. We decided on acquisition every 20 seconds [please verify]. It was noted that rough topography or even a heaving boat could foil this scheme since a change of more than one meter was likely even while trawling along the bottom. We also noted that a trawl start (or possibly end) time is required in order to correlate the data with time and therefore position. (It end time is used then there also must be a record kept of when the unit stopped taking data in case the internal memory is insufficient to accommodate a very long trawl.) After some discussion it was decided to use a five (5) hour average trawl time and 400 meters (~1200 feet) as the deepest water for determining the on-board sensor memory requirement.

Gary and Dave H. will cost out the sensors, both climate and non-climate quality, in time for the next meeting.

Data Parameters

Bob handed out a summary of the data parameters based on input from Dave H. The table contains an estimate of the record lengths and therefore the data transmission bandwidth. Bob used a one (1) minute repetition rate for these data (not counting trawl data) and determined that 17,880 bytes per hour would be collected. This would take one (1) minute to transmit at 2400 baud. His estimates for trawl net/subsurface data rates we incorrect and need to be recomputed. However, the data rates are expected to be within the low end range. It was also pointed out that the climate quality (high resolution) data need not be transmitted back in near real-time and could wait until the end of the voyage before being transferred to the central server.

We then prioritized the data as follows:

Data Priority
Description Priority
(1 is highest)		 Sub-priority
(A is highest)
wind speed/direction 1 B
barometric pressure 1 B
humidity 2 -
air temperature 1 C
short wave radiation (visible) 2 -
long wave radiation (IR) 2 -
precipitation 2 -
sea surface temperature 1 A
ships position (GPS) 1 A
date/time of observation (utc only) 1A
ship heading (compass bearing) Derived
not applicable		 -

Identification of Resource People

Ann requested that people continue to provide her with the names of potential resource people and of people who should be kept informed of our project. She will contact the "UMass person" (see David M.), Charlie Anderson and Dave McCarron to see about speaking to us, perhaps at our August meeting. Also, Peter will contact Dan Lynch about someone making a presentation to us about computer modeling.

Identification of Customers and Marketing

The following action items were identified:

Public Presence

It was agreed that our public web site at URL http://lena.whoi.edu:8180/ needs to be in place by August 18th. It should include material that describes the project, schematic designs, PI list, etc., and other material that helps people understand what we are doing. Ann will rework the first three pages of the White Paper for this purpose. Peter will provide Bob with an image to use on the home page.

It was agreed that material would first appear on our internal web page for preview before it goes public.

Ann requested that Bob prepare instructions on how to submit material to him for inclusion on the web site.

Dealing with Program Managers

Ann will continue to be the primary (and only) contact with our Program Managers.

Next Meeting

Our next meeting will be Friday, August 21, 1998 either at UNH or MIT depending on which resource people will be coming.

The meeting ended at 3:15pm.

Submitted by: R. Groman
July 8, 1998