Aside from the main window, Waveview windows and Network control window, Scream! includes facilities for monitoring status streams, the status of your network and the integrity of incoming data, and for accessing the serial console of attached digitizers.
Scream! can open a terminal session with any connected digitizer or DCM, either using a serial link or over the network (if the server permits it: see Section 4.2, page 50.)
Communicating with instruments
To open a terminal session with an instrument, right-click on its entry in the left pane of Scream's main window, and choose Terminal... from the pop-up menu:

Scream! automatically negotiates with any other Güralp instruments in the chain until it reaches the one you want to contact, and places the digitizer in command mode. If this fails, press Ctrl-S in the Terminal window to enter command mode manually.
If you see an ok prompt as shown, the digitizer (or DCM in some modes) is ready to receive commands. Otherwise, press ENTER to display a prompt. You can now type terminal commands into the window.
The ↑ and ↓ arrow keys let you browse through the history of typed commands. This history is common to all Terminal windows, so you can easily (for example) send the same command to several digitizers in turn.
To begin capturing a session in terminal mode, including every command you type as well as the instrument's response, right-click in the Terminal window and select Capture to File.... All subsequent actions will be saved to the file you select. Capturing stays in effect through digitizer restarts, and also if you close Scream! and later restart it. The capture file's name is displayed in the caption of the Terminal window.
To send a file to a digitizer, right-click in the Terminal window and select Send File.... This can be used to read in lists of commands that you have prepared, for example to set up a number of digitizers identically. It is also used to update a digitizer's firmware. For details on how to set up firmware transfers, refer to the documentation for the digitizer.
To close the connection, close the Terminal window. Scream! will automatically instruct the digitizer to start transmitting data. If the digitizer begins transmitting data whilst the Terminal window is still open (e.g. because you have issued the close or go command, or because of a time-out) the window will close automatically with the message Terminal session closed by instrument.
The Terminal window provides icons for the keys F2 – F12, which can be programmed with commonly-used commands (“macros”). To set a macro, right-click on a Fn icon, and enter the command or commands in the text box.
You can enter these commands by
left-clicking one of the Fn icons in the Terminal window,
pressing the corresponding function key whilst the Terminal is open, or
right-clicking on the digitizer's entry in Scream!'s main window, and selecting the command from the drop-down menu. Scream! will automatically start a terminal session with the instrument, send the command, and close the link.
Scream! remembers your all macro settings when you close the program.
You can also open a terminal session directly on your computer's serial ports or over a network. This is useful for communicating directly with modems, or with third-party equipment.
To do this, select File → Terminal... from Scream's main menu:

To make a serial connection, choose Direct Serial as the Link Type, select the name of the serial port you want to use, and check that it has the expected baud rate. If it does not, you can change it in the Setup window (see Section 2.1, page 9.) Click OK.
Scream! servers can provide access to their own serial ports over the network. To connect to the serial port of a remote Scream! server, choose Remote Serial and fill in the IP address of the remote computer, together with the port name. Click OK.
You will need to enable serial access on the Scream! server to use this feature. In the My Server tab of the Network Control window, check Allow remote access to Com ports.
If your Scream! server is a DCM, you will need to set the datatransfer.scream.server.allowserialaccess option to yes.
This option is most useful for accessing serial ports on a remote computer which are not producing GCF data. If a remote port does emit GCF data, it will appear in the source tree as normal, and you can open a session with it by right-clicking and selecting Terminal....
To connect over a TCP/IP terminal link, either to a remote Scream! server or to a TCP terminal device (e.g. a serial to network converter), choose TCP/IP and fill in the IP address of the remote computer. Click OK.
The terminal window will then open as described above.
All Güralp digitizers have a separate stream for reporting information about the system, such as their GPS and time synchronization status. This status information is in plain ASCII text format.
To see a Status window for any digitizer, double-click on the Stream ID xxxx00. This stream always has a reported sample rate of 0 samples/s.
During boot-up each unit reports its model type, firmware revision number, its System ID and serial number. This information is followed by the number of resets that have occurred and the time of the latest reboot from its internal clock. The following lines report the current configuration of the unit's sample rates, output taps, and baud rates. A typical digitizer re-boot status message looks like this:

The system will produce a similar status message whenever it is powered up, and whenever you reboot it (normally, after changing its configuration.)
If a GPS unit is fitted, its operational status is reported on reboot and the behaviour of the time synchronisation software will also be shown.
From a cold start, GPS will initially report No GPS time together with its last position (taken from the internal backup.) All messages from the GPS that involve a change of its status are automatically reported. Repeated status messages are not shown to avoid unnecessary clutter.
A typical GPS status report from a DM24 digitizer looks like this:

This report shows the satellites the system has found, and their corresponding signal strengths.
If the system has not been moved from its previous location, it should be able to find enough satellites to obtain an accurate GPS time fairly quickly; if the GPS receiver has difficulty finding satellites, there may be a delay of several minutes before a new message is displayed.
Before beginning, the digitizer's internal time synchronisation software will wait for the GPS unit to report a good position fix from at least 3 satellites, for at least 6 consecutive messages. Messages are normally received every 10 to 20 seconds.
The system will then set the internal clock and re-synchronise the Analogue to Digital Converters so that the data is accurately time-stamped to the new reference. Any data transmitted up to this point will be stamped with the time from the internal backup clock, which is set to the new accurate time at the end of this process. The re-synchronisation will result in a discontinuity in the data received.
From this point, the control process will attempt to keep the internal time-base synchronised to the GPS 1 pulse per second output, by adjusting a voltage-controlled crystal oscillator. First it alters the voltage control to minimise the error. Next it attempts to minimise both the “phase error” (i.e. the offset between the internal 1 Hz signal and the GPS) and the drift (the frequency error relative to GPS.) During the control process the system reports the measured errors and the control signal applied, as a PWM (Pulse Width Modulation) value.
During the initial, coarse adjustment stage only the coarse voltage control is used and no drift calculation is made. If the system is operating in a similar environment to that when the system was last powered (most importantly, the same temperature) the saved control parameters will be appropriate and the system should rapidly switch to the ‘fine’ control mode. The system reports its control status and parameters each minute, with error measurements given in nominal timebase units. In a stable temperature environment the system should soon settle down showing an offset error of only a few thousand (average error < 100 microseconds) and a drift rate under 100 counts (< 1 in 10-6).
Newer Güralp digitizers output a status block every few minutes giving information about the GPS status, ambient temperature, etc:

Scream! can automatically extract measurements from these messages and show them in graphical form. For each field Scream! finds, a checkbox is displayed at the top of the Status window. In the example above, Scream! has found Offset, Drift, PWM, Volts (i.e. user input) and Temp (temperature) fields in the status messages. Not all digitizers output all of these fields, so some of these checkboxes may not be present.
To display any or all of these fields in graphical form, check the checkbox for the field(s) you want to examine:

You can resize the Status window, or drag the bar between the graphs and the block display area, to see the graphs in more detail.
This window provides at-a-glance state of health information about all instruments on your network. To open it, choose Windows → Summary window from Scream!'s main window.

Every instrument known to Scream! is listed in this window, with coloured icons representing their timing, mass position and data flow status. The window also reports how many triggers have been communicated to Scream! in status blocks. To make Scream! forget all this information and start afresh, click Reset All. This will not remove streams from the main window or Waveview windows, or from the stream buffer.
In the leftmost four columns, each entry is a coloured rectangle with a border. A grey rectangle indicates that no relevant data has been received from the instrument since Scream! was started. Green indicates that this measurement is satisfactory; yellow indicates that some attention may be necessary, and red indicates that there is likely a problem.
If a box has a coloured border, an unsatisfactory reading has been received since the last reset, but the status has since improved. Thus, if a box goes from yellow to green, the border will be coloured yellow until you reset. If the same box subsequently turns red momentarily and then returns to yellow or green, the border will change to red.
This column details the instrument's GPS timing status. The colours are the same as those used for the top half of the instrument's icon in the main window. Double-click on a column entry to see the status messages coming from that instrument.
Grey : Scream! has not received any GPS information from the instrument since the last reset.
Green : The instrument has reported a satisfactory GPS timing fix.
Yellow : The instrument has reported a gap in the timing stream. This will occur if the GPS signal deteriorates to the point where the receiver cannot keep a lock on the satellites.
Red : The instrument has not reported a satisfactory timing fix for over an hour. This will happen if there have been gaps in the signal (as above), but also if it has not reported anything. If you have set the GPS system to power down for intervals longer than an hour, the icon will turn red even if the system is working normally.
This column details the instrument's mass position status. Double-click on a column entry to open a Waveview window on the instrument's mass position channels. (Note: some instruments must be switched to 1 s response mode for these channels to give meaningful data.)
Grey : Scream! has not received any mass positions information from the instrument since the last reset.
Green : The instrument has reported satisfactory mass positions (all components < 25% of full scale.)
Yellow : One or more components are reporting mass positions between 25% and 50% of full scale. Most instrument types will still function normally, but the masses should be re-centred when it is next convenient.
Red : One or more components are reporting mass positions over 50% of full scale. Most instrument types will still function adequately, but the masses should be re-centred as a matter of urgency.
This column records the time the instrument last sent data to Scream!.
When a data block is received, the box turns green. Over the next two minutes, if no more data is received, the box gradually changes through shades of yellow, to orange, and finally red.
If more than two minutes pass before the next data block is received, the border of the box will change to red to alert you that a suspicious gap in data has been detected. If you do not expect real-time data from this instrument, or you are using low sample rates exclusively, you may allow this column to turn red. For example, a 1 sample/s stream will transmit a block only once every 4 minutes under quiet conditions.
Double-click on a column entry to select the instrument in Scream!'s main window.
This column records the number of corrupted blocks Scream! has received. A corrupted block is one whose checksum does not match the data, or which fails one of Scream!'s integrity checks. To see which checks are failing:
Open a ViewInfo window on the suspect stream, where erroneous values are shown in red (see “The ViewInfo window”, page 66.)
Alternatively, double-click on the column entry to open the error log file (if you are recording one) in Notepad or an xterm.
The meaning of the colours is as follows:
Green : Fewer than 2 corrupted data blocks have been received in the last minute, or the window was reset less than a minute ago.
Yellow : 2 – 10 corrupted data blocks have been received in the last minute.
Red : Over 10 corrupted data blocks have been received in the last minute.
This column records the number of times the digitizer has sent a trigger status message since Scream! was started. New triggers are coloured in green; when you Reset window the green shading will disappear, but the number will remain.
Double-clicking on a column entry opens a window with details of the trigger events.

The top half of the window lists all the trigger events, with information extracted from each trigger's status message. The full status message is reported in the lower half.
Double-clicking on an entry in the table (or selecting it and pressing ENTER) opens a paused Waveview window containing all the streams from the digitizer which triggered, for the time period of the trigger. This time period is marked with the Time Cursors to show the duration of the event.
If you have instructed the digitizer to record pre- or post-trigger data, Scream! will attempt to include this as well. If two triggers from the same digitizer overlap, Scream! may show both triggers in the Waveview window, because the point where one trigger ends and the next begins is essentially arbitrary.
Scream! can only display data which is still in its stream buffer. If the buffer is full and the data has already been purged, double-clicking on a trigger will show a blank window. To view the data, you will need to retrieve it from the hard disk or your recording system, and replay it into Scream!.
The columns contain the following information:
Start : The start time of the trigger, prefixed with a * if the trigger occurred since the last time you reset the Summary window.
End : The end time of the trigger.
Type : What caused the trigger: R if the STA/LTA ratio exceeded the set threshold, L if the level exceeded the threshold, E for an external trigger (if the digitizer supports it) or S for a trigger generated in software.
You can also open the Trigs window by right-clicking on a digitizer's entry in the main window and selecting Triggers... from the menu.
Detailed header information from incoming data blocks is available from the ViewInfo window, accessible by selecting Windows → Info Display... from Scream!'s main window.

If ALL is selected as the Source at the top of this window, details of every incoming data block will be shown as they arrive. You can narrow the selection to a particular source using the drop-down menu.
Scream! makes a number of validity checks for incoming blocks. Any suspect fields are shown in red in the ViewInfo window.
The first three fields come from the transport header, which is added to each GCF block to aid with data transmission:
Block ID character : Must be a ‘G’ for GCF format blocks.
Block Number : An incrementing counter, modulo 256 (i.e. 255 + 1 = 0) for blocks from a data source. This box reports the Block Number for every incoming block, so this value will not appear sequential if you are using several sources. Unless the field turns red, the value is what Scream! expected.
Block Size : The size, in bytes, of the GCF block following, not including transport information.
The remaining fields constitute the information available from the GCF block's internal header, and mostly duplicate the information available in the stream list. The following additional information is available:
Reserved : A reserved field in older implementations of the GCF format. Newer digitizers use this byte to provide information about the filter setup of the digitizer, among other things. When the byte is non-zero, Scream! will interpret it if it can, and display the corresponding filter setup. Refer to the Güralp Systems technical notes (available on the web site) for more details.
Sample Rate and Compression : The current sample rate and compression code, also displayed in Scream!'s main window.
Number of Records : GCF blocks are divided into 4-byte records. Each record can contain 1, 2 or 4 samples, depending on the current compression factor. Since all GCF blocks are 1024 bytes long, allowing for the 24-byte header, a full GCF block should always contain 250 records. However, it is permissible for a GCF block to be only partially full.
RIC / Calculated : The Reverse Integrating Constant (effectively the value of the last sample in the block) and its calculated value from the differences in the block.
Checksum / Calculated : Received and calculated checksum values for the data in the block. If these differ, Scream! assumes the data is corrupt and asks the digitizer to re-transmit the corrupt block. If you are using a simplex communications link, this will fail, and the data block will be lost.
Scream! also logs any errors it detects. For more information on Scream!'s logging system, see Chapter 10, page 114.