The BaseBand is a concept we need for hardware set up, specifically for the correlator. The WIDAR VCI Specification defines a BaseBand Configuration in an XML Schema file. The ALMA team also has a definition for BaseBandConfiguration. This document compares the two versions with the goal of deciding which, if either, the SSS software should use.
Ultimately, the WIDAR Correlator must be passed a BaseBandConfiguration in its own language, namely VCI. We may also want the OPT to allow users to work directly with a BaseBand concept (as opposed to just telling the OPT what frequency areas are of interest and the letting the software translate those areas into basebands).
Since
it would seem natural to just use the classes generated from the VCI XML schema. Using the VCI baseband concept would mean we do not have to translate from our own version of a baseband to VCI's version. Using VCI's baseband may be what we ultimately do, but we're also going to explore, below, creating something more generic that the VCI's representation -- just in case the software needs to support multiple backends.
The data in the ALMA columns, below, comes from the BaseBandConfiguration document mentioned in the Abstract, above. The data in the VCI columns comes both from the WIDAR VCI Specification document mentioned in the Abstract, above, and from the XML Schema File. Unfortunately, those two sources do not contain the same data. When these sources are in conflict, I am taking the XML Schema as the definitive reference. Also of note: the VCI will soon undergo changes that should make it line up better with NRAO's view of what is should be.
| Common Data | ||||
|---|---|---|---|---|
| VCI | VCI Desc. | ALMA | ALMA Desc. | My Comments |
| bw | Bandwidth in Hz. | (See bBC in ALMA-Specific section, below.) | -- | I'd lean in favor of specifying the bandwidth directly, as opposed to having a table of modes. WIDAR just seems too flexible to warrant trying to tabularize all the possible combinations. |
| id | BaseBand identifier. | baseBandIndex | The baseband index (1-4) to be configured. | -- |
| models.freqOffset | Local Oscillator (BaseBand offset) in Hz. Specified independently for each BaseBand of each antenna. | centerFrequency | Must be between 4 - 12 GHz or 4-8 GHz depending on receiver band | I believe these two fields have the same purpose -- namely, to allow one to deduce the originally received frequencies. I lean toward using the offset concept, as it's simpler to just add the offset to zero and bandwidth to come up w/ the original frequency range. |
| models.sideband | Defines which sideband is being processed (VLBI). | sideBand | Sideband to use. | -- |
| ❈ Both specifications also provide for a list of Subbands. A separate document is needed to compare these. ALMA seems to have two different types: ChannelAverageBands and SpectralSubbandSet. | ||||
| VCI-Specific Data | ||
|---|---|---|
| VCI | VCI Desc. | My Comments |
| dataPath | Station Board Data Path. | This doesn't seem like a generic concept. |
| models | Parameters related to delay and phase models. "models" has items: freqOffset, singlePhaseCenter (yes/no), fringeRotation (on/off), sideband (upper/lower) | I put models.freqOffset & models.sideband in the common section, above. See if Michael things fringeRotation and singlePhaseCenter are things that belong in a baseband configuration. |
| name | Optional BaseBand name. | An optional name, for human use, seems like a good idea. |
| numBands | Number of bands in the input stream. | See Q and A on this topic. It's not clear to me why the configuration of a single band would be carrying information about the number of bands in an input stream. Seems like this concept should go somewhere else. I don't think i really understand what Sonja meant here. |
| numBits | Number of bits in the input stream. | Is there a better place (InputStream?) for this? (See Q and A on this topic.) |
| polarization | "polarization" has a polarization type (L or R) and a PolPairIdType, which is a number from 0 through 4. | See also bBC and dataProducts in ALMA-Specific section, below. Saying "i want these polarizations products from this baseband" might be a better approach for us than "this baseband has this polarization". Can we specify polarization product desires at the subband level, or must all subbands in the same baseband get the same products? |
| pulsarGating | Pulsar gating parameters.VCI has a separate table (4-22) for this. Attributes: epoch, gateWidth, period, firstDerivative, secondDerivative. | Find out if pulsar specification is really per-baseband. |
| source | Source of input data. Optional. (FORM-0, FORM-1, TPG, VSI-0, VSI-1.) | This doesn't seem like a generic concept. |
| station | "station" has an ID, name, and list of antennas. | This doesn't seem like a generic concept. |
| subarray | "Subarray" has an ID and a name. The VCI Doc does not have subarray, but does have antenna. | I would like to see the base band configuration be free of references to specific antennas. Instead, there s/b s/t that says "use base band config X for subarray S". |
|
❈
The following data items are present in the VCI Doc, but not the VCI XML Schema:
Antenna
Offset (see models.frequencyOffset) Single Phase Center (see models.singlePhaseCenter) Delay Model Valid Interval Delay Model Epoch Fringe Rotation (see models.fringeRotation) Sideband (see models.sideband) | ||
| ALMA-Specific Data | ||
|---|---|---|
| ALMA | ALMA Desc. | My Comments |
| aPCDataSets | This flag determines which APC results are published:
|
APC = ALMA P_____ Correlator? P = Production? |
| bBC | Baseband configuration (BBC) mode (1-228) which defines the bandwidth, polarizations and oversampling. An integer. | See comments in Common Data section, above |
| binMode | Single Bin = 0. Multiple bins, subarray based (e.g., nutating subreflector) = 1. Multiple bins, baseline based (e.g., sideband separation) = 2. | Very ALMA-specific? |
| bin0Duration | Bin0Duration and Bin1Duration define the amount of correlator chip accumulation time for 1 or 2 bins depending on BinMode and CAM. The sum of these two amounts is the dump duration. Bin0Duration defines the accumlation duration for bin 0 while Bin1Duration defines the dump duration for bin 1. - For CAM = AUTO_MODE (1), Bin0Duration must be in units of 1, 2, 4, or 8 milliseconds and Bin1Duration must be 0. - For CAM = CROSS_MODE (16), Bin0Duration and Bin1Duration must be in multiples of 16 milliseconds. | I really need some help understanding all the time-based knobs that correlators seem to have. If i remember correctly, WIDAR has several of these (min hardware integration time, hardware integration time, LTA int'g'n time, backend int'g'n time). What gets exposed to observer? |
| bin1Duration | ||
| cAM | Correlator accumulation mode can be 1 or 16 ms which defines the correlator chip level accumulation duration. Note that this must be 16 for cross-correlations, and this is therefore the default chosen. | |
| channelAverageDuration | The duration of the channel averaging is between 0.5 and 1.024 seconds, such that the smallest number of channel average durations fits into the spectral integration duration. The units of ChannelAverageDuration is ACS::TimeInterval, i.e., 100ns. | |
| dataProducts | Allows the user to select both auto & cross correlation products or auto only or cross only when CAM = CROSS_MODE. When CAM = AUTO_MODE, only the auto products are available. The default is DataProducts = AUTO_CROSS_PRODUCTS. | See my comment for "polarization" in VCI-Specific Data section, above. |
| fFT | Boolean selection to perform FFT. | -- |
| lO2Frequency | The LO2 frequency as determined within the OT, by the tool itself or entered by the user. This is an estimate to help the user in preparing a correlator setup - the actual LO2 used may vary depending on the time of observation. | -- |
| numSwitchCycles | Number of times the bin switching cycle sequence repeats before a dump occurs and results go to CDP - AKA dump duration. For CAM = 1, NumSwitchCycles = 1. For CAM = 16, NumSwitchCycles x (Bin0Ticks + Bin1Ticks) must be less or equal than 4096. Dump duration = NumSwitchCycles x (Bin0Ticks + Bin1Ticks) x 16ms. | Another timing knob? |
| quantizationCorrection | Boolean selection to perform quantization correction on the lag data. | -- |
| windowFunction | An enumerated value representing the windowing function to use: Uniform, Hanning, Hamming, Bartlett, Blackman, Blackman-Harris, Welch. | A useful enumeration for us to also have? |
We have three science-based means of specifying spectral chunks for observation: a sky frequency specification, a spectral line specification, and a pulsar specification. (We have only stubbed the pulsar specification and will not address it here.) Observers are allowed to use multiple instances of each of these types of specifications, all at once, in the same resource specification.
First, we shouldn't invest too much time in this until after we see the new form of the VCI. Remember: the goal is to create VCI messages, so the content of those messages drive the data we get from the observer, from other information stores, and from heuristics. Let's use as a strawman the approach that says we'll develop a 100% hardware view, which is the raw VCI configuration messages, and a fairly pure science view, as represented by the specification objects in the above section, but not some intermediate view that is VCI-like. If we later see that the science view doesn't allow enough flexibility, we'll than either violate its purity or develop this intermediate view.
My concern, and the place where i need help from observatory staff, is what data shown above in the VCI and ALMA specifications should the obs prep tool be gathering that our current science view is not already allowing us to get? For example, we have nothing in the model about sidebands. Should we allow specification of this in the sky frequency and spectral line specifications? If not, should we get it via the obs prep tool, but put it in some part of the resource specification. (Note: right now the ResourceSpecification object holds nothing more than lists of the sky freq, spec line, and pulsar specs. It can certainly hold other data, especially those things that would apply to all subbands for a given configuration.) I can say for certain that i don't want to see antenna and subarry data inside these spectral chunk specifications, but what about those timing knobs, smoothing switches, phase center stuff, etc.?
The VCI is necessarily flexible. It allows a lot of subband by subband specification of various "fiddly-bits". My hunch is that we ought to have something in the ResourceSpecification that has many of these bits, and that uses their values as defaults for all subbands. This would allow intermediate-level observers to play with some of the knobs, but not have to set them on every single baseband. The experts who really want to do that would be forced into using raw VCI. So, which fiddly-bits should we expose in the obs prep tool?