Relevant notes from the Argo Technical Workshop held September 10-13 in Seattle, WA
Discussion surrounding the technical details of standardizing the Argo mission, including cycle timing (not equal exactly 10 days) and park depth sampling (hourly T/P, 6-hour S). More experienced user groups will still set up their floats as they see fit. The goal is not to control how these type of groups program their floats, but to ensure smaller users that may not change the floats from their default configuration have an Argo mission compliant setup.
Also, Argo Canada’s sampling is not very typical of the array - we chose a setup that maximized the number of 1 dbar bins within our Iridium plan. 2 dbar bins throughout the water column is more common (CSIRO, Ifremer) or at least to 1000 dbar (UW), with 1 dbar bins only at the very surface. Our current setup returns just under 675 points (18-22 sbd messages, ~6kB). Moving to 1/2/10 with 20/1000 depth thresholds would result in 610 points. Our current park sample strategy is the NKE default, 12 hours, with some exceptions (Dal PROVORs sampling hourly).
Connecting with TWR staff was a helpful part of the week including getting some hands on experience with APEX floats. Pre-deployment testing will be similar, though there are some differences in deployment. General notes:
An emphasis on dockside testing was made, to (1) ensure problems do not arise in transport to a ship and (2) this also minimizes startup time as the GPS almanac will update. Typically we have testing within 1-2 months of a float going on a ship, but I would like to move that up to at least test the week of.
Strong recommendation to share raw data with float manufacturers so that they have access to the engineering data when helping address issues. Easy with SBD (add manufacturer email address to distribution list) but slightly more complicated with RUDICS. Will work with TWR to ensure they have access to RUDICS data (mirror on their server perhaps?). Does NKE already have access to the general RUDICS server? Do we need to revoke that?
Dalhousie is purchasing a PROVOR CTS5 that will be equipped with an RBR Tridente sensor instead of the SBS FLBB sensor. Data format coming from the float should be very similar, maybe different naming structure, but also may be differences in QC, processing, etc. Something to keep in mind.
Talked with Noe about deployments near ice - they will often let the float start its mission on deck (start to try to sink) in order to have the float sink faster and therefore reduce chance of hitting ice.
NKE presented the next generation of ARVOR float. Hardware/structure is very similar, but software/firmware will have major upgrades and will address some of our complaints/issues from the past. Available 2025.
Argo Tech plans to host quarterly virtual meetings and bi-annual in-person meetings. Next in person meeting September 2026 (WHOI?).
Next two meetings will tentatively discuss float profiling, timing, parking, and the report to be made to the AST.
A meeting report is being produced, however some action items are more relevant to Argo Canada than others. Those are listed here. Note that at the time of writing this the action items are still subject to change.
This will encourage testing and allow for analysis of float failures in context of knowing the float was in working order as close to deployment as possible. Data capture methodology to be determined. Meta file may be a good place to store this data, however Argo Tech recognizes the challenges associated with additions to the data system.
Transmitted data and engineering log info should be sent to vendors so that they may monitor float performance as well. For SBD, simply add the preferred vendor email to the distribution list. For floats on RUDICS communication, collaborate with vendors to arrange appropriate access.
Argo Tech asks for support as needed from AST/ADMT as DACs may need to facilitate.
Argo Tech asks vendors to review and analyze data as it is submitted.
Larger user groups should track float failures and present analysis at bi-annual Argo Tech meetings and/or updates at quarterly virtual meetings (see SIO failure analysis presentation as an example). Any systematic failures should be communicated to the vendors and the Argo Tech group to prevent deployment of compromised floats.
This action item is a call for improved record keeping prior to float deployment. This includes logging all interactions with the float, for example using date-stamped terminal logs. In addition, any problems discovered during float testing/ballasting/assembly should be formally recorded by the end user and shared with the vendor, even in cases where the problem can be fixed without any required RMA or similar action from vendors. WHOI maintains a github for this type of information, which is a good example to follow.
User groups, especially those with close relationships with float vendors or sensor manufacturers, will often bypass the typical customer service portals these companies have in place in favor of direct contact with a representative they may have a personal relationship with. Bypassing these types of ticketing systems however can lead to issues not being properly tracked internally by the vendors.
User groups should be motivated to use these ticketing systems as it is the best way for vendors to track issues, and make changes to their products based on that information. It is a way for both end users and vendors to contribute to the progress/reliability of a given float/sensor.
For attribution, please cite this work as
Gordon (2024, Sept. 17). Argo Canada Development Blog: Argo Technical Workshop - Argo Canada Debrief. Retrieved from https://argocanada.github.io/blog/notes/2024-09-17-argo-technical-workshop-argo-canada-debrief/
BibTeX citation
@misc{gordon2024argo,
author = {Gordon, Christopher},
title = {Argo Canada Development Blog: Argo Technical Workshop - Argo Canada Debrief},
url = {https://argocanada.github.io/blog/notes/2024-09-17-argo-technical-workshop-argo-canada-debrief/},
year = {2024}
}