However, the Timekeeper and DataCollector modules still have not been implemented, so we still are not really doing anything meaningful with the data, such as processing & visualizing it. To recap, the functions of these modules will be:
- (in timekeeper.py) timekeeper.Timekeeper - Worker thread class. The Timekeeper gets created just before the CTU is started up. Its function is to take in all of the data from the CTU (including both PPS time-references and GPS data records) and do several things with it:
- (1) Store it in memory, at least for a while (although older records may be rotated out of memory eventually), and also store it persistently in a database file that can be queried offline from other processes;
- (2) Based on the stored data, provide a service of reconstructing accurate absolute times (ideally to an uncertainty of only a few ns) given relatively "raw" time data for an event. The CTU currently marks time in 4/3 ns intervals from the start of the run - so the core function would be to take some number of "ticks" of this clock (>0) and return a data structure representing the corresponding absolute time in some more standard format (day, hour, minute, second) with few-ns accuracy. The function from ticks to absolute time should be monotonically increasing, but is not necessarily perfectly linear, since there may be some gradual drift of the OCXO clock frequency over time which will need to be measured & accommodated when shaping the translation function. Also, the function is not necessarily unchanging, since as we receive more data, we may continually refine the mapping. Ideally the output structure would also provide some idea of the uncertainty of the time value, based on the current data.
- (3) Display some kind of real-time graphical visualizations of important data having to do with the timekeeping function. This could include, e.g.:
- (a) Graphing the history of key information reported by the GPS, including the number of satellites we're currently receiving data from, and the number that are "good" vs. "bad" in terms of whether their time data has been eliminated from the timing solution.
- (b) Graphing the time-deltas between PPS pulses with a vertical scale marked according to the deviation in Hz between the implied OCXO frequency and the nominal frequency (10 MHz). Superimpose a horizontal line showing the average frequency (over some appropriately-sized time window).
- (c) Graphing the cumulative phase wander of the GPS PPS signal vs. OCXO since the start of the run; this provides a nice visual indication of any excursions which may result from e.g. satellites going out of range, etc. Superimposed on this curve can be another curve representing the reconstructed mapping from OCXO-based times to absolute times; the latter curve ignoring excursions due to a lost signal, and applying appropriate averaging to improve the accuracy of the inferred times beyond the accuracy of individual PPS edges. A gray region around the latter curve indicating the uncertainty of the inferred times can also be shown. The user should be able to zoom in & out on this graph using the mouse to inspect portions of it in detail, to examine the quality of the time reconstruction at particular points.
- (d) Graphing the Allan deviation of the two time references against each other? Not sure if it's feasible, CPU-wise, to update this one in real time, but we can have a separate background thread that updates it periodically.
- (in datacollector.py) datacollector.DataCollector (worker thread class) - The DataCollector gets created just before the CTU is started up. It takes in time-tagged event data of various types from the FEDM and does several things with it:
- (1) Store it (at least recent data) in memory, and also store it persistently in a database that we can separately query. (Like with the TimeKeeper.) Data will be organized into tables based on what kind of data it is - candidate coincidence pulses, non-coincidence pulse counts, or error events.
- (2) Do real-time processing of the candidate-coincidence data via a number of steps:
- (a) From the raw data points, reconstruct a model pulse shape in some appropriate way. Ideally this would involve some Bayesian inference of the ideal shape that best explains the data. But in practice we will probably do some simpler least-squares fit of the model parameters to the data points. When there are not enough data points to e.g. calculate the leading-edge to trailing-edge width ratio, we can use an average of previously inferred ratios as a placeholder.
- (b) Once inferred peak times for pulses have been inferred, cluster them into the most-likely shower sets based on how close-together in time the peaks are on the 3 detectors.
- (c) For each candidate shower event, infer the source heading (angle of incidence). Store the so-processed data for shower events in another database. A separate astronomy module should perhaps take care of mapping ground-relative headings and times to locations on the celestial sphere.
- (3) Do real-time visualization of various data:
- (a) Graph the number of error events (FIFO full, lost pulses) seen at each detector over time.
- (b) Graph the total number of pulse events (coincidence & non-coincidence) seen at each detector over time. (A histogram of pulses of each height would also be nice.)
- (c) 2D polar scatter plot of the inferred ground-relative headings of all accumulated shower events since the start of the run. (Since this is ground-relative, a celestial point source would revolve around the North star on a diurnal basis.)
- (d) Similar plot in inferred galactic coordinates on an elliptic projection - although this should perhaps be taken care of by a separate astronomy module.
No comments:
Post a Comment