Timeouts, Output Blanking and Power Saving

Wakeup

All RBR instruments sleep as much as possible.  Interaction requires that the instrument be woken up first, then a series of commands issued.  After a 10-second idle timer elapses, the instrument will return to the low-power sleep mode.

The wakeup procedure is to send a single character; carriage return <CR> (0x0D) is the recommended choice.  Over the USB link, the response is usually immediate.  Over the Serial link, this first character may not be completely received by the instrument due to the non-zero wakeup time required, and it may be seen as a garbage character.  However, the instrument itself ignores all garbage characters received immediately after wakeup, and so will not return any errors.

After the initial <CR> character, a 10ms pause should be used.  Following this, the instrument is fully ready to receive any valid command.

In the RBR Ruskin software which is used by end-customers, the following is an example of the wakeup sequence used:

Output blanking

When the first character of a potential command is received, a 10-second timeout is started. This timeout serves two purposes: output blanking and power saving.

As soon as the logger knows it may be about to receive a command, any output which it could autonomously generate (such as streamed sample data) is suppressed. This is to avoid confusing the host, which has just sent a command and may be expecting a particular form of response. Until the logger has processed the command and sent the response, any other outputs will be suppressed. Output such as streamed data may appear in between received commands, but not while a command is being received or processed.

This 'output-blanking' state does not persist forever; if the 10-second timeout expires before a command terminator is seen, outputs such as streamed data are permitted again. This poses no problem for machine generated commands, but can be limiting for commands typed manually at a terminal.

The output blanking behaviour does not apply to the very first (potential) command received after the logger is woken from a quiescent state. For this command, outputs such as streamed data may continue to appear while the command is being received. This exception prevents, for example, random noise input from suppressing required data output. The logger will not invoke the output blanking behaviour until it has seen at least one valid command, at which point it can reasonably assume that a valid host is genuinely trying to communicate with it. Empty commands (isolated <CR> and/or <LF>) do not count as "valid commands" for this purpose.

Power saving

The second purpose of the 10-second timeout is to minimize power consumption. If no valid, terminated command is received within the timeout, the communication returns to a quiescent state. This means that it discards any incomplete input, restarts the "valid command" timeout, and will start afresh with the next input character.

In the case of the serial port, it also allows the transmit hardware to be turned off to save power; indeed, if the logger has no other tasks to perform the entire instrument will enter a low power sleep mode.

The USB port is different in this respect, because the logger can draw enough power from the connection to run most of its basic functions. As long as the USB is connected the logger remains 'awake' and responsive to commands; no hardware is shut down. However, expiry of the 10-second timeout still resets the command processor's behaviour with respect to its 'memory' of valid commands, incomplete input and output blanking.

Changing the Timeout

The timeout referred to in the above sections has a default value of 10 seconds in all instruments. As noted, this is short enough to make manual typing of commands difficult in some cases. This timeout can be changed; refer to the description of the inputtimeout parameter for the settings command for more details.