schedule
Usage
>> schedule [ count maxcount list availablemodes availablefastperiods]
>> schedule <schedule_label> [ grouplist | configlist | stream | storage | mode | <mode_dependent_parameters>]
>> schedule create <schedule_label>
>> schedule delete <schedule_label> | all
Security
Open.
Description
The schedule command can be used to create, delete, modify, and access sampling schedules within the instrument.
To access meta information about all the configured schedules in the instrument, the schedule command can be specified without any arguments. If a specific parameter is required, the parameter key can be provided as an argument to the schedule command. The list of parameter keys are as follows:
count reports the number of schedules currently defined.
maxcount reports the maximum number of schedules that the logger can hold in its pool at any given time.
list reports a list, by label, all defined schedules; labels in the list are separated by a pipe character ("|"), with no spaces. Labels are reported in the order that the schedules were created, earliest first.
availablemodes lists all the sampling modes configured to be available in the instrument; not all instruments support all modes. Items in the list are separated by a pipe character ("|"), with no spaces.
availablefastperiods reports a list of the fast measurement periods available to the instrument for sampling rates faster than 1Hz. Each available period is reported to the nearest millisecond, and the values are separated by a vertical bar, or "pipe" character, "|". The period for sampling rates faster than 1Hz can be set to any value in the list, but no others. If there are no fast periods available, the word none is returned instead of a list of values.
Note that the periods given in the list may be supported in some modes but not others, depending on the instrument's configuration.
>> schedule
<< schedule count=3 maxcount=16 list=test|schedule_04|basic_schedule availablemodes=continuous|average|tide availablefastperiods=500|250|125|63In order to access or modify properties for a specific schedule, provide the <schedule_label> as an argument to the schedule command. The following parameters are available for a given schedule:
<schedule_label> is a required parameter that specifies by label the schedule to access. Labels of schedules cannot be renamed.
grouplist [=<group_label_list ...>] reports or sets a list of groups defining the channels that will be sampled according to this schedule. Labels in the list must be separated by a pipe character ("|"), with no spaces. The list must specify at least one group for the schedule to be valid. Specifying the keyword none, by itself, in place of a list of group labels, will clear the group list.
configlist [=<config_label_list ...>] is a read-only parameter that reports a list of all the configurations currently in the pool which use this schedule. Any configurations used for historical datasets stored in the logger's memory are not included. Labels in the list are separated by a pipe character ("|"), with no spaces. If the schedule is unused by any configurations, this list is replaced by the word none.
stream [=serial | usb | off ] is used to report or set the communication link over which data for this schedule will be streamed in real time during the deployment. At most one link may be active for each schedule. Defaults to off when the schedule is created.
storage [=on | off ] determines whether data for this schedule will be stored in memory during the deployment. For data logging instruments which can store data, this parameter defaults to on when the schedule is created. For sensor instruments that do not store data, schedules are created with this parameter set to off, and the value can not be changed.
mode [= continuous | regimes ] reports or sets the sampling mode to be used by this schedule.
<mode_dependent_parameters> will be described in more detail below.
Here are some points to be aware of when modifying a schedule.
Any modification made to a schedule will cascade into all configurations currently in the pool which use the schedule. Historical datasets in the logger's memory are not affected.
The order of <group_labels> in the <group_label_list> determines the order in which channels will be sent in real time and stored in memory for this schedule. For example, if group_A contains channels W and X, and group_B contains channels Y and Z, then a group list of group_A|group_B results in a channel order W,X,Y,Z, whereas group_B|group_A would result in Y,Z,W,X.
It is possible to specify a <group_label> for a group that does not yet exist, but at some point the group must be defined before the schedule can be used in a deployment.
Mode dependent parameters in each schedule are reported, and can be modified, only for the sampling mode currently selected. Parameters for only one mode at a time can be held in non-volatile memory for each schedule; if the mode for a schedule is changed, settings for the old mode are lost, and settings for the new mode start with a pre-defined set of default values. The mode and settings of other schedules are not affected.
In all cases there may be instrument specific constraints on the parameter values that can be used, but here are some general guidelines:
A period must either be a multiple of 1000ms, or be specified from the list of availablefastperiods (see the schedules command). The upper limit is 86400000ms, corresponding to 24 hours. The period values reported in availablefastperiods all correspond to exact frequencies in Hz, rounded to the nearest millisecond; for example, 125ms for 8Hz, 63ms for 16Hz. See also Tips for system integrators.
continuous mode
A simple mode in which data is acquired at a single, steady rate between the start and the end of the deployment. The parameters are as follows:
period [= <milliseconds>], the amount of time between consecutive samples; must comply with the generic constraints on sampling periods given above.
castdetection=off is reported for consistency with other types of instrument. It can not be set to on, and attempting to do so will provoke an error message.
regimes
This mode is intended for use when the instrument is integrated into a moving platform. The water column is divided into regions by depth, with a maximum of three regions, or regimes. Each regime can use a different sampling rate, and within each regime the water column is divided into bins, which are again defined by depth. All data acquired in each bin is averaged before being stored. For a more detailed discussion of the regimes sampling mode, refer to the chapter Integrating with a profiling float in the Quick start section. The parameters for regimes mode are as follows:
direction [= ascending | descending ]
This parameter indicates the intended vertical direction of the instrument through the water column while sampling. ascending means that sampling will start at depth and continue until the instrument reaches the surface, whereas descending means that sampling starts at (or near) the surface and continues as the instrument depth increases.count [= 1 | 2 | 3 ]
This parameter indicates the number of regimes that are set; the minimum is 1 and the maximum is 3. When multiple regimes are used, regime 1 is always where sampling begins; that is, if direction=ascending then regime 1 is the deepest, whereas if direction=descending then regime 1 is the shallowest.reference [=<channel label> ]
This parameter indicates which channel is used to determine which regime, and which bin within that regime, currently applies during sampling. This channel can either be an absolute or sea pressure channel. Sea pressure is the difference between the absolute pressure measured and the atmospheric pressure. Most instruments do not independently measure atmospheric pressure; in this case a nominal fixed value is defined via the settings command.finalboundary [=<dbar>]
This parameter specifies the transition depth to cease sampling. So, if direction=ascending, the boundary value is the uppermost depth of all of the regimes, whereas if direction=descending, the boundary value is the lowest depth of any enabled regime. The value is given in units of dbar to a precision of 1 dbar; fractional dbar values are not accepted. Before the instrument can be deployed, the verify and enable commands will check that all regimes boundaries are strictly increasing if direction=descending, or strictly decreasing if direction=ascending, and respond with an error message if the constraint is violated.boundary1 [=<dbar>]
This parameter specifies the transition depth from one regime to the next. The boundary value specified for each individual regime is the depth at which sampling starts in that regime. So, if direction=ascending, the boundary value is the lowest depth of the regime, whereas if direction=descending, the boundary value is the uppermost depth of the regime. The value is given in units of dbar to a precision of 1 dbar; fractional dbar values are not accepted. Before the instrument can be deployed, the verify and enable commands will check that all regimes boundaries are strictly increasing if direction=descending, or strictly decreasing if direction=ascending, and respond with an error message if the constraint is violated.binsize1 [=<dbar>]
This parameter specifies the size (depth range) used for each averaged bin. It is typically set by the user so that the total regime size is an integer multiple of the bin size; however, if the last bin in the regime is smaller than the rest, the measurement is stored "early" and the next regime commences. The bin size is specified in units of dbar, with a precision of 0.1 dbar. If the bin size is set to 0.0, the logger will not average the data per bin during the regime and will just record/stream every measurement.period1 [=<milliseconds>]
This parameter specifies the amount of time between consecutive samples throughout all bins in the given regime. The value must comply with the generic constraints on sampling periods given above.boundary2 [=<dbar>]
binsize2 [=<dbar>]
period2 [=<milliseconds>]
boundary3 [=<dbar>]
binsize3 [=<dbar>]
period3 [=<milliseconds>]
Parameters for the second and third regimes, if used, are exactly analogous to those for the first regime already described.
When the vehicle is not in a defined regime, the logger will sample internally at the same rate as the first regime in order to check when it has entered this regime. Measurements acquired during this period will not be stored or streamed.
The average for each bin is stored as soon as the vehicle enters the next bin, travelling in the specified direction. For example, in the following figure the average of the first bin in regime 2 is stored as soon as the vehicle enters the second bin. When the vehicle goes back into the range defined for the first bin, these measurements are discarded, but all measurements acquired in the second bin continue to be accumulated, as long as the vehicle has not entered yet the third bin.
The bin average is calculated without any kind of interpolation. In the case of a bin size set to 0.0, there is no averaging whatsoever.
count channel
The logger may be configured with a channel of type cnt_00. This is a derived channel designed to count the number of readings that actually contributed to an averaged value; it may not be included in every logger configuration.
It is most useful in regimes sampling mode, where it will indicate the number of samples averaged to obtain the reading in each bin. It may also be used in the average or tide sampling modes, where it will usually have the same value as the measurementcount parameter, unless it was necessary to omit some readings from the average because of errors. For other sampling modes, the value of this channel (if present) will just be 1; remember that the channel can be excluded from any or all groups if it is not required.
In all cases, if the channel is sampled according to multiple schedules, the value reported for each schedule could be different and, in each case, will be applicable to the schedule using it.
create
Usage
>> schedule create <schedule_label>
Security
Unsafe - schedules may not be created while logging is enabled.
Description
Schedules can be created and deleted using the create or delete actions within the schedules command. In both cases <schedule_label> must be specified as an argument to the action.
>> schedule
<< schedule count=3 maxcount=16 schedulelist=test|schedule_04|basic_schedule availablemodes=continuous|average|tide,availablefastperiods=500|250|125|63
>> schedule create s.pressure
<< schedule create s.pressure
>> schedule s.pressure
<< schedule s.pressure grouplist=none configlist=none stream=off storage=on mode=continuous period=1000 castdetection=off
>> schedule
<< schedule count=4 maxcount=16 schedulelist=test|schedule_04|basic_schedule|s.pressure availablemodes=continuous|average|tide availablefastperiods=500|250|125|63delete
Usage
>> schedule delete <schedule_label> | all
Security
Unsafe - schedules may not be deleted while logging is enabled.
Description
Deletes one or all schedules. Schedules are specified by their labels. At least one existing schedule must be specified. The parameters are as follows:
<schedule_label> specifies by label a single schedule to delete from the pool.
all causes all user-defined schedules to be deleted from the pool.
A deleted schedule can no longer be used in any configuration. Any configuration in the configuration pool which used the deleted schedule will automatically have the schedule removed from its list. Historical datasets in the logger memory are not affected when a schedule is deleted; the configuration snapshot saved in the dataset's metadata includes all schedule details at the time the logger was enabled.
Schedules can be deleted using the delete action within the schedule command. The <schedule_label> must be specified as an argument to the action.
>> schedule
<< schedule count=4 maxcount=16 list=test|schedule_04|basic_schedule|s.pressure availablemodes=continuous|average|tide availablefastperiods=500|250|125|63
>> schedule delete schedule_04
<< schedule delete schedule_04
>> schedule
<< schedule count=3 maxcount=16 list=test|basic_schedule|s.pressure availablemodes=continuous|average|tide availablefastperiods=500|250|125|63Deleting schedule_04 removes it from the pool and reduces the count by one.
>> schedule
<< schedule count=3 maxcount=16 list=test|basic_schedule|s.pressure availablemodes=continuous|average|tide availablefastperiods=500|250|125|63
>> schedule delete all
<< schedule delete all
>> schedule
<< schedule count=0 maxcount=16 list=none availablemodes=continuous|average|tide availablefastperiods=500|250|125|63Deleting all schedules removes all items from the pool and reduces the count to zero. The schedule list will indicate it is empty with the value of none.