<?xml version="1.0" encoding="UTF-8"?>
<hibernate-generic datetime="2026-02-03 15:48:03">
<object class="Space" package="com.atlassian.confluence.spaces">
<id name="id">21692417</id>
<property name="name"><![CDATA[901023 Continental Margins]]></property>
<property name="key"><![CDATA[CONMAR]]></property>
<property name="description" class="SpaceDescription" package="com.atlassian.confluence.spaces"><id name="id">21365490</id>
</property>
<property name="homePage" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365491</id>
</property>
<collection name="permissions"><element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659665</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659666</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659667</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659668</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659669</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659670</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659671</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659672</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659673</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659674</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659675</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659676</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659677</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659678</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659679</id>
</element>
<element class="SpacePermission" package="com.atlassian.confluence.security"><id name="id">21659680</id>
</element>
</collection>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.680</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.680</property>
<property name="spaceType">global</property>
</object>
<object class="ConfluenceBandanaRecord" package="com.atlassian.confluence.setup.bandana">
<id name="id">21725187</id>
<property name="context"><![CDATA[CONMAR]]></property>
<property name="key"><![CDATA[atlassian.confluence.space.settings]]></property>
<property name="value"><![CDATA[<com.atlassian.confluence.setup.settings.SpaceSettings>
  <spaceKey>CONMAR</spaceKey>
  <disableLogo>false</disableLogo>
  <colourSchemesSettings>
    <colourSchemeType>global</colourSchemeType>
  </colourSchemesSettings>
</com.atlassian.confluence.setup.settings.SpaceSettings>]]></property>
</object>
<object class="ConfluenceBandanaRecord" package="com.atlassian.confluence.setup.bandana">
<id name="id">21725186</id>
<property name="context"><![CDATA[CONMAR]]></property>
<property name="key"><![CDATA[atlassian.confluence.css.resource.counter]]></property>
<property name="value"><![CDATA[<int>2</int>]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365491</id>
<collection name="children"><element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</element>
</collection>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="title"><![CDATA[Home]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398213</id>
</element>
</collection>
<collection name="outgoingLinks"><element class="OutgoingLink" package="com.atlassian.confluence.links"><id name="id">21434166</id>
</element>
<element class="OutgoingLink" package="com.atlassian.confluence.links"><id name="id">21434167</id>
</element>
</collection>
<property name="version">4</property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 09:38:37.440</property>
<property name="versionComment"><![CDATA[]]></property>
<collection name="historicalVersions"><element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365501</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365586</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365587</id>
</element>
</collection>
<property name="contentStatus"><![CDATA[current]]></property>
<collection name="attachments"><element class="Attachment" package="com.atlassian.confluence.pages"><id name="id">21528620</id>
</element>
</collection>
</object>
<object class="ConfluenceBandanaRecord" package="com.atlassian.confluence.setup.bandana">
<id name="id">21725185</id>
<property name="context"><![CDATA[CONMAR]]></property>
<property name="key"><![CDATA[atlassian.confluence.theme.settings]]></property>
<property name="value"><![CDATA[<map>
  <entry>
    <string>theme.key</string>
    <string></string>
  </entry>
</map>]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365493</id>
<property name="parent" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365491</id>
</property>
<collection name="ancestors"><element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365491</id>
</element>
</collection>
<collection name="comments"><element class="Comment" package="com.atlassian.confluence.pages"><id name="id">21365551</id>
</element>
<element class="Comment" package="com.atlassian.confluence.pages"><id name="id">21365552</id>
</element>
</collection>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398215</id>
</element>
</collection>
<collection name="outgoingLinks"><element class="OutgoingLink" package="com.atlassian.confluence.links"><id name="id">21434189</id>
</element>
</collection>
<property name="version">34</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 15:23:45.423</property>
<property name="versionComment"><![CDATA[]]></property>
<collection name="historicalVersions"><element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365494</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365495</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365496</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365497</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365499</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365503</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365505</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365506</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365508</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365510</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365512</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365554</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365555</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365557</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365559</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365561</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365563</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365589</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365591</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365593</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365595</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365597</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365599</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365600</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365602</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365604</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365607</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365608</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365610</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365612</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365615</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365616</id>
</element>
<element class="Page" package="com.atlassian.confluence.pages"><id name="id">21365620</id>
</element>
</collection>
<property name="contentStatus"><![CDATA[current]]></property>
<collection name="attachments"><element class="Attachment" package="com.atlassian.confluence.pages"><id name="id">21528617</id>
</element>
<element class="Attachment" package="com.atlassian.confluence.pages"><id name="id">21528619</id>
</element>
</collection>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365563</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398283</id>
</element>
</collection>
<property name="version">17</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-23 09:10:40.337</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659665</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[VIEWSPACE]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.690</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.690</property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659666</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[COMMENT]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.690</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.690</property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659667</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[EDITSPACE]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.690</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.690</property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659668</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[SETSPACEPERMISSIONS]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.690</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.690</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365554</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398274</id>
</element>
</collection>
<property name="version">12</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 16:08:10.127</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365555</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398275</id>
</element>
</collection>
<property name="version">13</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-23 08:59:08.397</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365557</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398277</id>
</element>
</collection>
<property name="version">14</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-23 09:00:01.223</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365559</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398279</id>
</element>
</collection>
<property name="version">15</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-23 09:00:52.007</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365561</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398281</id>
</element>
</collection>
<property name="version">16</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-23 09:02:42.660</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365597</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398317</id>
</element>
</collection>
<property name="version">22</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 10:44:44.493</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365595</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398315</id>
</element>
</collection>
<property name="version">21</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 10:43:13.727</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659680</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[COMMENT]]></property>
<property name="group"><![CDATA[confluence-users]]></property>
<property name="userName"/><property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.700</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.700</property>
</object>
<object class="OutgoingLink" package="com.atlassian.confluence.links">
<id name="id">21434166</id>
<property name="destinationPageTitle"><![CDATA[]]></property>
<property name="destinationSpaceKey"><![CDATA[CONMAR]]></property>
<property name="sourceContent" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365491</id>
</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-24 09:38:37.453</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 09:38:37.453</property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659679</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[VIEWSPACE]]></property>
<property name="group"><![CDATA[confluence-users]]></property>
<property name="userName"/><property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.700</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.700</property>
</object>
<object class="OutgoingLink" package="com.atlassian.confluence.links">
<id name="id">21434167</id>
<property name="destinationPageTitle"><![CDATA[Software]]></property>
<property name="destinationSpaceKey"><![CDATA[CONMAR]]></property>
<property name="sourceContent" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365491</id>
</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-24 09:38:37.453</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 09:38:37.453</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365602</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398322</id>
</element>
</collection>
<property name="version">25</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 11:11:40.110</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659678</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[SETPAGEPERMISSIONS]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.693</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365599</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398319</id>
</element>
</collection>
<property name="version">23</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 10:50:16.197</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659677</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[REMOVEMAIL]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.693</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365600</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398320</id>
</element>
</collection>
<property name="version">24</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 11:02:12.667</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659676</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[EXPORTSPACE]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.693</property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659675</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[EXPORTPAGE]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.693</property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659674</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[EDITBLOG]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.693</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365604</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398324</id>
</element>
</collection>
<property name="version">26</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 11:12:40.213</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659673</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[REMOVEATTACHMENT]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.693</property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659672</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[CREATEATTACHMENT]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.693</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365610</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398330</id>
</element>
</collection>
<property name="version">29</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 11:26:09.023</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659671</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[REMOVEBLOG]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.693</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365607</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398327</id>
</element>
</collection>
<property name="version">27</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 11:15:36.297</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659670</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[REMOVECOMMENT]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.690</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.690</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365608</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398328</id>
</element>
</collection>
<property name="version">28</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 11:25:39.360</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="SpacePermission" package="com.atlassian.confluence.security">
<id name="id">21659669</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="type"><![CDATA[REMOVEPAGE]]></property>
<property name="group"/><property name="userName"><![CDATA[kgomes]]></property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.690</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.690</property>
</object>
<object class="SpaceDescription" package="com.atlassian.confluence.spaces">
<id name="id">21365490</id>
<property name="space" class="Space" package="com.atlassian.confluence.spaces"><id name="id">21692417</id>
</property>
<property name="title"/><collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398212</id>
</element>
</collection>
<property name="version">1</property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.643</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.643</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365586</id>
<property name="title"><![CDATA[Home]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398306</id>
</element>
</collection>
<property name="version">2</property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:23:46.667</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365491</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365589</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398309</id>
</element>
</collection>
<property name="version">18</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-23 09:12:31.593</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365587</id>
<property name="title"><![CDATA[Home]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398307</id>
</element>
</collection>
<property name="version">3</property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 09:37:14.947</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365491</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365593</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398313</id>
</element>
</collection>
<property name="version">20</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 10:34:54.573</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="OutgoingLink" package="com.atlassian.confluence.links">
<id name="id">21434189</id>
<property name="destinationPageTitle"><![CDATA[//www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]]></property>
<property name="destinationSpaceKey"><![CDATA[http]]></property>
<property name="sourceContent" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-24 15:23:45.560</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 15:23:45.560</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365591</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398311</id>
</element>
</collection>
<property name="version">19</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 10:11:44.517</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365503</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398225</id>
</element>
</collection>
<property name="version">6</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:22:52.450</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365505</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398227</id>
</element>
</collection>
<property name="version">7</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:24:45.400</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365506</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398228</id>
</element>
</collection>
<property name="version">8</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:26:27.373</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365499</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398221</id>
</element>
</collection>
<property name="version">5</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:22:07.337</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365501</id>
<property name="title"><![CDATA[Home]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398223</id>
</element>
</collection>
<property name="version">1</property>
<property name="creatorName"><![CDATA[kgomes]]></property>
<property name="creationDate">2013-07-16 14:38:43.693</property>
<property name="lastModifierName"><![CDATA[kgomes]]></property>
<property name="lastModificationDate">2013-07-16 14:38:43.693</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365491</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365512</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398234</id>
</element>
</collection>
<property name="version">11</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 16:01:04.177</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365508</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398230</id>
</element>
</collection>
<property name="version">9</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:27:15.007</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365510</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398232</id>
</element>
</collection>
<property name="version">10</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:48:05.657</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365620</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398340</id>
</element>
</collection>
<property name="version">33</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 11:38:45.730</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365496</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398218</id>
</element>
</collection>
<property name="version">3</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:21:08.803</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365615</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398335</id>
</element>
</collection>
<property name="version">31</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 11:33:33.510</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365495</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398217</id>
</element>
</collection>
<property name="version">2</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:19:35.997</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398213</id>
<property name="body"><![CDATA[This is the home page for the 901023 Continental Margins space.

[Proposal|^Monterey_submitted.pdf]&nbsp;

[Software|CONMAR:Software]\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365491</id>
</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365616</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398336</id>
</element>
</collection>
<property name="version">32</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 11:36:52.203</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365497</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398219</id>
</element>
</collection>
<property name="version">4</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:21:47.190</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365612</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398332</id>
</element>
</collection>
<property name="version">30</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 11:28:53.360</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
<id name="id">21365494</id>
<property name="title"><![CDATA[Software]]></property>
<collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398216</id>
</element>
</collection>
<property name="version">1</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:10.307</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:19:10.307</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="originalVersion" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398215</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter include:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color}&nbsp;

{color:000000}{*}Figure 1: Recorded instrument sampling intervals  showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry  retrieval contention with sampling.*{color}
!jitter.png!

*Table 1: Summary of sampling statistics corresponding to Figure 1*
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}\\

{color:000000}{*}Tabl{*}{color}{color:000000}{*}e 2: Instrument logging capacities{*}{color} {color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:{color}

{color:#0000ff}I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here;{color} {color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

Note that some of the problems described by Paul could be avoided by periodic synch of the instrument clocks with the MOOS BIN clock.

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

Several important details for this project have yet to be determined, and these influence the necessary software effort.&nbsp;

*Table 3: Software tasks*
|| ID \\ || Description || Est. time \\ || deployment scenario \\ || sampling type, internal, external \\ || additional notes \\ ||
| 1 | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment. \\ | 5 days \\ | cabled and acoustic \\ | both \\ | |
| 2 | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | 5 days \\ | cabled and acoustic \\ | both \\ | |
| 3 | Improve sampling determinacy \\ | 15 days \\ | cabled and acoustic \\ | external \\ | required only if jitter is unacceptable \\ |
| 4 | Coordinate acoustic instrument sampling \\ | 5 days \\ | cabled and acoustic \\ | both | required only if acoustic interference is a problem \\ |
| 5 | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | 5 days \\ | cabled and acoustic \\ | internal \\ | |
| 6 | Periodically resynch instrument clocks with MOOS clock \\ | 5 days \\ | cabled and acoustic \\ | internal | |
| 7 | Integrate acoustic modem \\ | 5 days \\ | acoustic | both | |
| 8 | Low-bandwidth health-status log for acoustic xmit \\ | 5 days \\ | acoustic \\ | both \\ | |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
</object>
<object class="Comment" package="com.atlassian.confluence.pages">
<id name="id">21365552</id>
<property name="page" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="title"/><collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398272</id>
</element>
</collection>
<property name="version">1</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-22 14:20:03.517</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-22 14:20:03.517</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Comment" package="com.atlassian.confluence.pages">
<id name="id">21365551</id>
<property name="page" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="title"/><collection name="bodyContents"><element class="BodyContent" package="com.atlassian.confluence.core"><id name="id">21398271</id>
</element>
</collection>
<property name="version">1</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-22 14:18:42.763</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-22 14:18:42.763</property>
<property name="versionComment"><![CDATA[]]></property>
<property name="contentStatus"><![CDATA[current]]></property>
</object>
<object class="Attachment" package="com.atlassian.confluence.pages">
<id name="id">21528617</id>
<property name="fileName"><![CDATA[jitter.png]]></property>
<property name="contentType"><![CDATA[image/png]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-16 15:19:53.507</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-16 15:19:53.507</property>
<property name="fileSize">27628</property>
<property name="comment"><![CDATA[]]></property>
<property name="attachmentVersion">1</property>
</object>
<object class="Attachment" package="com.atlassian.confluence.pages">
<id name="id">21528620</id>
<property name="fileName"><![CDATA[Monterey_submitted.pdf]]></property>
<property name="contentType"><![CDATA[application/x-pdf]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365491</id>
</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-24 09:38:01.650</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-24 09:38:01.650</property>
<property name="fileSize">878905</property>
<property name="comment"><![CDATA[Proposal text]]></property>
<property name="attachmentVersion">1</property>
</object>
<object class="Attachment" package="com.atlassian.confluence.pages">
<id name="id">21528619</id>
<property name="fileName"><![CDATA[Monterey_submitted.pdf]]></property>
<property name="contentType"><![CDATA[application/x-pdf]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365493</id>
</property>
<property name="creatorName"><![CDATA[oreilly]]></property>
<property name="creationDate">2013-07-23 15:49:05.800</property>
<property name="lastModifierName"><![CDATA[oreilly]]></property>
<property name="lastModificationDate">2013-07-23 15:49:05.800</property>
<property name="fileSize">878905</property>
<property name="comment"><![CDATA[]]></property>
<property name="attachmentVersion">1</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398279</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}

{color:000000}NOTE:{color} {color:000000}If instruments log internally, it is critical that all internal instrument clocks are synchronized to a common time base, within required accuracy.{color}\\

{color:000000}From the project proposal:{color}

{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy; sampling algorithm improvements.{color} {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}

{color:000000}2. Retrieve and store internal instrument logs.{color} {color:000000}If instrument logs internally, instrument log may fill up during deployment; need SIAM software to periodically retrieve internal instrument log, save to external storage, erase instrument log and restart internal logging.{color}

{color:000000}3. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

{color:000000}4. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365559</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398281</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. We believe strategy A (improved scheduling algorithm) is preferable to internal triggering and logging.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy; sampling algorithm improvements.{color} {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}

{color:000000}2. Retrieve and store internal instrument logs.{color} {color:000000}If instrument logs internally, instrument log may fill up during deployment; need SIAM software to periodically retrieve internal instrument log, save to external storage, erase instrument log and restart internal logging.{color}

{color:000000}3. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

{color:000000}4. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365561</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398275</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}


{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging


{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}

{color:000000}NOTE:{color} {color:000000}If instruments log internally, it is critical that all internal instrument clocks are synchronized to a common time base, within required accuracy.{color}\\

{color:000000}From the project proposal:{color}

{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:

I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.

Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.

If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.

One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:

http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf




h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy; sampling algorithm improvements.{color} {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}

{color:000000}2. Retrieve and store internal instrument logs.{color} {color:000000}If instrument logs internally, instrument log may fill up during deployment; need SIAM software to periodically retrieve internal instrument log, save to external storage, erase instrument log and restart internal logging.{color}

{color:000000}3. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

{color:000000}4. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365555</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398277</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}

{color:000000}NOTE:{color} {color:000000}If instruments log internally, it is critical that all internal instrument clocks are synchronized to a common time base, within required accuracy.{color}\\

{color:000000}From the project proposal:{color}

{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.

Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.

If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.

One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:

[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]
h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy; sampling algorithm improvements.{color} {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}

{color:000000}2. Retrieve and store internal instrument logs.{color} {color:000000}If instrument logs internally, instrument log may fill up during deployment; need SIAM software to periodically retrieve internal instrument log, save to external storage, erase instrument log and restart internal logging.{color}

{color:000000}3. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

{color:000000}4. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365557</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398283</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. We believe strategy A (improved scheduling algorithm) is preferable to internal triggering and logging.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy; sampling algorithm improvements.{color} Verify SIAM timestamp accuracy even in case of jitter. {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}{color:000000}2{color}{color:000000}. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}{*}Tasks for internal instrument logging only:*


{color:000000}1a{color}{color:000000}. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\

{color:000000}2a. Retrieve and store internal instrument logs.{color} {color:000000}If  instrument logs internally, instrument log may fill up during  deployment; need SIAM software to periodically retrieve internal  instrument log, save to external storage, erase instrument log and  restart internal logging.{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365563</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398306</id>
<property name="body"><![CDATA[This is the home page for the 901023 Continental Margins space.\\

[Software|CONMAR:Software]\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365586</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398313</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}
\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

|| || || deployment type: cabled, acoustic\\ || sampling type, internal, external\\ ||
| | Characterize sampling determinacy \\ | both\\ | both\\ |
| | | | |
| | Periodically resynch instrument clocks with MOOS clock\\ | both | internal |
| | | | |
| | Health and status via acoustic modem\\ | acoustic | both |
\\

{color:000000}1. Characterize sampling determinacy, with all seven science instruments running.{color} Verify SIAM timestamp accuracy even in case of jitter. {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally.{color}

{color:000000}2{color}{color:000000}. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

*Tasks for internal instrument logging only:*

{color:000000}1a{color}{color:000000}. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\

{color:000000}2a. Retrieve and store internal instrument logs.{color} {color:000000}If  instrument logs internally, instrument log may fill up during  deployment; need SIAM software to periodically retrieve internal  instrument log, save to external storage, erase instrument log and  restart internal logging.{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365593</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398311</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color} \\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy, with all seven science instruments running.{color} Verify SIAM timestamp accuracy even in case of jitter. {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally.{color}


{color:000000}2{color}{color:000000}. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

*Tasks for internal instrument logging only:*

{color:000000}1a{color}{color:000000}. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\

{color:000000}2a. Retrieve and store internal instrument logs.{color} {color:000000}If  instrument logs internally, instrument log may fill up during  deployment; need SIAM software to periodically retrieve internal  instrument log, save to external storage, erase instrument log and  restart internal logging.{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365591</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398309</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. We believe strategy A (improved scheduling algorithm) is preferable to internal triggering and logging.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy.{color} Verify SIAM timestamp accuracy even in case of jitter. {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}

{color:000000}2{color}{color:000000}. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

*Tasks for internal instrument logging only:*

{color:000000}1a{color}{color:000000}. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\

{color:000000}2a. Retrieve and store internal instrument logs.{color} {color:000000}If  instrument logs internally, instrument log may fill up during  deployment; need SIAM software to periodically retrieve internal  instrument log, save to external storage, erase instrument log and  restart internal logging.{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365589</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398307</id>
<property name="body"><![CDATA[This is the home page for the 901023 Continental Margins space.

Proposal&nbsp;


[Software|CONMAR:Software]\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365587</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398322</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

|| || || Est. time (days) \\ || deployment type: cabled, acoustic \\ || sampling type, internal, external \\ ||
| | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment. \\ | | both | both \\ |
| | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | | both \\ | both \\ |
| | Improve sampling determinacy \\ | | both \\ | external \\ |
| | Coordinate acoustic instrument sampling \\ | | both | both |
| | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | | both \\ | internal \\ |
| | Periodically resynch instrument clocks with MOOS clock \\ | | both | internal |
| | | | | |
| | Integrate acoustic modem \\ | | acoustic | both |
| | Low-bandwidth health-status log for acoustic xmit \\ | | acoustic \\ | both \\ |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365602</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398319</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

|| || || deployment type: cabled, acoustic \\ || sampling type, internal, external \\ ||
| | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | both \\ | both \\ |
| | Improve sampling determinacy\\ | both\\ | external\\ |
| | Coordinate acoustic instrument sampling \\ | both | both |
| | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory\\ | both\\ | internal\\ |
| | Periodically resynch instrument clocks with MOOS clock \\ | both | internal |
| | | | |
| | Integrate acoustic modem \\ | acoustic | both |
| | Low-bandwidth health-status log for acoustic xmit \\ | acoustic \\ | both \\ |
\\

{color:000000}1. Characterize sampling determinacy, with all seven science instruments running.{color} Verify SIAM timestamp accuracy even in case of jitter. {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally.{color}

{color:000000}2{color}{color:000000}. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

*Tasks for internal instrument logging only:*

{color:000000}1a{color}{color:000000}. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\

{color:000000}2a. Retrieve and store internal instrument logs.{color} {color:000000}If  instrument logs internally, instrument log may fill up during  deployment; need SIAM software to periodically retrieve internal  instrument log, save to external storage, erase instrument log and  restart internal logging.{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365599</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398320</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

|| || || Est. time (days) \\ || deployment type: cabled, acoustic \\ || sampling type, internal, external \\ ||
| | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment.\\ | | both | both\\ |
| | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | | both \\ | both \\ |
| | Improve sampling determinacy \\ | | both \\ | external \\ |
| | Coordinate acoustic instrument sampling \\ | | both | both |
| | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | | both \\ | internal \\ |
| | Periodically resynch instrument clocks with MOOS clock \\ | | both | internal |
| | | | | |
| | Integrate acoustic modem \\ | | acoustic | both |
| | Low-bandwidth health-status log for acoustic xmit \\ | | acoustic \\ | both \\ |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365600</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398317</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

|| || || deployment type: cabled, acoustic \\ || sampling type, internal, external \\ ||
| | Characterize sampling determinacy \\ | both \\ | both \\ |
| | Coordinate acoustic instrument sampling\\ | both | both |
| | Periodically resynch instrument clocks with MOOS clock \\ | both | internal |
| | | | |
| | Integrate acoustic modem \\ | acoustic | both |
| | Low-bandwidth health-status log for acoustic xmit \\ | acoustic \\ | both \\ |
\\

{color:000000}1. Characterize sampling determinacy, with all seven science instruments running.{color} Verify SIAM timestamp accuracy even in case of jitter. {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally.{color}

{color:000000}2{color}{color:000000}. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

*Tasks for internal instrument logging only:*

{color:000000}1a{color}{color:000000}. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\

{color:000000}2a. Retrieve and store internal instrument logs.{color} {color:000000}If  instrument logs internally, instrument log may fill up during  deployment; need SIAM software to periodically retrieve internal  instrument log, save to external storage, erase instrument log and  restart internal logging.{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365597</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398315</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

|| || || deployment type: cabled, acoustic \\ || sampling type, internal, external \\ ||
| | Characterize sampling determinacy \\ | both \\ | both \\ |
| | | | |
| | Periodically resynch instrument clocks with MOOS clock \\ | both | internal |
| | | | |
| | Integrate acoustic modem \\ | acoustic | both |
| | Low-bandwidth health-status log for acoustic xmit\\ | acoustic\\ | both\\ |
\\

{color:000000}1. Characterize sampling determinacy, with all seven science instruments running.{color} Verify SIAM timestamp accuracy even in case of jitter. {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally.{color}

{color:000000}2{color}{color:000000}. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

*Tasks for internal instrument logging only:*

{color:000000}1a{color}{color:000000}. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\

{color:000000}2a. Retrieve and store internal instrument logs.{color} {color:000000}If  instrument logs internally, instrument log may fill up during  deployment; need SIAM software to periodically retrieve internal  instrument log, save to external storage, erase instrument log and  restart internal logging.{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365595</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398330</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}\\
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}\\

{color:000000}Tabl{color}{color:000000}e 2: Instrument logging capacities{color} {color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

Several important details for this project have yet to be determined, and these influence the necessary software effort.&nbsp;

Table 3: Software tasks
|| ID \\ || Description || Est. time (days) \\ || deployment type: cabled, acoustic \\ || sampling type, internal, external \\ || additional notes \\ ||
| 1 | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment. \\ | | both | both \\ | |
| 2 | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | | both \\ | both \\ | |
| 3 | Improve sampling determinacy \\ | | both \\ | external \\ | required only if jitter is unacceptable \\ |
| 4 | Coordinate acoustic instrument sampling \\ | | both | both | required only if acoustic interference is a problem \\ |
| 5 | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | | both \\ | internal \\ | |
| 6 | Periodically resynch instrument clocks with MOOS clock \\ | | both | internal | |
| 7 | Integrate acoustic modem \\ | | acoustic | both | |
| 8 | Low-bandwidth health-status log for acoustic xmit \\ | | acoustic \\ | both \\ | |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365610</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398328</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}\\
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}\\

{color:000000}Tabl{color}{color:000000}e 2: Instrument logging capacities{color} {color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

Several important details for this project have yet to be determined, and these influence the necessary software effort.&nbsp;

Table 3: Software tasks
|| ID \\ || || Est. time (days) \\ || deployment type: cabled, acoustic \\ || sampling type, internal, external \\ || additional notes\\ ||
| 1 | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment. \\ | | both | both \\ | |
| 2 | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | | both \\ | both \\ | |
| 3 | Improve sampling determinacy \\ | | both \\ | external \\ | required only if jitter is unacceptable \\ |
| 4 | Coordinate acoustic instrument sampling \\ | | both | both | required only if acoustic interference is a problem\\ |
| 5 | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | | both \\ | internal \\ | |
| 6 | Periodically resynch instrument clocks with MOOS clock \\ | | both | internal | |
| 7 | Integrate acoustic modem \\ | | acoustic | both | |
| 8 | Low-bandwidth health-status log for acoustic xmit \\ | | acoustic \\ | both \\ | |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365608</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398327</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}\\
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}\\

{color:000000}Tabl{color}{color:000000}e 2: Instrument logging capacities{color} {color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}

| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

Several important details for this project have yet to be determined, and these influence the necessary software effort.&nbsp;

Table 3: Software tasks

|| ID \\ || || Est. time (days) \\ || deployment type: cabled, acoustic \\ || sampling type, internal, external \\ ||
| 1 | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment. \\ | | both | both \\ |
| 2 | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | | both \\ | both \\ |
| 3 | Improve sampling determinacy \\ | | both \\ | external \\ |
| 4 | Coordinate acoustic instrument sampling \\ | | both | both |
| 5 | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | | both \\ | internal \\ |
| 6 | Periodically resynch instrument clocks with MOOS clock \\ | | both | internal |
| 7 | Integrate acoustic modem \\ | | acoustic | both |
| 8 | Low-bandwidth health-status log for acoustic xmit \\ | | acoustic \\ | both \\ |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365607</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398324</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

|| ID\\ || || Est. time (days) \\ || deployment type: cabled, acoustic \\ || sampling type, internal, external \\ ||
| 1 | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment. \\ | | both | both \\ |
| 2 | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | | both \\ | both \\ |
| 3 | Improve sampling determinacy \\ | | both \\ | external \\ |
| 4 | Coordinate acoustic instrument sampling \\ | | both | both |
| 5 | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | | both \\ | internal \\ |
| 6 | Periodically resynch instrument clocks with MOOS clock \\ | | both | internal |
| 7 | Integrate acoustic modem \\ | | acoustic | both |
| 8 | Low-bandwidth health-status log for acoustic xmit \\ | | acoustic \\ | both \\ |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365604</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398336</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter include:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color}&nbsp;

{color:000000}{*}Figure 1: Recorded instrument sampling intervals  showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry  retrieval contention with sampling.*{color}
!jitter.png!

*Table 1: Summary of sampling statistics corresponding to Figure 1*
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}\\

{color:000000}Tabl{color}{color:000000}e 2: Instrument logging capacities{color} {color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:{color}

{color:#0000ff}I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

Note that some of the problems described by Paul could be avoided by periodic synch of the instrument clocks with the MOOS BIN clock.

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

Several important details for this project have yet to be determined, and these influence the necessary software effort.&nbsp;

Table 3: Software tasks
|| ID \\ || Description || Est. time \\ || deployment scenario \\ || sampling type, internal, external \\ || additional notes \\ ||
| 1 | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment. \\ | 5 days \\ | cabled and acoustic \\ | both \\ | |
| 2 | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | 5 days \\ | cabled and acoustic \\ | both \\ | |
| 3 | Improve sampling determinacy \\ | 15 days \\ | cabled and acoustic \\ | external \\ | required only if jitter is unacceptable \\ |
| 4 | Coordinate acoustic instrument sampling \\ | 5 days \\ | cabled and acoustic \\ | both | required only if acoustic interference is a problem \\ |
| 5 | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | 5 days \\ | cabled and acoustic \\ | internal \\ | |
| 6 | Periodically resynch instrument clocks with MOOS clock \\ | 5 days \\ | cabled and acoustic \\ | internal | |
| 7 | Integrate acoustic modem \\ | 5 days \\ | acoustic | both | |
| 8 | Low-bandwidth health-status log for acoustic xmit \\ | 5 days \\ | acoustic \\ | both \\ | |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365616</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398335</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}\\
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}\\

{color:000000}Tabl{color}{color:000000}e 2: Instrument logging capacities{color} {color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:{color}

{color:#0000ff}I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

Note that some of the problems described by Paul could be avoided by periodic synch of the instrument clocks with the MOOS BIN clock.


h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

Several important details for this project have yet to be determined, and these influence the necessary software effort.&nbsp;

Table 3: Software tasks
|| ID \\ || Description || Est. time \\ || deployment scenario \\ || sampling type, internal, external \\ || additional notes \\ ||
| 1 | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment. \\ | 5 days \\ | cabled and acoustic \\ | both \\ | |
| 2 | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | 5 days \\ | cabled and acoustic \\ | both \\ | |
| 3 | Improve sampling determinacy \\ | 15 days \\ | cabled and acoustic \\ | external \\ | required only if jitter is unacceptable \\ |
| 4 | Coordinate acoustic instrument sampling \\ | 5 days \\ | cabled and acoustic \\ | both | required only if acoustic interference is a problem \\ |
| 5 | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | 5 days \\ | cabled and acoustic \\ | internal \\ | |
| 6 | Periodically resynch instrument clocks with MOOS clock \\ | 5 days \\ | cabled and acoustic \\ | internal | |
| 7 | Integrate acoustic modem \\ | 5 days \\ | acoustic | both | |
| 8 | Low-bandwidth health-status log for acoustic xmit \\ | 5 days \\ | acoustic \\ | both \\ | |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365615</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398332</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}\\
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}\\

{color:000000}Tabl{color}{color:000000}e 2: Instrument logging capacities{color} {color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

Several important details for this project have yet to be determined, and these influence the necessary software effort.&nbsp;

Table 3: Software tasks
|| ID \\ || Description || Est. time \\ || deployment scenario \\ || sampling type, internal, external \\ || additional notes \\ ||
| 1 | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment. \\ | 5 days\\ | cabled and acoustic\\ | both \\ | |
| 2 | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | 5 days\\ | cabled and acoustic \\ | both \\ | |
| 3 | Improve sampling determinacy \\ | 15 days\\ | cabled and acoustic \\ | external \\ | required only if jitter is unacceptable \\ |
| 4 | Coordinate acoustic instrument sampling \\ | 5 days\\ | cabled and acoustic\\ | both | required only if acoustic interference is a problem \\ |
| 5 | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | 5 days\\ | cabled and acoustic \\ | internal \\ | |
| 6 | Periodically resynch instrument clocks with MOOS clock \\ | 5 days\\ | cabled and acoustic\\ | internal | |
| 7 | Integrate acoustic modem \\ | 5 days \\ | acoustic | both | |
| 8 | Low-bandwidth health-status log for acoustic xmit \\ | 5 days\\ | acoustic \\ | both \\ | |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365612</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398340</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter include:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color}&nbsp;

{color:000000}{*}Figure 1: Recorded instrument sampling intervals  showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry  retrieval contention with sampling.*{color}
!jitter.png!

*Table 1: Summary of sampling statistics corresponding to Figure 1*
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
\\

h4.


h5. {color:000000}Strategy A: improved scheduling algorithm{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

h5. Strategy B: internal instrument triggering and logging

{color:#0000ff}NOTE: If instruments  log internally, it is critical that all internal instrument clocks are  synchronized to a common time base, within required accuracy. It may be desirable to automate periodic synchronization of each instrument clock with the MOOS node clock.{color}\\

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}{color:000000}From the project proposal:{color}{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}\\

{color:000000}{*}Tabl{*}{color}{color:000000}{*}e 2: Instrument logging capacities{*}{color} {color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}\\

{color:#0000ff}UPDATE: Paul McGill has extensive clock conditioning/correction experience in context of seafloor seismometers, and writes this:{color}

{color:#0000ff}I would advise you to not allow each instrument to keep time  independently if you want the data samples from multiple sensors to be  synchronous. You might think that you could set each clock accurately  just before deployment and then measure the drift immediately after  recovery to correct the time stamps for each instrument. In practice,  it's just not that easy.{color}{color:#0000ff}Each clock's oscillator will have its own initial frequency error,  frequency drift rate, and aging rate (i.e. drift of the drift rate). You  can't even assume that each clock's error will monotonically increase  or decrease over time. Even with a zero aging rate (which you seldom see  in practice), a fixed frequency offset gives you a parabolically  increasing time error, so it gets bad fast and you can't correct it with  a simple two-point, before-and-after linear time correction. Three  seconds in a year is roughly 100 parts per billion, while the  inexpensive crystals used in typical ocean instruments is measured in  tens of parts per million (i.e. orders of magnitude worse). This makes  it difficult to remove the error post-recovery.{color}{color:#0000ff}If you can afford it, you should trigger each instrument from a common  source (e.g. SIAM) keeping time from a single decent clock. That single  clock doesn't even have to be super-accurate, since it's probably more  scientifically important to know that all the data channels are  synchronous than it is to know the absolute time that an event occurred.  Of course if you're trying to synchronize data from multiple BINs then  every clock needs to be pretty accurate.{color}{color:#0000ff}One of the best documents I've ever read on this subject is an HP  application note, "The Science of Timekeeping," available here:{color}{color:#0000ff}[http://www.allanstime.com/Publications/DWA/Science_Timekeeping/TheScienceOfTimekeeping.pdf]{color}

Note that some of the problems described by Paul could be avoided by periodic synch of the instrument clocks with the MOOS BIN clock.

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

Several important details for this project have yet to be determined, and these influence the necessary software effort.&nbsp;

*Table 3: Software tasks*
|| ID \\ || Description || Est. time \\ || deployment scenario \\ || sampling type, internal, external \\ || additional notes \\ ||
| 1 | Set up and configure BIN testbed in lab. Testbed is used prior and during deployment. \\ | 5 days \\ | cabled and acoustic \\ | both \\ | |
| 2 | Characterize sampling determinacy. Verify SIAM timestamp accuracy even in case of jitter. | 5 days \\ | cabled and acoustic \\ | both \\ | |
| 3 | Improve sampling determinacy \\ | 15 days \\ | cabled and acoustic \\ | external \\ | required only if jitter is unacceptable \\ |
| 4 | Coordinate acoustic instrument sampling \\ | 5 days \\ | cabled and acoustic \\ | both | required only if acoustic interference is a problem \\ |
| 5 | Periodically retrieve internal instrument logs and store on BIN, clear instrument log memory \\ | 5 days \\ | cabled and acoustic \\ | internal \\ | |
| 6 | Periodically resynch instrument clocks with MOOS clock \\ | 5 days \\ | cabled and acoustic \\ | internal | |
| 7 | Integrate acoustic modem \\ | 5 days \\ | acoustic | both | |
| 8 | Low-bandwidth health-status log for acoustic xmit \\ | 5 days \\ | acoustic \\ | both \\ | |
\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365620</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398230</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when &nbsp;Seabird CTD, WETLabs Triplet, and Aanderaa were sampled at 1 Hz in "polled" mode. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}

{color:000000}Strategies{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color}

{color:000000}NOTE:{color} {color:000000}If instruments log internally, it is critical that all internal instrument clocks are synchronized to a common time base, within required accuracy.{color}\\

{color:000000}From the project proposal:{color}

{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy; sampling algorithm improvements.{color}

{color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}

{color:000000}2. Retrieve and store internal instrument logs.{color}

{color:000000}If instrument logs internally, instrument log may fill up during deployment; need SIAM software to periodically retrieve internal instrument log, save to external storage, erase instrument log and restart internal logging.{color}

{color:000000}3. Health and status via acoustic modem.{color}

{color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

{color:000000}4. Implement clock synchronization for each instrument{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365508</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398227</id>
<property name="body"><![CDATA[h2. {color:000000}{*}Options{*}{color}


h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when &nbsp;Seabird CTD, WETLabs Triplet, and Aanderaa were sampled at 1 Hz in "polled" mode. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}{*}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.*{color}

{color:000000}Strategies{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color}

{color:000000}NOTE:{color} {color:000000}If instruments log internally, it is critical that all internal instrument clocks are synchronized to a common time base, within required accuracy.{color}\\

{color:000000}*&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;*{color}

| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365505</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398228</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when &nbsp;Seabird CTD, WETLabs Triplet, and Aanderaa were sampled at 1 Hz in "polled" mode. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}{*}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.*{color}

{color:000000}Strategies{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color}

{color:000000}NOTE:{color} {color:000000}If instruments log internally, it is critical that all internal instrument clocks are synchronized to a common time base, within required accuracy.{color}\\

{color:000000}{*}From the project proposal:*{color}

{color:000000}{*}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{*}{color}

{color:000000}{*}Desired sample interval: 2-30 sec{*}{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}*\* May be expandable to 161 MB{*}{color}

{color:000000}*\*\* May be expandable to 4 GB{*}{color}




h3. {color:666666}{*}Event detection{*}{color}

{color:000000}{*}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.*{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}




h3. {color:666666}Software tasks{color}


{color:000000}1. Characterize sampling determinacy; sampling algorithm improvements.{color}

{color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}

{color:000000}2. Retrieve and store internal instrument logs.{color}

{color:000000}If instrument logs internally, instrument log may fill up during deployment; need SIAM software to periodically retrieve internal instrument log, save to external storage, erase instrument log and restart internal logging.{color}

{color:000000}3. Health and status via acoustic modem.{color}

{color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

{color:000000}4. Implement clock synchronization for each instrument{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365506</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398234</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1\\

{color:000000}An{color}{color:000000}ti-jitter s{color}{color:000000}trategies{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color}

{color:000000}NOTE:{color} {color:000000}If instruments log internally, it is critical that all internal instrument clocks are synchronized to a common time base, within required accuracy.{color}\\

{color:000000}From the project proposal:{color}

{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy; sampling algorithm improvements.{color} {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}

{color:000000}2. Retrieve and store internal instrument logs.{color} {color:000000}If instrument logs internally, instrument log may fill up during deployment; need SIAM software to periodically retrieve internal instrument log, save to external storage, erase instrument log and restart internal logging.{color}

{color:000000}3. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

{color:000000}4. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365512</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398232</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when &nbsp;Seabird CTD, WETLabs Triplet, and Aanderaa were sampled at 1 Hz in "polled" mode. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}

{color:000000}Strategies{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color}

{color:000000}NOTE:{color} {color:000000}If instruments log internally, it is critical that all internal instrument clocks are synchronized to a common time base, within required accuracy.{color}\\

{color:000000}From the project proposal:{color}

{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy; sampling algorithm improvements.{color} {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}

{color:000000}2. Retrieve and store internal instrument logs.{color} {color:000000}If instrument logs internally, instrument log may fill up during deployment; need SIAM software to periodically retrieve internal instrument log, save to external storage, erase instrument log and restart internal logging.{color}

{color:000000}3. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

{color:000000}4. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365510</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398221</id>
<property name="body"><![CDATA[h2. {color:000000}{*}Options{*}{color}


h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when &nbsp;Seabird CTD, WETLabs Triplet, and Aanderaa were sampled at 1 Hz in "polled" mode. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365499</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398219</id>
<property name="body"><![CDATA[h2. {color:000000}{*}Options{*}{color}


h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}
{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}
{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}
{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy{*}{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when &nbsp;Seabird CTD, WETLabs Triplet, and Aanderaa were sampled at 1 Hz in "polled" mode. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365497</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398225</id>
<property name="body"><![CDATA[h2. {color:000000}{*}Options{*}{color}


h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when &nbsp;Seabird CTD, WETLabs Triplet, and Aanderaa were sampled at 1 Hz in "polled" mode. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}{*}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.*{color}


{color:000000}Strategies{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color}

{color:000000}NOTE:{color} {color:000000}If instruments log internally, it is critical that all internal instrument clocks are synchronized to a common time base, within required accuracy.{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365503</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398223</id>
<property name="body"><![CDATA[This is the home page for the 901023 Continental Margins space.]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365501</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398212</id>
<property name="body"><![CDATA[]]></property>
<property name="content" class="SpaceDescription" package="com.atlassian.confluence.spaces"><id name="id">21365490</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398218</id>
<property name="body"><![CDATA[h2. {color:000000}{*}Options{*}{color}


h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}{*}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;*{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}{*}Science data retrieved at 6-month intervals.*{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy{*}{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when &nbsp;Seabird CTD, WETLabs Triplet, and Aanderaa were sampled at 1 Hz in "polled" mode. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365496</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398217</id>
<property name="body"><![CDATA[h2. {color:000000}{*}Options{*}{color}


h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}{*}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;*{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}{*}Science data retrieved at 6-month intervals.*{color}

{color:000000}{*}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.*{color}
* {color:000000}{*}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.*{color}
* {color:000000}{*}Oracle embedded JVM&nbsp;*{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}{*}Real-time data retrieval to shore{*}{color}
* {color:000000}{*}Minimal software development cost{*}{color}
* {color:000000}{*}SIAM runs on capable shore workstation{*}{color}

*&nbsp;*

h3. {color:666666}{*}Sampling rate and determinacy{*}{color}

{color:000000}{*}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when &nbsp;Seabird CTD, WETLabs Triplet, and Aanderaa were sampled at 1 Hz in "polled" mode. Possible causes of this jitter:*{color}
* {color:000000}{*}Telemetry retrieval thread contending with sampling threads{*}{color}
* {color:000000}{*}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;*{color}]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365495</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398216</id>
<property name="body"><![CDATA[h2. {color:000000}{*}Options{*}{color}


h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}{*}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;*{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}{*}Science data retrieved at 6-month intervals.*{color}

{color:000000}{*}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.*{color}
* {color:000000}{*}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.*{color}
* {color:000000}{*}Oracle embedded JVM&nbsp;*{color}


h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}{*}Real-time data retrieval to shore{*}{color}
* {color:000000}{*}Minimal software development cost{*}{color}
* {color:000000}{*}SIAM runs on capable shore workstation{*}{color}

*&nbsp;*

h3. {color:666666}{*}Sampling rate and determinacy{*}{color}

{color:000000}{*}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when &nbsp;Seabird CTD, WETLabs Triplet, and Aanderaa were sampled at 1 Hz in "polled" mode. Possible causes of this jitter:*{color}
* {color:000000}{*}Telemetry retrieval thread contending with sampling threads{*}{color}
* {color:000000}{*}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;*{color} ]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365494</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398271</id>
<property name="body"><![CDATA[Per our meeting on 7/16, Charlie believes that level of jitter presented in the figure is not ideal, but is acceptable provided that we can determine at what time each sample was acquired.\\]]></property>
<property name="content" class="Comment" package="com.atlassian.confluence.pages"><id name="id">21365551</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398272</id>
<property name="body"><![CDATA[Esther notes instrument clock synchronization issues when data is logged internal to each instrument. Usually assume clock drift is linear.]]></property>
<property name="content" class="Comment" package="com.atlassian.confluence.pages"><id name="id">21365552</id>
</property>
</object>
<object class="BodyContent" package="com.atlassian.confluence.core">
<id name="id">21398274</id>
<property name="body"><![CDATA[h3. {color:666666}{*}Unconnected BIN: SIAM on SideARM{*}{color}

{color:000000}This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues. &nbsp;{color}
* {color:000000}j9 JVM is no longer distributed/supported, but we likely have archived copy{color}
* {color:000000}Old kernel version; do we have adequate documentation?{color}
* {color:000000}gnu cross-compiler toolchain available?{color}\\

h3. {color:666666}{*}Unconnected BIN: SIAM on new controller{*}{color}

{color:000000}This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.{color}
* {color:000000}Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.{color}
* {color:000000}Oracle embedded JVM&nbsp;{color}

h3. {color:666666}{*}Cabled BIN: SIAM on shore{*}{color}

{color:000000}Real-time data retrieval to shore{color}
* {color:000000}Minimal software development cost{color}
* {color:000000}SIAM runs on capable shore workstation{color}\\

h3. {color:666666}{*}Sampling rate and determinacy - "jitter"*{color}

{color:000000}During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when&nbsp;{color} {color:000000}Aquadopp,{color} {color:000000}WETLabs Triplet, and Aanderaa were sampled{color} {color:000000}every 10 seconds, Seabird{color} {color:000000}was sampled at 18 seconds, and Workhorse sampled{color} {color:000000}every 1 minute{color} {color:000000}(Figure 1, Table 1){color}{color:000000}. Possible causes of this jitter:{color}
* {color:000000}Telemetry retrieval thread contending with sampling threads{color}
* {color:000000}Inefficient scheduler design - currently each instrument service creates its own sampler and timer, and sampling is uncoordinated between multiple instruments. Better approach is to allocate just one sampling thread and one timer, which would be used by all polled instruments.&nbsp;{color} !jitter.png!

{color:000000}Figure 1: Recorded instrument sampling intervals showing "jitter" on MOOS BIN. "Telemetry thread" indicates telemetry retrieval contention with sampling.{color}
{noformat}
                      Scheduled    Actual mean       #samples
                      interval     interval, sigma
 
Aanderaa                10         10.0, 0.7          6801
Aquadopp                10         10.0, 1.1          6562
Seabird                 18         18.0, 0.9          3710
WETLabs                 10         10.0, 0.8          6825
Workhorse               60         60.0, 2.3          1099
 
 
{noformat}
Table 1: Summary of sampling statistics corresponding to Figure 1
\\

h4.


h5. {color:000000}An{color}{color:000000}ti-jitter s{color}{color:000000}trategies{color}

{color:000000}SIAM could implement a more deterministic architecture that samples each instrument in series (i.e. just one sampling thread that takes care of multiple instruments, one instrument at a time). Note that in this case the minimum possible sample interval would be equal to the \*sum\* of all instrument minimum sampling intervals. Suppose the minimum sampling intervals for instruments A, B, and C are 10 seconds each. Then the fastest possible sampling interval for all of those instruments is 30 seconds in a single-threaded system.{color}

{color:000000}Alternatively, some instruments can be configured to sample and log internally. Sampling by these instruments does not utilize the SIAM cpu, and is likely to be very deterministic. The internal storage of the instrument is of course finite, and sampling schedules must be specified accordingly. Note that SIAM could periodically retrieve the instrument's stored data, log it on the BIN and erase the instrument's storage. Sampling of the instrument would be paused during this operation; retrieval schedules could be "staggered" to minimize the likelihood that an event would be missed by all instruments.{color} {color:000000}Note that it is very important that{color} {color:000000}all instrument clocks be synchron{color}{color:000000}ized with each other, either in situ or after data recovery.{color}


{color:000000}NOTE:{color} {color:000000}If instruments log internally, it is critical that all internal instrument clocks are synchronized to a common time base, within required accuracy.{color}\\

{color:000000}From the project proposal:{color}

{color:000000}Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days{color}

{color:000000}Desired sample interval: 2-30 sec{color}

{color:000000}&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{color}
| \\ | {color:000000}internal log size{color} | {color:000000}bytes per record{color} | {color:000000}log download time{color} | {color:000000}capacity @ 2 sec{color} | {color:000000}capacity @ 10 sec{color} | {color:000000}capacity @ 20 sec{color} | {color:000000}capacity @ 30 sec{color} | {color:000000}capacity @ 60 sec{color} |
| {color:000000}SBE-16\+{color} | {color:000000}8 MB{color} | \\ | {color:000000}28 min @38400 baud{color} | {color:000000}N.A.{color} | {color:000000}N.A.{color} | {color:000000}183 days{color} | {color:000000}274 days{color} | {color:000000}547 days{color} |
| {color:000000}Nortek Aquadopp{color} | {color:000000}81 MB *{color} | {color:000000}40{color} | {color:ff0000}1.6 hrs @115200 baud{color} | {color:000000}47 days{color} | {color:000000}234 days{color} | {color:000000}468 days{color} | {color:000000}702 days{color} | {color:000000}1404 days{color} |
| {color:000000}WETLabs Triplet{color} | {color:000000}1 MB{color} | {color:000000}20{color} | {color:000000}7 min @19200 baud{color} | {color:000000}2.9 days{color} | {color:000000}5.8 days{color} | {color:000000}11.6 days{color} | {color:000000}17.4 days{color} | {color:000000}34.8 days{color} |
| {color:000000}Aanderaa Optode{color} | {color:000000}none{color} | \\ | {color:000000}N.A.{color} | \\ | \\ | \\ | \\ | \\ |
| Teledyne Workhorse Sentinel | {color:000000}440 \*\*{color} | \\ | {color:ff0000}8.5 hrs @115200 baud{color} | {color:000000}17 days?{color} | {color:000000}86 days?{color} | {color:000000}173 days{color} | {color:000000}260 days{color} | {color:000000}520 days{color} |
{color:000000}\* May be expandable to 161 MB{color}

{color:000000}\*\* May be expandable to 4 GB{color}

h3. {color:666666}{*}Event detection{*}{color}

{color:000000}We could run the STA/LTA event detector on the SBE turbidity sensor, and log detected events to the status log that will be acoustically retrieved.{color}

h3. {color:666666}Instrument clock synchronization{color}

{color:000000}It is critical to ensure that internal instrument clocks are synchronized within required accuracy.{color}

h3. {color:666666}Software tasks{color}

{color:000000}1. Characterize sampling determinacy; sampling algorithm improvements.{color} {color:000000}Characterize/improve SIAM controller cpu contention if instrument sampling is triggered and logged externally. In the case of cable-to-shore BIN, need to run tests with all 7 science instruments running at nominal rates.{color}

{color:000000}2. Retrieve and store internal instrument logs.{color} {color:000000}If instrument logs internally, instrument log may fill up during deployment; need SIAM software to periodically retrieve internal instrument log, save to external storage, erase instrument log and restart internal logging.{color}

{color:000000}3. Health and status via acoustic modem.{color} {color:000000}Software to generate low-bandwidth health/status logs. Acoustic modem driver{color}

{color:000000}4. Implement clock synchronization method for each instrument. We may want to periodically sync instrument clock with BIN clock{color}\\]]></property>
<property name="content" class="Page" package="com.atlassian.confluence.pages"><id name="id">21365554</id>
</property>
</object>
<object class="BucketPropertySetItem" package="bucket.user.propertyset">
<composite-id><property name="entityName"><![CDATA[confluence_ContentEntityObject]]></property>
<property name="entityId">21365493</property>
<property name="key"><![CDATA[socialbookmarkingurl]]></property>
</composite-id>
<property name="type">6</property>
<property name="booleanVal">false</property>
<property name="doubleVal">0.0</property>
<property name="stringVal"/><property name="textVal"><![CDATA[]]></property>
<property name="longVal">0</property>
<property name="intVal">0</property>
<property name="dateVal"/></object>
<object class="BucketPropertySetItem" package="bucket.user.propertyset">
<composite-id><property name="entityName"><![CDATA[confluence_ContentEntityObject]]></property>
<property name="entityId">21365493</property>
<property name="key"><![CDATA[isbookmark]]></property>
</composite-id>
<property name="type">5</property>
<property name="booleanVal">false</property>
<property name="doubleVal">0.0</property>
<property name="stringVal"/><property name="textVal"><![CDATA[]]></property>
<property name="longVal">0</property>
<property name="intVal">0</property>
<property name="dateVal"/></object>
<object class="BucketPropertySetItem" package="bucket.user.propertyset">
<composite-id><property name="entityName"><![CDATA[confluence_ContentEntityObject]]></property>
<property name="entityId">21365491</property>
<property name="key"><![CDATA[socialbookmarkingurl]]></property>
</composite-id>
<property name="type">6</property>
<property name="booleanVal">false</property>
<property name="doubleVal">0.0</property>
<property name="stringVal"/><property name="textVal"><![CDATA[]]></property>
<property name="longVal">0</property>
<property name="intVal">0</property>
<property name="dateVal"/></object>
<object class="BucketPropertySetItem" package="bucket.user.propertyset">
<composite-id><property name="entityName"><![CDATA[confluence_ContentEntityObject]]></property>
<property name="entityId">21365491</property>
<property name="key"><![CDATA[isbookmark]]></property>
</composite-id>
<property name="type">5</property>
<property name="booleanVal">false</property>
<property name="doubleVal">0.0</property>
<property name="stringVal"/><property name="textVal"><![CDATA[]]></property>
<property name="longVal">0</property>
<property name="intVal">0</property>
<property name="dateVal"/></object>
</hibernate-generic>