[Gb-ccb] suggested changes to ccb library

[Martin Shepherd]

On Tue, 12 Aug 2003, John Ford wrote:
>...
> The 1 ms integrations will be summed into longer integrations,
> presumably, and these longer integrations are assumed to be the units
> upon which the scans are stopped and restarted.

This summing is performed in the manager, not in the CCB software, so
it is the raw 1ms integrations that Melinda and Brian appear to be
concerned about.

>  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...

Martin