|
|
Base Band
Random Thoughts
2007-Jul-18
Abstract
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.
Just Use WIDAR VCI's BaseBand Configuration?
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
- We need to send VCI messages to the correlator,
- The VCI is expressed as an XML Schema, and
- JAXB allows us to automatically generate java classes from XML schemata,
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.
VCI and ALMA Versions
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:
- APCDataSets = 0 Send only the APC-corrected data.
- APCDataSets = 1 Send only the APC-uncorrected data.
- APCDataSets = 2 Send both the APC-corrected and APC-uncorrected data.
|
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? |
Refresher on Existing SSS Resource Specification Code
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.
SkyFrequencySpecification
This specification has the following properties:
- frequencyRange
- The "chunk" of the spectrum, as seen by the receiver, to be studied.
- timeResolution
- This is expressed as a time duration (eg, 75ms).
- either frequencyResolution or numberOfSpectralChannels
- frequencyResolution is expressed in frequency units (eg, 60Hz);
numberOfSpectralChannels is expressed as an integer.
- polarizations
- A list of polarization products output for this spectral chunk.
I need a better understanding of this. I know the EVLA
receivers are circular polarized, with left and right outputs.
Our enumeration of
PolarizationParameters include, for circular polarizations, "LL", "LR", "RL", "RR", and the total, "I".
Do we need a plain "L" and a plain "R"?
Do we need a separate enumeration similar to ALMA's
DataProductsChoices that has "AUTO_CROSS_PRODUCTS", "AUTO_ONLY_PRODUCTS", and "CROSS_ONLY_PRODUCTS"?
Keep in mind we're already using PolarizationParameter in a lot of places.
- additionalSpecifications
- This is a a map of name/value pairs with no other structure imposed on it.
If we keep it, it is a way to give hints to the hardware and to deal
with hardware-specific differences. Eg, we could enter a name/value pair
here of "recirculation=true". Hardware that knew nothing about recirculation
would not look for this key name and would suffer no harm; hardware that
has recirculation could look for this key name and use its value, if found.
Our sky frequency specification is more akin to a Subband than a Baseband.
The trick is to put enough attributes into this specification so that it,
along with data that we may have gathered elsewhere, is sufficient to
fill out the VCI definition of subband and baseband.
SpectralLineSpecification
The spectral line specification is used by observers who know the rest frequencies
of atomic or molecular transistions, and the velocity of the source of interest.
Given the data held in the properties below, we are able to convert a
spectral line specification into a sky frequency specification. The code for
this is already written.
This specification has the following properties:
- spectralLine
- The spectral line of interest. This property is an object that has its
own set of properties. Our object is based on that of the Splatalogue
version. The main property of interest to us here is the restFrequency
of the line. The other properties are of interest to humans, but not
(yet?) to our software, and include things such as the name of the molecule
and which transistion we're dealing with.
- sourceVelocity
- This the component of the source's velocity either away from or toward the observer.
It helps us translate the rest frequency into a sky frequency. It should
be considered the central velocity of the source.
- velocityBandwidth
- Along with sourceVelocity, above, this helps us translate from
rest to sky frequencies. The velocity range used to create a sky frequency
range is based on sourceVelocity +/- 0.5*velocityBandwidth.
- velocityResolution
- The desired resolution, in linear velocity units (eg, 5km/s), for this
spectral chunk. The velocity resolution will be converted into
frequency resolution. (Right now the code converts the velocity resolution
into a single frequency resolution using, if i remember correctly,
the central velocity +/- 0.5 * resolution for its calculation. It does
not try to create a varying set of frequency resolutions along
the frequency range.)
- timeResolution
- See this same field in SkyFrequencySpecification, above.
- polarizations
- See this same field in SkyFrequencySpecification, above.
Umm, Now What?
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?
Modified on
Friday, 20-Jul-2007 09:34:30 MDT
|
National Radio
