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

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