901023 Continental Margins : Software This page last changed on Jul 24, 2013 by oreilly. ### 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 synchron ized 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 Tabl e 2: Instrument logging capacities
| internal log size | bytes per record | log download time | capacity @ 2 sec | capacity @ 10 sec | capacity @ 20 sec | capacity @ 30 sec | capacity @ 60 sec
SBE-16+ | 8 MB |  | 28 min @38400 baud | N.A. | N.A. | 183 days | 274 days | 547 days
Nortek Aquadopp | 81 MB * | 40 | 1.6 hrs @115200 baud | 47 days | 234 days | 468 days | 702 days | 1404 days
WETLabs Triplet | 1 MB | 20 | 7 min @19200 baud | 2.9 days | 5.8 days | 11.6 days | 17.4 days | 34.8 days
Aanderaa Optode | none |  | N.A. |  |  |  |  |
Teledyne Workhorse Sentinel | 440 ** |  | 8.5 hrs @115200 baud | 17 days? | 86 days? | 173 days | 260 days | 520 days
* 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
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 |
Attachments: jitter.png (image/png) Monterey_submitted.pdf (application/x-pdf) Comments:
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

Document generated by Confluence on Feb 03, 2026 15:47