• Main INDEX
  • Monthly INDEX
  • PREV
  • NEXT
    Make New Entry, Make Followup Entry

    User name R. Michaels

    Log entry time 18:03:36 on August25,2009

    Entry number 285965

    keyword=Oversampling fixed (I think).

    It appears that the rampdelay on R-HRS is important to get the
    busy logic right.  This is because of the propogation delay through
    the trigger supervisor and via the RS485 cable.
    If ovs=0 and integ=13200, want rampdelay=0.
    Actually want (integ+rampdelay)<=13200.  
    If ovs=1 a rampdelay of 200 or 400 on R-HRS (and zero on CH) 
    seems to be important to avoid large deadtimes. 
    Using the RightHap DAQ config.
    Runs to check 
    ovs=0 ... run 11621 ... baseline check.  rampdelays=0.  integ=13200.
    Run 11622 ... ovs=1,  R-HRS rampdelay=200, integ=6000
    (i.e. oversample-by-2)
    In the following, R-HRS rampdelay=200 and CH rampdelay=0.
    Run 11623 ... ovs=3 ... integ = 300.  
    (i.e. oversample-by-4)
    DAQ is very stable at 120 Hz.
    Raw data dumps look good.  
    Run 11624 ... ovs=9 ... integ = 1100 (reminder, R-HRS rampdelay=200)
    (i.e. oversample-by-10)
    DAQ runs stable at 300 Hz.
    Raw data dumps look good.
    I've added some diagnostics :
    If you get deadtime-logic errors (no data, or busy timeout)
    there is a clear "logMsg" at vxWorks.  Absence of these means
    all is well.  
    Also, in the datastream the "bad" data inserted is -999 which
    is hopefully clearer than +9999.
    CRL for R-HRS is happex_test.crl.
    Oops, just realized I had thrown out a data word fa18b0b1.
    I put it back in.  Will do 4 quick runs with updated CRL.
    Run 11625 .... ovs=9 ... oversample by 10.
    Run 11626 .... ovs=3 ... i.e. by 4
    Run 11627 .... ovs=0.  Check baseline.