Tips for system integrators

Deployment start time

The command deployment allows the start time of a deployment to be accessed, modified, or ignored. This concept of a start time is beneficial mainly to standard product users. In the context of an integration with a host controller, it is generally useless, scheduling of logging or streaming being controlled directly by the host controller. Furthermore, on some system the clock might just be discarded and timestamping applied by host controller (streaming instruments).

The use of the start time is dictated by the gating condition set. The time gating condition is the only one which will use the starttime to gate a deployment.

The onboard RTC clock minimum date time is 2000/01/01 00:00:00 and the maximum date time is 2099/31/12 23:59:59.

If a deployment is required to start at a specific time in the future, configure the deployment gate for time as follows:

>> deployment starttime=20000101000000 gate=time

However, if the deployment is not required to start at a certain time then we recommend using none as the gating option:

>> deployment gate=none

Sampling rates

The schedule command allows the user to set faster than 1Hz sampling rate by specifying a number of milliseconds below 1000.  It also reports a list of milliseconds values (see availablefastperiods parameter). As there is in many cases no direct conversion between an integer number of milliseconds and a frequency in Hertz, the following explains how to convert from one to another.

Converting from Hz to milliseconds

If Fs is the sampling rate in Hz, then the number of milliseconds to be used as a parameter for the schedule command, is calculated as (using integer division):

Converting from milliseconds to Hz

If Ts is the number of milliseconds reported by the logger as the period (see schedule command), then the corresponding sampling rate Fs in Hz, is calculated as (using integer division):

Examples

If the logger needs to be deployed at 13Hz, and this sampling rate is available, then the period to be used would be 77 ms.

If the logger is deployed with a period of 53 ms, the effective sampling rate is 19Hz.

Future proofing development

The chapter Command Processing and Timeouts gives a good overview on best practices on how to parse and handles logger commands.

For OEM customers using more than one configuration or planning to, it is best practice to inspect which channels are available with the channel command:

>> channel
<< channel count=5 list=conductivity_00|temperature_00|pressure_00|sea_pressure_00|salinity_00

Power management and power cycling behaviour

The RBR logger can accommodate two power sources: internal batteries (see instrument power internal) or an external power source (see instrument power external).

The RBR logger handles power management automatically, switching to one or the other power source depending on availability. The instrument also automatically handles which power domains should be enabled or not depending on their current state (sampling, asleep, in communications). In systems which power cycle the logger, a full reset will be obtained by powering off the unit for at least 5 minutes to allow time for internal capacitors to discharge.

There is no dedicated battery to maintain the onboard clock. As a consequence, the onboard clock might be lost every time there is no power source available (see Note). In such cases, the date and time may be reset to 2000-01-01 00:00:00. However, if the clock is lost while logging, the instrument will try to reset the clock to midnight of the day following the last known good sample. For example, if the last sample stored was at 2024-03-17 15:34:26.000, the instrument would try to reset the clock to 2024-03-18 00:00:00.000 before continuing to log data. Although the instrument no longer has any true idea of what the actual date and time are, this strategy does at least ensure that stored (and streamed) timestamps continue to advance monotonically.

Upon power cycling, the instrument may take up to 4 seconds to initialize. During that initialization period, characters transmitted to the instrument might not be received, and commands might not be processed correctly.

If an instrument is power cycled while it is logging or streaming, it will continue logging and/or streaming, even if the RTC clock is reset as described above. This activity will continue after the initialization period, the settling time and the read time periods have expired (see channel) following the restoration of power.

In order to enforce a full hardware reset, this sequence should be followed:

1. power off the unit

2. wait 5 minutes

3. power on the unit

4. wait 4 seconds before sending any commands (initialization time)

When the instrument is not powered, all UART and RS232 lines must be in high impedance mode, with no pull-up resistors connected

The amount of time required for the onboard clock to lose the date and time following the removal of all power may vary between instrument types. For some it may be only a few minutes, for others it can be several hours.

Error handling

Instrument not responding

If the instrument stops responding to any commands, first apply a full hardware reset (as described above). 
Send the command id followed by the command disable; if the instrument is still not responding, repeat the same procedure with a baudrate 115200 bps (default baudrate if configured baudrate lost).

Instrument reporting a hardware failure

If the instrument is reporting a hardware failure error code as described in Information, warning, and error codes, one course of action is to apply a full hardware reset (as described above). 

Instrument reporting error codes in the measurements

Most of the error codes reported reflect a hardware failure of some sort, except for Error-14, which could just reflect a value outside of an equation.
Sometimes, this error can be transient and can be resolved by itself.
However, if the instrument is always reporting the same error for some period of time, one possible course of action is to disable logging/scheduling, do not issue any poll for 10 seconds, and enable the unit again.
If this does not resolve the issue, a full hardware reset (as described above), is advised. If one full hardware reset does not resolve the issue, it is unlikely that performing other full hardware resets will do.

In any case, only channels reported as Error should be discarded. A classic example is an instrument carrying cabled sensors. If a cable is damaged, the measurements associated with the sensor are likely to be reported as errors. Applying previous methods won't help but measurements from other channels are still valid and useful.

Electronic static discharge

Various electrical and electronic components are vulnerable to ESD. RBR PCBAs should be handled in a static controlled environment