On Thursday 2/19 we held a meeting to refine the science requirements for
the respirometer software application.  Attendees were Bob Herlien, Mike Risi,
Jim Barry, Kim Reisenbichler, and Kurt Buck.

Mike Risi and I presented the attached materials as background for the
discussion.  Mike's PowerPoint slides served as background for discussing
what the software architecture would support, and my requirements doc served
as a straw man for discussion.

A main point of the discussion was the unit of control.  The hardware allows
a single controller to support multiple "chamber controllers" -- theoretically
hundreds, but practically probably one or two dozen.  Each chamber (or I/O)
controller is intended to support a single respirometer chamber.  We discussed
the fact that the basic software unit of control would be either a single
respirometer chamber or a set of multiple chambers.  The latter needs to be
supported because the experiments are sometimes set up to plumb the flush
pump through multiple chambers, due to concerns about the power to run the
flush pump.  The scientists emphasized the need for both capabilities,
particularly the need to independently control respirometer chambers
in some cases.

I presented my understanding that a typical respirometer chamber needs to
support the following:
   - Stirrer
   - CO2 Injector
   - O2 Optode
   - pH sensor (serial)
   - Flush pump

The scientists noted that it would be desirable to support the injection of
multiple types of fluid (at least CO2 plus one other tracer), and to be able
to extract samples.

Mike pointed out that the I/O controller actually contains
   - 3 serial ports, each of which has a power bit to turn on/off the instrument
   - 8 additional outputs configured as current sinks (allows on/off via switching
     the low or "ground" side of a load)

The serial ports are intended for the Optode and pH sensor, plus one spare.  The
8 additional outputs are sufficient to easily allow for additional injection and
extraction ports.

In addition to the above, the experiment needs some global sensors to read the
ambient conditions (outside all chambers).  At minimum, we need an ambient
O2 Optode and perhaps ambient pH and/or a CTD.  I discussed the two possibilities
for how to control them:
1. Via the serial ports on the main controller board.  There are 7 serial
    ports, which can be used either for strings of I/O controllers via ModBus,
    or for individual instruments.  Putting the global instruments here could
    steal up to 3 ports, leaving only 4 for strings of chamber controllers.
    This was not seen as a concern, since 4 strings could still easily support
    at least 24 chambers by putting 6 chambers on each ModBus string.
2. Convert a chamber controller to control global instruments rather than
    a respirometer chamber.  This maximizes hardware use, but is a little more
    difficult to support in software.  I intend to support this method if possible.

Jim Barry brought up the user interface for configuring the system.  He suggested
a GUI.  I noted that the controller we use can't support a GUI.  If we built a GUI,
it would have to run on a PC, build a config file, and then we'd have to manually
move it over.  I believe it would be operationally simpler to simply build a
text/menu based system on the controller itself.

All the scientists indicated that it would be very useful to have some kind of
interactive capability during deployment.  Mike indicated that he has been in
contact with Dave French, who is building an IR based serial capability into
Ventana.  Presumably this could also be ported to the Ricketts.  We could then
put a complementary IR transceiver on the respirometer controller, and have
a console port to the system during deployment.  We will pursue this possibility.