[Gb-ccb] suggested changes to ccb library

[Brian Mason]

Martin Shepherd writes:
 > >  It should be possible
 > > for the control manager to send either a "stop" command, which will
 > > stop the device in a sane manner, i.e. after a full cycle of phases,
 > > and an "abort" command, which will stop the data taking immediately.
 > 
 > In the case of the CCB, data are always being taken, except when the
 > system is in standby. Between primary observing scans, data are
 > associated with intra-scans, and can be used for monitoring. The
 > stop-scan command stops an observing scan immediately, and starts an
 > intra-scan ASAP. A start-scan command aborts the current scan or
 > intra-scan and starts the new scan at the specified 1PPS. If the
 > target 1PPS has already passed by the time the driver hears about the
 > start-scan request, the new scan is started ASAP. The issue of what
 > "abort" means in terms of the start-scan command is what I believe is
 > being discussed at the moment. The plan until now was for the
 > device-driver to wait for an end-of-integration interrupt before
 > aborting the previous scan. This made it possible to avoid certain
 > race conditions in the interactions between my driver and Yamasaki's
 > design, but since I am now redesigning the FPGA, this isn't relevant,
 > since I can move the timing of the abort into the hardware.
 > 
 > > On our other backends, integrations are typically many seconds or
 > > even minutes long.  This may not be the case here, but, ???
 > 
 > Our original plan was to have long integrations, but in one of the
 > early meetings at Green Bank, it was decided that the CCB would always
 > send 1ms integrations to the manager, so that the manager could
 > compute statistics etc before summing them up. This upped the
 > data-rate enormously, putting a strain on the ethernet and on the
 > FPGA->device-driver interface, as well as making the CCB real-time
 > requirements somewhat tight, but that is what we were asked to do...

No, 1ms streamed integrations were the minimum requirement-- there was
no stipulation that this be "what is sent", merely that the 1ms
samples be available.

I think it is still the case that by judiciously setting
CCBTimingCnf->integ_period we can have integration periods longer than
1ms. For the very reasons you've stated, Martin, this makes us very
happy.  If this is not the case (ie we've reverted to the minimum
specification, and/or my reading of the 16jun03 "The network interface
between the Ygor manager and the CCB server" is mistaken) please let
me know.

cheers,
  Brian


 > 
 > Martin
 > 
 > _______________________________________________
 > gb-ccb mailing list
 > gb-ccb at listmgr.cv.nrao.edu
 > http://listmgr.cv.nrao.edu/mailman/listinfo/gb-ccb

-- 
--------------------------------------------------------------------
Brian Mason                           | office: +1(304)456-2338
Assistant Scientist                   | fax:    +1(304)456-2229
National Radio Astronomy Observatory  | mail:   PO Box 2
bmason at gb.nrao.edu                    |         Green Bank, WV 24944
http://www.gb.nrao.edu/~bmason/       |
--------------------------------------------------------------------