[Gb-ccb] suggested changes to ccb library

[Brian Mason]

John Ford writes:
 > Martin Shepherd writes:
 >  > 
 >  > On Mon, 11 Aug 2003, Brian Mason wrote:
 >  > >...
 >  > > The issue is that a new scan can't start until the current integration
 >  > > is done. Potentially this is a longer delay than we want.
 >  > 
 >  > This can be fixed at the hardware/driver level, so there is no need
 >  > for a software workaround.
 >  > 
 >  > Having said this, I am wondering what you consider to be too long of a
 >  > delay for a new scan to start, especially given that we were planning
 >  > on very short, 1ms integrations? Observing scans are supposed to start
 >  > on one-second boundaries, so the manager needs to inform the server
 >  > sufficiently far in advance of the target second that the driver
 >  > receives the request before that second has passed. Since the request
 >  > is going over the ethernet, and neither the manager, nor the server
 >  > are to be real-time processes, getting this reliably right will
 >  > probably require the manager to send the message at least a second in
 >  > advance.
 > 
 > 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.  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.

1ms is plenty of accuracy for the scan start. My recollection however
is that 1ms is the *minimum* integration time, we've not always
planned to use that (cf my draft use cases), ie that that short an
integration would not always make sense.

My recollection is that
-there are many *very* fast samples (40 KHz or, now 10 MHz samps),
which are added into...
-longer "integrations" --> which are what are passed back to the
manager via the radiometer server software interface;
-these longer integrations can be configured from 1ms up to many 
many seconds.
-However the innermost hardware loop in the old FPGA design was
such that the FPGA was "blind to the world" while it added samples up
to integrations, ie, you couldn't interrupt it, so if a long
integration time happened to be set (for a good reason, or by
accident) then you are stuck there adding samples up for potentially
a very long time. There was also a cal diode delay which, depending on
where you were in the state machine, might also get added in before
the scan interrupt was checked (tho perhaps this was changed in a
later version).

Melinda & I invented the fake pre-YGOR-scan CCB-intra-scan in the
*manager* to a) set the cal diode rise & fall delays to zero; b) set
the integration time very small; both so that the scan would start
within a small time (I believe 1 ms or so) after the 1pps scan-start
signal.  Again cf my draft use cases, sections 2.7 and 3.3.

For a typical point source radiometry measurement we would do 100 ms
integrations, in order to have enough statistics in a single on-source
scan (one scan=1 to 10 seconds in length, roughly) to estimate the
noise level in the data. For on the fly mapping we would have
integrations of 1ms to many 10's of ms, depending on the slew speed.

A few ms is an acceptable delay but if we can easily hold the scan
start delays to < 1 ms, that would be better. The schedule being what
it is I don't want to significantly perturb the hardware design in
order to accomadate the above considerations since we do have a
workaround; however, if a more elegant and general solution is easily
possible, why not do it.

Does that make any sense?

 Brian


 > 
 > On our other backends, integrations are typically many seconds or
 > even minutes long.  This may not be the case here, but, ???
 > 
 > John
 > _______________________________________________
 > 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/       |
--------------------------------------------------------------------