Tips for system integrators

Default deployment start and end time

The command deployment sets the start and end time of a deployment. This concept of start/end time is beneficial mainly to standard products 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). In order to not have to set correctly the start and end time relative to the onboard clock, one simple solution is to set them as follows:

>> deployment starttime = 20000101000000 endtime = 20991231235959

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.

Sampling rates

The sampling 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 sampling 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 sampling 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 good practice to not rely on a fixed channel order (between a T.D configuration and a C.T.D configuration, the temperature channel is not necessarily at the same index). In order to identify available channels on a platform, the best way is to use labels (see channel). It is also not recommended to identify channels via their channel type as they might change for the same configuration over time. Those are generated at RBR factory and correspond to the physical properties measured. 

In order to process all the commands, RBR suggests to use a command buffer of 1Kbyte, as it will cover most of commands to the exception of getall, help and, when all channels are requested, sensor, channel, calibration. 

Power management and power cycling behavior

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

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

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. In such case the date and time will reset at 2000-01-01 00:00:00. If the logger endures a reset while logging, and the clock is lost, the logger will continue logging but timestamps might restart at 2000-01-01 00:00:00 even if the starttime (see deployment) is set to another date/time.

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 not processed correctly. 

If an instrument is power cycled while it was logging or streaming, it will continue streaming and logging (even if the RTC clock is reset). In the case of an instrument streaming, measurements will start to be streamed after the settling time and readtime periods expire (see channels). 

In order to enforce a full hardware reset, the following 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

Memory format

Except in the case of operating a BPR instrument in seismic application, the Easyparse "calbin00" memory format should be used.

Error handling

Instrument not responding

If the instrument stop 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 an hardware failure

If the instrument is reporting an hardware failure error code as described in Error messages, 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 (see EasyParse "calbin00" format) reflects an hardware failure of some sort except for Error-14 which could just reflect a value outside of an equation.
Sometimes, this error can be a transient and resolves 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 fetch for 10 seconds, and enable again the unit.
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 reset will do.

In any case, only channels reported as Error should be discarded. A classical 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 and 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