Stability of async cal mode in cima.

27aug04

The cima gui has an async cal option. It allows you to fire a cal for duration seconds every period secs. This firing continues for the entire scan. The scheduling of when the cal starts is computed from the time in the multicast scramnet blocks. The duration of the cal is determined by the after command of Tk/Tcl. This code is run in the tcl/tk interpreter of the cima executive. The timing code is:

proc calasync_poll { } {
  global cal

  if { $cal(ison) == 0 } {
    return
  }

  after 997 {
    global cal

    if { $cal(ison) == 1 } {

      set sec [ expr int([ scram sec_midn ] ) ]
#      display_log $sec
      if { [ scram sec_midn ] >= $cal(time) } {
        set cal(time) [ expr int( [ scram sec_midn ] + $cal(mult) ) % 86400 ]
        sock_errsend CALCONTROL "CALON"
        display_log "async cal on"
        after $cal(calsecs) {
          sock_errsend CALCONTROL "CALOFF"
          display_log "async cal off"
        }
      }
      calasync_poll
    }
  }
}

Here mult is the cal period and calsecs is the cal duration. It keeps the time for the start of the next cal in cal(time). When it sees this time in scramnet, it turns the cal on with the sock_errsend calcontrol calon line. It then executes the after cal(calsecs) command that will execute the cal off command cal(secs) later. It then reschedules itself by recursively calling itself.

The stability of this method of firing the cal was tested by telling cima to fire the cal for 1 second every 9 seconds. It was told to repeat this for 900 seconds. The alfa receiver was centered at 1400 mhz. The alfa monitor port was set to beam 0. The signal was passed thru a 5 Mhz filter and then square law detected with a 50 Usec time constant. This band was centered at 1390 Mhz (the filter was at 260 Mhz). The detected signal was then input to the Radar interface and sampled every 25 useconds.
The plots show the stability of the cal firing

Fig 1. This plot shows the 9 second periods of each cal firing. The total power of each strip is offset for display purposes. The data has been smoothed to 10 milliseconds . You can see the cal firing each 9 seconds. The pulse drifts to the right. This is because the actual time between cal firings is greater than 9 seconds. After about 10 9 second periods, the cal pulse jumps back by about a second. This is probably a beating with the 1 second time coming out of scramnet.
Fig 2. This plot shows the duration of the cal for each of the 93 9 secon cal periods. The data has been smoothed to .2 milliseconds. For each cal period the start of the cal was found by looking for .5 seconds of contiguous values above the cal threshold (1100 counts). The end of the cal was the first total power value that dropped below the threshhold. Visual inspection of the data showed that the noise levels were small enough for this criteria to always. work. The mean cal duration was 1.11 seconds with an rms of 14 milliseconds. There are some outliers where the cal duration was 50 milliseconds longer than the mean value.

summary:

The async cal firing method of cima for a 1 second cal duration gave a mean period of 1.11 seconds and an rms of 14 milliseconds. There were outliers that were 50 milliseconds larger than the mean. The cal start time drifted by 3.5 seconds over the 900 second measurement. For people sampling the wapps once a second, the 1.1 second duration with jitter of up to 50 milliseconds will add unnecessary errors to the calibration scheme. A hardware based duration of 1 second that is triggered by this same method (by say adding another port to the cal multiplexor) would solve this problem.

processing: x101/040827/chkcal.pro

home_~phil