1. Cover Sheet
2. Project Summary (might be shorter)
A key recommendation of the Science Plan For Carbon Cycle Research In North American Coastal Waters1 endorsed by the US Carbon Cycle Science Program is “Further development of event-scale observing capacity (e.g., novel autonomous platforms) in all continental margin systems to better quantify impacts of episodic events on coastal carbon budgets”. Profiling floats have proven exceptionally capable at addressing important ocean science questions at the global and regional scales.  The data from the Argo array of 3500+ profiling floats is now routinely used in climate models to understand ocean climate and climate change and 3800+ papers have been generated based on Argo float data.  The Southern Ocean Carbon and Climate Observations and Modelling (SOCCOM) project is using profiling floats to understand the Southern Ocean’s influence on climate4. Building on this profiling float technology, the Monterey Bay Aquarium Research Institute (MBARI) has developed and fielded the first prototypes of a new autonomous profiling float optimized for biogeochemical science missions in the coastal zones of the world’s oceans, the coastal profiling float (CPF). The CPF is as a sensor platform optimized to support biogeochemical research experiments in the coastal zones of the world’s oceans with an ecosystem size spatial scale e.g. the salmon fishery along the west coast of North America and a time scale of years.   
This proposal seeks funding in 3 general areas. 1) Add additional functionality to widen the range of science questions targetable by the CPF. 2) Maximize the probability of success for science missions using the CPF but not or minimally supported by the CPF development engineers. This can be accomplished by integrating proven production practices, including rigorous inspection, assembly and test procedures, appropriate for the size and scope of the CPF project. Both of these goals are prerequisites to achieving the third goal of transferring the CPF technology so it readily and effectively usable by the research community outside of MBARI.
Intellectual Merit
The work proposed herein advances profiling float technology in several key areas.  First, the CPF has the ability to change its volume by 3500 mL. The ratio of volume change to overall volume, ∆V/V, is a useful number for evaluating a profiling floats ability to work in high density gradients.  ∆V/V for the current CPF design is 9.2%. A Webb Technologies BGC APEX float has a ∆V/V of ~1%3 and a MRV S2-A Solo-II float ∆V/V is 3.4%2. For comparison, the density gradient at the Columbia River outfall in Oregon can be 2.5% in a few (tens of, hundreds of ???) meters (need a reference).  The CPF also has good velocity and depth control allowing consistent sampling to be achieved quickly in shallow waters.  Good depth control allows the CPF to park in a thin layer and consistently sample that water mass. The large volume change also give the CPF the ability to anchor on, and more importantly de-anchor off, the bottom in order to minimize horizontal drift between profiles. The CPF supports the complete 6 sensor biogeochemical sensor suite of CTD, Oxygen, pH, Nitrate, Optical Radiation and Fluorometer/Backscatter.  There are currently 3 unused instrument channels which are intended to provide power and communications for 3 additional sensors.
Need a compelling example of the kind of science that can be done with fleets of CPFs in a couple of sentences here.
Broader Impacts
For the beginning, it has been the explicit intention of the MBARI CPF project to transfer the CPF technology outside of MBARI.  At this point we believe the CPF has the potential to be a highly functional platform that can be used effectively by many academic and government research labs to address a range of significant questions in the coastal zone of the world’s oceans.  Upon completion of this work we expect the current MBARI CPF research prototype will be a robust, operational product available for routine use by the greater research community.  


3. Table of Contents


4. Project Description
   1. Intellectual Merit
Several recent studies have identified the need for improved ocean observing systems to understand changes in critically important regions of the world’s oceans. Navigating the New Arctic is one of NSF’s 10 Big Ideas with the goal of “Establishing an observing network of mobile and fixed platforms and tools across the Arctic to document and understand the Arctic's rapid biological, physical, chemical, and social changes … Current Arctic observations are sparse and inadequate for enabling discovery or simulation of the processes underlying Arctic system change or to assess their environmental and economic impacts on the broader Earth system“. The Science Plan For Carbon Cycle Research In North American Coastal Waters1 endorsed by the US Carbon Cycle Science Program makes a key recommendation: “Further development of event-scale observing capacity (e.g., novel autonomous platforms) in all continental margin systems to better quantify impacts of episodic events on coastal carbon budgets”. Arrays of profiling floats have proven exceptionally capable at addressing important ocean science questions at global and regional scales.  The data from the Argo array of 3500+ profiling floats (arguably the only example of a truly global observing system is now routinely used in climate models to understand ocean climate and climate change and 3800+ papers have been generated based on Argo float data.  The Southern Ocean Carbon and Climate Observations and Modelling (SOCCOM) project is using profiling floats to understand the Southern Ocean’s influence on climate4. Building on this profiling float technology, the Monterey Bay Aquarium Research Institute (MBARI) has developed and fielded the first prototypes of a new autonomous profiling float optimized for biogeochemical science missions in the coastal zones of the world’s oceans, the coastal profiling float (CPF). The CPF is as a sensor platform optimized to support biogeochemical research experiments in the coastal zones of the world’s oceans with an ecosystem size spatial scale e.g. the salmon fishery along the west coast of North America and a time scale of years.   






   2. Broader Impacts


Yui?


A somewhat unexpected potential broader impact is using the CPF as a teaching tool.  One of our colleagues, a University Professor, has expressed interest in using the CPF as an on-going project for classes in control systems, robotics and ocean engineering. We would be delighted to pursue this possibility as part of the proposed work. (Maybe a letter of support from Giancarlo?)


This is not exactly the order in the NSF PAPPG but it makes more sense to me to have IM and BI up front and the detailed plan of work follow them. 








   3. Plan of Work


We would like to emphasize that the current state of the CPF is nearing the end of the engineering development phase funded by MBARI and is nearly ready for the time consuming test-refine-repeat phase followed by a production engineering phase. We believe the CPF technology has strong potential benefits for research in the coastal zone and upper water column of the world’s oceans by the greater community outside of MBARI.  We are committed to transferring the CPF technology to the greater research community. This proposal seeks funding to maximize the probability of success of this transfer. Much of the proposed work exceeds the level that MBARI would normally support with internal funds.  However, we believe the proposed work is critical to the success of this technology transfer and will serve as a valuable pilot project for future technology transfer efforts both inside and outside MBARI. (Do we want to provide any “Voluntary committed cost sharing” page II-22 of the PAPPG?)


The plan of work falls into 3 general categories. 1) Add additional functionality to widen the range of science questions targetable by the CPF. 2) Maximize the probability of success for science missions using the CPF but not or minimally supported by the CPF development engineers. This can be accomplished by integrating proven production practices, including rigorous inspection, assembly and test procedures, appropriate for the size and scope of the CPF project. Both of these goals are prerequisites to achieving the third goal of transferring the CPF technology so it readily and effectively usable by the research community outside of MBARI.


An overview of the current status of the CPF is provided here and a detailed description of the proposed work follows. In the course of the CPF development we have built several prototypes.  The first was a proof of concept version intended for use only in the MBARI test tank (Figure 1a).  Experience with the test tank prototype drove the design of the first go-to-sea CPF prototype (Figure 1b).  That version was deployed XX times in the Monterey Bay.  We also built 2 more of this prototype for the MBARI Biological Oceanography Group who have been deploying them for their research since 201X.  Experience with these 3 prototypes drove the design of CPF serial number 001 (CPF SN001, see Figure 1c).  SN001 has all of the functionality necessary to meet the CPF science requirements and was deployed YY times in the Monterey Bay for missions up to 10 days in duration.  Based on our experience with SN001, we are currently building 2 more CPFs, SN002 and SN003 (Figure 1d). SN001, 003 and 003 have the complete set of functionality required to meet our current biogeochemical science mission.  SN002 and 003 are identical but differ from SN001 with several design refinements and one major design variation. The design refinements are relatively minor and we will incorporate them into SN001. The design variation can be seen in Figure 1, the first prototype and SN002/3 use an external buoyancy bellows integrated in the base of the CPF, SN001 use two flexible hoses for the external buoyancy, one on each side of the pressure housing.  As mentioned earlier, horizontal drift was identified as a risk at the beginning of the project which leads to a requirement for the CPF to be able to anchor on the bottom between profiles. Our concern was that in very muddy bottom types, the process of anchoring will stir up enough mud that some will work its way into the external bellows cover.  With time, enough mud may build up and interfere with the expansion and contraction of the external bellows.  We did notice a very small amount of mud in the external bellows cover during deployments of the first prototype. While the amount of mud in the cover was quite small, we couldn’t rule out the possibility that after hundreds of profiles in very muddy bottoms, enough mud would build up and cause problems. This led to the external buoyancy tubes seen on SN001. The clear tube covers surrounding the buoyancy tubes are open at the top and the bottom and there is essentially no vertical surface where mud can build up and create problems. Other than the external buoyancy subassembly (which includes the pressure housing lower endcap), the 2 CPF design variations are identical. The external tubes variation had the advantages of minimizing the probability of mud build up causing problems and is 20 cm shorter but is more vulnerable during deployment and recovery and maybe to accumulating debris during deployment. Moving forward, we intend to deploy both variations simultaneously in various environments.  That experience will help define which design option is appropriate for a specific mission environment or less likely, if one option can be dropped.


  
 


More words may be required here depending on how much we say in the intellectual merit section.


      1. Additional Functionality 


         1. Reducing power consumption
As mentioned earlier, the current CPF design has all the necessary functionality designed in to meet the science mission requirements but more work is required in several areas.  The most important is reducing the power consumption.  The current design has energy monitors for the buoyancy engine (the largest consumer of power), the rest of the electronics module, and on each instrument channel.  These energy monitors keep track of the voltage and current running through them and keep running totals for power and energy used. The energy monitors require very little power, can be powered down when not in use and don’t require much area on a circuit card assembly so we have them sprinkled liberally through the CPF electronics.  It may be that production versions of the CPF eliminate some of the energy monitors but for now, they are proving very useful. We use the energy monitors in 2 ways.  First, to characterize the actual CPF power use in critical subsystems so we have an accurate histogram of where energy is being spent.  In addition, we can use the energy monitors as fault detectors by comparing actual power usage with the known “good” value.  Our current data show the dominant energy consumer is the buoyancy engine when submerging after surface operations and how much negative buoyancy we use for anchoring.  Unfortunately, any profiling float is an awful platform for telemetry.  A small platform, e.g. all profiling floats, will have minimal stability at the surface and can only support a small, low height antennas for GPS and Iridium telemetry. This means keeping the Iridium telemetry link up is a challenging process. The more stability we have, the less energy is required to get the data ashore and the surface drift will be minimized. Similarly if we don’t apply enough negative buoyancy for anchoring, the CPF may “skip” along the bottom instead of staying anchored in one place. The tradeoff is clear, more positive buoyancy at the surface and more negative buoyancy for anchoring is beneficial but requires more energy which reduces mission duration. The work for this issue is to run more tests to determine how much positive buoyancy is required for telemetry and how much negative buoyancy is required to anchor effectively.  We have also included provisions to install a low cost, low power 3 axis inertial measurement unit (IMU) in the CPF. The IMU will give us the CPF motion and we may be able to use this data to adapt both the positive and negative buoyancy values to the actual environment.  For example, we may define multiple positive buoyancy values for surface operations.  Low positive buoyancy when the surface motion is low, high positive buoyancy when the surface motion is high and maybe a third value in-between these two. For the anchoring negative buoyancy, we may always start with a nominal value and add more negative buoyancy in small increments if the IMU shows the CPF is skipping.
As we continue to reduce the buoyancy engine energy usage, the “hotel load”, the electronics infrastructure required to run the CPF, is becoming a significant contributor to the energy budget. The work required to minimize the energy use of these consumers falls into 2 categories, first, continue testing to minimize the “on” time of the significant energy users.  The ability to turn off power to individual modules e.g., the GPS receiver, Iridium modem, individual sensors etc. is already built into the current design. The task here is to continue running tests to define more precisely when to turn modules off and on. The second category is minimizing the actual power consumption of the modules in the CPF.  We don’t have any real control of the power consumption of commercial products like the sensors and with 2 significant exceptions, most of the other electronic modules we have selected are among the lower power consumers available and can be put into a very low power sleep mode.  The 2 exceptions are the main CPF microcontroller unit (MCU) and the buoyancy engine motor controller. One of the design philosophies that drove the initial development of the CPF is that we really need to be testing in the ocean as early and as much as possible. To this end, we chose the current MCU because it was part of a hardware/software development ecosystem that has proven exceptionally efficient, i.e., we have not had to spend a lot of time learning how to use the development environment in order to get the CPF running but have been spending our time getting the CPF running using the development environment. At the beginning of the CPF development, we knew the current MCU was not the lowest power option available and we knew that we may want to replace it at some point in the future. With this in mind we made 2 design decisions to simplify a potential, future MCU replacement.  First, we selected a MCU that is part of the Cortex family of MCUs.  Currently, Cortex is the dominant choice for any embedded systems. Almost every MCU vendor is pouring a lot of money into developing Cortex MCUs and the available MCUs span the spectrum from incredibly high functionality at modest power consumption to modest functionality at incredibly low power consumption with dozens of choices at every point along the spectrum. The second design choice was to put the MCU on a small “system on module” (SOM).  This is a standard approach for embedded hardware the puts the MCU on a small circuit board, the SOM, with only the hardware needed to run that MCU.  The SOM then mounts on our custom motherboard with the additional required CPF specific hardware.  This approach allows MCUs to be upgraded very effectively by only changing the SOM and with no to minimal changes to the carrier board. At this point, we are ready to consider other hardware/software development ecosystems that will allow us to significantly reduce the hotel load energy consumption as described in section D2.2.2 below. To take full advantage of the new target ecosystem we would need to redesign the current SOM to take advantage of the significantly lower power consumption of the newer Cortex MCUs.
A similar decision was made to choose a commercial off the shelf (COTS) motor controller that we have used quite successfully in the past rather than spending the time required to build a custom motor controller.  We have used this motor controller on many previous projects and knew it could do the job but we also know it has higher idle current than we would like. Unfortunately, the current range of COTS motor controllers has not improved with respect to idle current.  Fortunately, the market for motor controller ICs has several choices with the potential to significantly reduce the energy lost when the motor controller is idle. As part of this effort we will re-evaluate the market and if a suitable COTS controller is still not available, we will design our own. 
         2. Improving Iridium telemetry
As mentioned earlier, profiling floats are terrible telemetry platforms and the energy required to transmit the data to shore after every profile is significant.  There are several things we can do to reduce energy consumption in this area.  Most profiling float have a plate mounted below the waterline to dampen the vertical heave motion.  The inherent shape of the CPF provides a similar damping effect. Additional stability can be achieved by increasing the metacentric height.  The metacentric height is a measure of a partially submerged body’s initial static stability and is defined as follows. 





Where G is the distance to the center of gravity (CG) of the body measured from the keel, KB is the center of buoyancy (CB) of the body also measured from the keel, I is the second moment of area of a horizontal cross section of the body taken at the waterplane and V is the volume of the body. It can be seen that increasing stability can be achieved by 1) decreasing the height of the CG, 2) increasing the height of the CB, 3) increasing the volume, 4) increasing the cross sectional area at the waterplane. The CPF design already minimizes the CG height by putting the heavy objects, like batteries, at the bottom of the pressure housing to the greatest extent reasonable. CB is defined by the shape of the pressure housing which for practical reasons is a cylinder. In fact we want to minimize the volume of the CPF to make it easier to ship, deploy and recover so maximizing the volume is really not an option.  That leaves increasing the waterplane area as the only available design parameter left to optimize. The current CPF design does use a stability plate at the waterplane but the current stability plate has not undergone significant analysis to optimize the design. We think a reasonable improvement in stability can be achieved with more analysis and test which will lead to a decreased in the time required for surface operations with a commensurate reduction in energy consumption. Fortunately, the CPF stability plate is a printed part and we can build and test new designs rapidly.


We are currently using a combined GPS/Iridium antenna from Trident Sensors in the UK. This antenna is based on 2 helical antenna modules, one for GPS and one for Iridium, stacked vertically. It isn’t clear how effective this antenna geometry is for the CPF application and given how much Iridium telemetry time costs in energy usage, we would like to test at least 2 other antenna types to see if we can improve Iridium telemetry performance. 
 
         3. Develop the CPF mission definition tool
A CPF mission is defined in the mission configuration file. Generally speaking, a CPF mission consists of multiple, identical profiles. Changes to the mission are made by downloading a new mission configuration over Iridium to the CPF. A mission starts with the CPF sitting at the surface after deployment. After a programmed delay, the CPF starts the descend process. Descend stops when either the CPF reaches the user defined target depth or the CPF detects it has hit the bottom.  In either case, the CPF parks or anchors for a user defined time taking samples at a user defined periodic rate. Which sensors are sampled during the park and anchor processes can also be user defined. When the park/anchor time has expired, the CPF puts the CTD into constant profile (CP) mode and starts the ascend process. Samples are taken at user defined depths and which sensors are sampled at each depth can also be defined by the user. When the CPF reaches the surface, CP mode is stopped and surface operations start. Surface operations include taking in-air measurements for surface calibration, getting a GPS position and uploading the profile data to shore. A complete new mission or individual mission parameters will be downloaded if the user posts the appropriate message(s) in the CPF mailbox. When surface ops are complete, the CPF starts the descend process and the whole profile process repeats.


Currently, several mission configurations are hard coded in the CPF and the user can select one.  Clearly, this is not the most desirable solution. Part of the work plan includes development of a shore side mission definition application that will allow the user to define all the user defined parameters described above and see the results graphically. The new mission will run through a sanity checker to insure the new mission is safe and sane and when the user is satisfied everything is correct, the new mission can be posted for download to the CPF. While a mission definition tool like this can be very helpful, like any tool it can have undesired consequences. Clearly the sanity checker has to be comprehensive and rigorous in uncovering errors.  Just as importantly, the user has to be diligent in checking that no fatal parameters exist in a new mission.  Regardless, mistakes can happen.  To help mitigate this risk, the CPF has several built in fail safes that can’t be programmed by the user and will result in an immediate ascent to the surface where the CPF enters the recovery state.  In the recovery state, the CPF powers down everything but the modules required for recovery.  A GPS positon is acquired every 15 minutes and sent to shore in an Iridium short burst datagram (SBD). The first SBDs will have whatever information is available that led to the recovery state along with some engineering data to help the user decide whether to recover, download a new mission or mission parameters and restart the mission or just restart the mission. Some of the circumstances that will start the recovery process include the following. 1) If the time from the initial deployment exceeds the maximum mission duration. 2) If the battery voltage drops below the minimum acceptable value. 3) If the maximum number of profiles has been exceeded. 4) If a mission critical module, like the CTD, faults.  


         4. Formalize the process of integrating new sensors
Integrating new sensors into the CPF is currently a pretty straight forward process, if you’re one of the current CPF software developers.  To ensure the CPF can support a wide range of science missions, integrating new sensors or different versions of the current sensor suite must be straight forward for future developers involved in the production CPF effort and were most likely not part of the current development process. We need to make sure the process of integrating new instruments can be accomplished without impacting other parts of the system, test with a few instruments not in the current instrument suite but likely to be used on science missions outside of our target biogeochemical missions and document the process.
  
         5. Shore side data processing


Do we want/need to put in time and money to work on FloatViz or something similar? 
Does all the data management stuff all really go in Special Information and Supplementary Documentation?


      2. Maximize the probability of successfully completing every CPF mission


         6. Incorporate robust embedded software best practices consistently across the CPF software
Developing robust and reliable software for any autonomous platform like the CPF or any autonomous robot, is a challenging and time consuming task. There are a number of industrial and government projects with the explicit goal of defining best practices for developing robust and reliable software5,6 These best practices include recommendations for coding and testing and are used routinely in industry and military system development environments. Currently, some of the CPF software adheres to some of the guidelines.  In addition, several years ago we integrated a software test framework into the CPF software development and have been using it ever since. However, we still need to integrate much of the early CPF software into the test framework. As an aside, we note that most of the best software libraries we use from the open source community are distributed with a test framework so new contributors to the library can add functionality and validate the new code with the existing test framework. We think it is well worth the effort to review the best practices documents, identify the practices that are appropriate for the size, scope and funding of the CPF project and make sure we’re consistently following those best practices across all of the CPF software.  


         7. Refactor the CPF software
We have been using the .NET Micro Framework for the CPF software development environment to date. This framework has proven remarkably efficient at getting us from concept to our current state.  However as effective as we’ve found the .Net Micro Framework, outside of a small group of very dedicated users it has not gained a significant market share and is only supported by one vendor. Given our priority of transferring the CPF technology to the greater research community, it makes sense to refactor the software to a more mainstream framework. Serendipitously, several very viable frameworks have become available that are consistent with the current CPF software architecture. In addition, the framework we have targeted has a suite of built in tools including static and dynamic analysis and a test framework that support the guidelines for developing robust and reliable software described above. It has been our experience that hiring a consultant who is already an expert in a particular area is a very effective way to get our team up the learning curve and have budgeted consulting time for this purpose.  With this approach although time consuming, refactoring the current software into a new framework will be a low risk effort. We are requesting funds to re-evaluate suitable frameworks, chose the most suitable framework and refactor the CPF code.   
 
         8. Enhance, extend and continue the current suite of test capabilities
Our current development process is as follows. 1) Add or change functionality and develop tests for that new or modified functionality. 2) Test on the bench top simulator.  3) Test in the MBARI test tank.  4) Test at sea. The bench top simulator in step 2 is a “smart” test fixture we built to simulate ocean pressure at the inlet to the CTD pressure transducer. The BTS operates in 3 modes.  First, the user can set a fixed pressure in dBar or pressure ramp in dBar/minute. Second, a predefined pressure profile or sequence of profiles with user defined pressure ramps and dwell times can be generated.  In this mode, the pressure ramps are independent of the control loops in the CPF.  For example, if the user defined profile sets a descent rate that cannot be achieved by the CPF buoyancy engine, the pressure at the CPF will continue ramping at the user defined rate even though the buoyancy engine cannot pump at the rate required to achieve that pressure ramp e.g. the BTS is running open loop with respect to the buoyancy engine. This issue is addressed in the third mode. Here, the pressure generated by the BTS is calculated by a dynamic model of the actual CPF physics that closes the loop between the BTS and the buoyancy engine. Regardless of the pressure ramp defined by the user, the pressure generated by BTS is calculated as a function of the pump rate command generated by the CPF control loop.  For example, if the user defined profile sets a descent rate that cannot exceeds the pump rate achievable by the buoyancy engine, the actual pressure ramp at the inlet to the CTD will only ramp at the maximum rate achievable by the buoyancy engine. The BTS was developed by a MBARI summer intern and has a lot of functionality built in that we have not had the time to fully incorporate in our development cycle and we are requesting funds for this task.


A lot of value can be had without the expense of at-sea testing by just running the CPF 24/7 in the MBARI 10 meter deep test tank. Virtually no setup or monitoring time is required to run continuous tests in the test tank, we don’t need to find ship time or wait for suitable weather conditions. The first CPF we developed was a simplified version designed specifically for use in MBARI’s 10 meter deep test tank. At this point other than the pressure housing envelope, the test tank prototype bears little resemblance to the current design.  We are requesting funds to update the CPF test tank prototype to the current design. 


While there is a lot of testing built into our development process, at-sea testing is still the critical step in declaring the CPF ready for production use outside of MBARI. We have found that at-sea testing is most effective when it is done in support of a specific science mission. We expect


         9. Get the CPF ready for production
It has always been a challenge to transfer technology from a specific research lab to the greater research community. Research labs are staffed with people who excel at turning new ideas into working prototypes suitable for their specific research needs but aren’t necessarily skilled at making a research prototype ready for production. There are several key steps in this process. First, the mechanical and electrical hardware needs to be re-evaluated for production. It is our view that much of the production engineering needs to be done by the entity responsible for the production effort as a function of their specific production resources. For example, we have excellent 3D printing capability at MBARI. Because amortizing the cost of the equipment is not passed on to our project, 3D printing is highly cost effective for us. However, if the production entity has to have 3D printing done out of house, printed parts may be more economically produced with a different manufacturing process.  However, we think a review of the current CPF design with respect to decreasing production cost is worth our time. In particular we know the current pressure housing design is going to an expensive part even in production quantities. The current housing is a ring stiffened, anodized aluminum housing designed to minimize weight. It is by far the most expensive mechanical part in the CPF and also the heaviest even with the ring stiffened design. The current machining process for this housing requires a fair amount of custom fixturing.  While the cost of the fixturing can be amortized over production quantities, the time required to setup and dial in the fixturing for each housing cannot. The most viable approach we have for reducing the cost and weight of the CPF pressure housing is moving to carbon fiber. A first pass analysis suggest that a constant wall thickness carbon fiber housing would meet the design requirements and reduce the weight by XX%. Even though carbon fiber is significantly more expensive than aluminum on a per kg basis, the savings in machining and anodizing costs offset the increased raw material cost.  We are requesting funds to re-evaluate and redesign the current CPF pressure housing. 
 
A second key step in making the transition to production is the quality of the documentation package. Currently, the CPF mechanical and electrical documentation package (mechanical models, part drawings, assembly drawing, electrical schematics, wire harness assembly drawings, printed circuit board drawings, etc.) are in pretty good shape. However, more effort is required to ensure the documentation package is ready for production. Our assembly notes need to be turned into assembly procedures, inspection dimensions need to be identified on the mechanical drawings, our test notes need to be turned into formal test procedure documents and so on. Equally important, we need to write a user manual for the CPF. Again, these are time consuming and necessary but low risk tasks.  


      3. Transferring the CPF technology to the greater research community
As we’ve discussed, moving the CPF technology out of our research lab and into the greater community is a primary goal of this proposal.  Our chemical sensor lab has commercialized several technologies including the Seabird SeaFET Ocean pH sensor and the Satlantic SUNA (Submersible Ultraviolet Nitrate Analyzer). There are several strategies that could be used to transfer the CPF technology.  The right choice will be strongly driven by the needs of potential CPF users in the research community.  As part of this work we will assess these user needs with a survey conducted with a select group of our colleagues at academic and government research labs. This survey would be completed early in the project schedule in order to guide the subsequent work. And we expect to at least start the transfer process and depending on what transfer strategy makes sense, potentially complete the transfer process as part of the proposed work.




5. References Cited
1Benway, H., Alin, S., Boyer, E., Cai, W.-J., Coble, P., Cross, J., Friedrichs, M., Goñi, M., Griffith, P., Herrmann, M., Lohrenz, S., Mathis, J., McKinley, G., Najjar, R., Pilskaln, C., Siedlecki, S., Smith, R., 2016. A Science Plan for Carbon Cycle Research in North American Coastal Waters. Report of the Coastal CARbon Synthesis (CCARS) community workshop, August 19-21, 2014, Ocean Carbon and Biogeochemistry Program and North American Carbon Program, 84 pp., DOI 10.1575/1912/7777.
(Can’t use URLs)
2https://www.mrvsys.com/products/mrvs2a
3http://www.teledynemarine.com/apex-biogeochem?ProductLineID=61
4Bronselaer, B., Russell, J.L., Winton, M. et al. Importance of wind and meltwater for observed chemical and physical changes in the Southern Ocean. Nat. Geosci. 13, 35–42 (2020) doi:10.1038/s41561-019-0502-8
5https://www.misra.org.uk/MISRAHome/tabid/55/Default.aspx
6https://ti.arc.nasa.gov/tech/rse/
6. Biographical sketches
7. Budget and Budget Justification


The WBS and Schedule go here.


8. Current and Pending Support
Previous NSF Support
Ken: SOCCOM
PI Takeshita: Collaborative Research: Self-Calibrating pH sensors for Autonomous Collection of Climate Quality Data, NSF OCE-1736864, $107,817 to MBARI, 9/1/2017-8/31/2020. Intellectual merit: This project aims to develop an in situ self-calibrating pH sensor based on the Durafet technology capable of producing ‘climate quality’, defined as having uncertainty < 0.003. The pH sensor flow cell will be periodically injected with equimolar Tris buffer prepared in artificial seawater, the standard solution for pH in seawater. A prototype of the self-calibrating sensor is currently being tested in a test tank, flow cell design is being refined, and field deployments on the Scripps Pier is planned in the summer of 2019. Publications have been submitted, or currently in preparation. Broader impacts: Currently, the quality of data obtained from autonomous pH sensors is strongly tied to expertise and experience with the instruments and calibration using discrete samples. A self-calibrating feature will enable routine high quality measurements from non-expert users, dramatically enhancing the capability to collect climate-quality pH measurements around the world oceans to more accurately monitor changes in ocean pH. This award is currently supporting two doctoral students at Scripps Institution of Oceanography including one underrepresented woman and two early career researchers.


9. Facilities, Equipment and Other Resources
10. Special Information and Supplementary Documentation
   1. Data Management Plan
   2. Postdoctoral Mentoring Plan (if applicable)
11. Single Copy Documents
   1. Collaborators and Other Affiliations Information