Changes between Version 1 and Version 2 of carlstatrig


Ignore:
Timestamp:
05/22/12 12:49:17 (8 years ago)
Author:
branden
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • carlstatrig

    v1 v2  
    3636As station trigger messages are received by carlsubtrig, they are stored in queues by station. Carlsubtrig maintains an internal clock which is set a fixed number of seconds (the latency period) behind wall-clock (real, system) time. This latency period allows for delayed delivery of station trigger messages. Carlsubtrig uses this internal clock to compare to station trigger times. Once the station trigger-on or -off time is later than the internal clock time, this trigger status change is noticed by carlsubtrig. In order for times to be compared between machines, all machines should be synchronized within a few seconds or better. Xntp (available with Solaris2.6 and also public domain) is a good choice for time synchronization. '''In addition, the system time must be set to data time, i.e. GMT.''' 
    3737 
    38 After the station trigger off time has expired, the station is still considered triggered for an additional TimeToLive (configurable). This feature is to allow for the difference in travel times of the P-wave to each of the stations in a subnet. The idea is that for a subnet to trigger for an event, some minimum (configurable) number of its station triggers must be on at the same time. The TimeToLive parameter is set to provide this coincidence within a subnet. 
     38After the station trigger off time has expired, the station is still considered triggered for an additional !TimeToLive (configurable). This feature is to allow for the difference in travel times of the P-wave to each of the stations in a subnet. The idea is that for a subnet to trigger for an event, some minimum (configurable) number of its station triggers must be on at the same time. The !TimeToLive parameter is set to provide this coincidence within a subnet. 
    3939 
    4040When any one subnet is triggered, the network becomes triggered and an event (TRIGLIST2K) message will eventually be released and optionally. The duration of the network trigger depends on the maximum number of subnets that trigger, up to a configured maximum trigger length. When the network trigger finally expires, then the TRIGLIST2K message is sent to the transport ring. All the subnets are reset and the module waits for the next event.