Changes between Version 1 and Version 2 of k2ew


Ignore:
Timestamp:
04/06/12 09:09:43 (9 years ago)
Author:
branden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • k2ew

    v1 v2  
    88 
    99== Details == 
    10 This module receives data packets from a Kinemetrics K2 Strong Motion Accelerograph. The packets are then put into an Earthworm ring-memory transport buffer. The module was developed using Earthworm version 5.0 and K2 header version 1.40. It is all 'C' code compiled using standard makefiles ("makefile.nt" or "makefile.sol") like those used with other Earthworm modules. On Windows 2000, there are two versions of K2EW: k2ew_com, to use a COM port on a PC; and k2ew_tcp, for using TCP communications to a serial-to-TCP server (such as a Lantronix MSS100) connected to the serial port on the K2. For Solaris/Unix, the two versions are k2ew_tcp and k2ew_tty (for using a Unix TTY port.) There is one config file for the TCP versions (k2ew_tcp.d); the others use k2ew_com.d and k2ew_tty.d. One instance of K2EW will be needed for each K2, and each instance will have its own config file. 
     10This module receives data packets from a Kinemetrics K2 Strong Motion Accelerograph. The packets are then put into an Earthworm ring-memory transport buffer. The module was developed using Earthworm version 5.0 and K2 header version 1.40. It is all 'C' code compiled using standard makefiles ("makefile.nt" or "makefile.sol") like those used with other Earthworm modules. On Windows 2000, there are two versions of K2EW: k2ew_com, to use a COM port on a PC; and k2ew_tcp, for using TCP communications to a serial-to-TCP server (such as a Lantronix MSS100) connected to the serial port on the K2. For Solaris/ Unix, the two versions are k2ew_tcp and k2ew_tty (for using a Unix TTY port.) There is one config file for the TCP versions (k2ew_tcp.d); the others use k2ew_com.d and k2ew_tty.d. One instance of K2EW will be needed for each K2, and each instance will have its own config file. 
    1111 
    12 The K2 is configured (outside of K2EW) by the user for its station name, channel names and selection of channels used. This configuration can be done from the command line or, for PCs, using QuickTalk (a free program from Kinemetrics. QuickTalk can only be used with a COM port.) A useful manual from Kinemetrics is "Altus Monitor Mode Communications", available on the web. This manual is essential if you need to use command-line configuration. 
     12The K2 is configured (outside of K2EW) by the user for its station name, channel names and selection of channels used. This configuration can be done from the command line or, for PCs, using !QuickTalk (a free program from Kinemetrics. !QuickTalk can only be used with a COM port.) A useful manual from Kinemetrics is "Altus Monitor Mode Communications", available on the web. This manual is essential if you need to use command-line configuration. 
    1313 
    1414The station name (as in station, component, network or SCN) must be configured in the K2; channel names may be configured there as well. If channel names have not been entered into the K2 then the default names "CH1", "CH2", "CH3", etc. are used. The network name is specified in the "k2ew.d" file. To enable the Serial Data Stream (SDS) output needed for K2EW, these parameters should be setup in the K2 as follows: 
     
    4141Before K2EW exits, it stops the Serial Data Stream output from the K2 (unless restarts are enabled in the config file) and writes several lines of statistical information to the console and the log file. 
    4242 
    43 The K2 can also be configured to trigger on events. See the K2 User Manual from Kinemetrics for details on this. When the K2 triggers on an event, it saves the trace data in an event file on its internal disk(s). (These disks are normally PCMCIA ram-disks. One or two of them can be installed in the K2.) The K2 will send messages to K2EW about event files, including file names and size, and disk space remaining. These messages are logged in the K2EW log file and on the screen/console as standard-error. The K2 does not automatically remove these files unless it is configured for "AQ AUTODELETE". You need to log into the K2 (outside of K2EW, using QuickTalk or command-line) to download the event files (if desired) and to delete the old files. 
     43The K2 can also be configured to trigger on events. See the K2 User Manual from Kinemetrics for details on this. When the K2 triggers on an event, it saves the trace data in an event file on its internal disk(s). (These disks are normally PCMCIA ram-disks. One or two of them can be installed in the K2.) The K2 will send messages to K2EW about event files, including file names and size, and disk space remaining. These messages are logged in the K2EW log file and on the screen/console as standard-error. The K2 does not automatically remove these files unless it is configured for "AQ AUTODELETE". You need to log into the K2 (outside of K2EW, using !QuickTalk or command-line) to download the event files (if desired) and to delete the old files. 
    4444 
    4545K2ew can be configured to query the K2 periodically to send a status messages. This message includes free disk space, battery voltage, event and alarm trigger status, and basic hardware status (OK/Fault). Newer K2's also have an extended status message that includes local temperature and a few fault indicators. If supported by the K2, K2EW can query for the extended status. Paramters in the K2EW config file can be set for alarm thresholds on several of these status parameters. When these thresholds are exceeded K2EW can send email or pages through earthworm. 
     
    5252When the received packet is "ahead" of the current expected stream and data sequence numbers, one of two things will happen: 
    5353 
    54 If the data sequence number is not greater than the expected value by more than the 'WaitTime' parameter, the number of missing packets is calculated, and for each one a "waiting" block is entered into the FIFO buffer. If the 'Debug' parameter is greater than zero then the log message "Detected # missing packets..." is generated. The output of packets to the Earthworm ring buffer stops until the "waiting" blocks are filled or too much time passes and they are skipped. Any time the "waiting" blocks are skipped, the log message "Cleared # wait entries..." is generated. 
     54If the data sequence number is not greater than the expected value by more than the '!WaitTime' parameter, the number of missing packets is calculated, and for each one a "waiting" block is entered into the FIFO buffer. If the 'Debug' parameter is greater than zero then the log message "Detected # missing packets..." is generated. The output of packets to the Earthworm ring buffer stops until the "waiting" blocks are filled or too much time passes and they are skipped. Any time the "waiting" blocks are skipped, the log message "Cleared # wait entries..." is generated. 
    5555 
    56 If the data sequence number is greater than the expected value by more than the 'WaitTime' parameter, a "resync" is performed. All "waiting" blocks are skipped, the received packet is entered into the FIFO, and the current expected stream and data sequence numbers are resynchronized. When this happens, the log message "Too many missing packets (#) detected / Resync-ing..." is generated. 
     56If the data sequence number is greater than the expected value by more than the '!WaitTime' parameter, a "resync" is performed. All "waiting" blocks are skipped, the received packet is entered into the FIFO, and the current expected stream and data sequence numbers are resynchronized. When this happens, the log message "Too many missing packets (#) detected / Resync-ing..." is generated. 
    5757 
    5858When the received packet is "behind" the current expected stream and data sequence numbers, one of three things will happen: 
     
    6464Otherwise, the received data packet is ignored. If 'Debug' is greater than zero then the log message "Unexpected data block..." is generated. 
    6565 
    66 When a missing packet is detected and a new "waiting" block is entered into the FIFO, it is necessary to issue a resend request for the packet to the K2. If less than 'MaxReqPending' other "waiting" blocks exist in the FIFO, then the request will be issued. (If 'Debug' is greater than zero then the log message "Requesting resend (#) of packet..." is generated.) If resend requests for more than 'MaxReqPending' number of "waiting" blocks are pending, then no resend requests from new "waiting" blocks will be issued until 'MaxReqPending'/2 or fewer number of "waiting" blocks remain outstanding. 
     66When a missing packet is detected and a new "waiting" block is entered into the FIFO, it is necessary to issue a resend request for the packet to the K2. If less than '!MaxReqPending' other "waiting" blocks exist in the FIFO, then the request will be issued. (If 'Debug' is greater than zero then the log message "Requesting resend (#) of packet..." is generated.) If resend requests for more than '!MaxReqPending' number of "waiting" blocks are pending, then no resend requests from new "waiting" blocks will be issued until 'MaxReqPending'/2 or fewer number of "waiting" blocks remain outstanding. 
    6767 
    68 In general, when the packet for a "waiting" block is not received after 'WaitResendVal' seconds a new resend request is issued for the packet. If 'MaxBlkResends' requests have already been issued for the packet then its "waiting" block is marked as "skipped" and the "output" thread bypasses it. In this case the log message "Excessive resend count..." is generated. Note that K2EW attempts to maximize its error-recovery capabilities by issuing multiple resend requests as needed while still giving priority to the "oldest" block in the FIFO that is "waiting". 
     68In general, when the packet for a "waiting" block is not received after '!WaitResendVal' seconds a new resend request is issued for the packet. If '!MaxBlkResends' requests have already been issued for the packet then its "waiting" block is marked as "skipped" and the "output" thread bypasses it. In this case the log message "Excessive resend count..." is generated. Note that K2EW attempts to maximize its error-recovery capabilities by issuing multiple resend requests as needed while still giving priority to the "oldest" block in the FIFO that is "waiting". 
    6969 
    7070If a received packet fills in a "waiting" block that is not the "oldest" one in the FIFO, then a resend request is re-issued for the "oldest" block that is "waiting". If the stream and data sequence numbers of a received packet match a "waiting" block, but the packet has a payload error (such as a CRC-checksum mismatch), then a resend request is re-issued for the "waiting" block. When either of these cases occur and 'Debug' is greater than zero, the log message "Re-requesting resend (#) of packet..." is generated.