Unconnected BIN: SIAM on SideARM

This option uses existing MOOS hardware and software (SideARM with DPAs). These components are approximately 10 years old, and there may be support issues.  

• j9 JVM is no longer distributed/supported, but we likely have archived copy
• Old kernel version; do we have adequate documentation?
• gnu cross-compiler toolchain available?
  

Unconnected BIN: SIAM on new controller

This option provides a modern supported processor platform, faster clock speed and lower power consumption than SideARM.

• Capable low-power ARM processors available; must adapt to DPA or provide alternative. Additional EE resource required.
• Oracle embedded JVM 

Cabled BIN: SIAM on shore

Real-time data retrieval to shore

• Minimal software development cost
• SIAM runs on capable shore workstation
  

Sampling rate and determinacy - "jitter"

During MOOS project sampling rate and determinacy limits were observed when multiple instruments are sampling. Sampling "jitter" was observed in sample intervals when  Aquadopp, WETLabs Triplet, and Aanderaa were sampled every 10 seconds, Seabird was sampled at 18 seconds, and Workhorse sampled every 1 minute (Figure 1, Table 1). Possible causes of this jitter include:

• Telemetry retrieval thread contending with sampling threads
• 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.  

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

Table 1: Summary of sampling statistics corresponding to Figure 1

                      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
 
 

Strategy A: improved scheduling algorithm

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.

Strategy B: internal instrument triggering and logging

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.

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. Note that it is very important that all instrument clocks be synchronized with each other, either in situ or after data recovery.From the project proposal:Total deployment time: 18 months = 1.5 years = 547 days. Servicing intervals at 6 months = 180 days

Desired sample interval: 2-30 sec

Table 2: Instrument logging capacities                                                                        

* May be expandable to 161 MB

** May be expandable to 4 GB

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

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

Event detection

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.

Instrument clock synchronization

It is critical to ensure that internal instrument clocks are synchronized within required accuracy.

Software tasks

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

Table 3: Software tasks

jitter.png (image/png)
Monterey_submitted.pdf (application/x-pdf)

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. Posted by oreilly at Jul 22, 2013 14:18

Esther notes instrument clock synchronization issues when data is logged internal to each instrument. Usually assume clock drift is linear. Posted by oreilly at Jul 22, 2013 14:20