NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Observing > ObsHelp > BalancingDescription

Changes | Index | Contents | Search | Go

Balancing Description & Scenarios

• Summary of Balancing MRs in priority order (Note: Supersedes old list at bottom of page)
• Balancing the GBT Recevier/IF/Backend Power Levels
  • Scenarios
• Good ranges for the hardware
• Other Issues for Discussion
• Tools Currently Available for Balancing
• Backend Specific Instructions for Balancing
• Changes Needed to implement above scenarios ( OUT OF DATE - IGNORE )

Summary of Balancing MRs in priority order (Note: Supersedes old list at bottom of page)

• get/set/adjust attenuators : 8C505
• Converter Rack Balancing : 4C505
• Revise spectrometer warning messages : 9C505
• Revise IF Rack messages : 10C505
• Balancing in presence of RFI : 11C505
• Turning cals on/off before balancing : 12C505
• Balancing criteria

Balancing the GBT Recevier/IF/Backend Power Levels

There are three different scenarios to be considered when determine when and how to optimize the power levels in the GBT hardware path(from the receiver through the backend being used). You should read carefully through this document and choose the balance procedure(s) which best suit your science. Note that regardless of which scenario you choose, you should always balance the power levels on all possible instruments (Receiver, IF Rack, and backend, when applicable) after every new configuration. Additionally, please be aware that the balance scenarios given below assume that you are balancing on your source, unless otherwise stated.

The good range for the various instruments is given at the bottom of this page.

Scenarios

1. No appreciable power within beam when on source (the median power level of the observations does not take you out of the good response limit of your backend, when compared to balancing on blank sky)
   • When doing spectroscopy with the Spectrometer:
     • Balance (at least the IF Rack and preferably the IF Rack and the backend) each time you move to a new source or
     • If you are not switching sources, balance every few hours (often enough to keep within the good response limits of the IF Rack and backend); this will be necessary as your sources rises and atmospheric conditions change.
   • When making continuum (DCR) or Spectral Processor science observations:
     • Balance the IF Rack each time you move to a new source
   • When running a Scan Type that involves a doing a peak or focus:
     • Balance as often as you do for your science. That is, if you are going to rebalance the power levels after the peak and focus are run, then you should also balance the power levels for the peak and the focus. If, however, you are not going to be rebalancing for your science, then do not rebalance for the peak and the focus. Note, though, that is you chose a different IF filter for your peak and focus, which may be done, for example if you run the AutoPeakFocus Scan Type or for RFI mitigation, you will need to rebalance between configurations. Be aware, though, that if you chose not to balance when running the peak and focus, you may saturate the backend, particularly at lower frequencies. Additionally, the choice to not balance make put your peak and focus results into the nonlinear regime of the backend or IF Rack, thereby making the observations unusable for gain/SEFD curve determination. Finally, if this is your first observation of your run, then you should of course balance before the observation.
   • When running pulsar observations:
     • For Pulsar Spigot observations, you must balance the whole system (from frontend to Spectrometer) when you get to your first science source (or "test" pulsar). Additionally, you should balance the IF Rack every time you move to a new source that is relatively far away on the sky (say, more than a couple degrees). For long tracks, you should probably use the SpigotAutoLevelerStart Observing Directive (don't forget to use SpigotAutoLevelerStop as well), which adjusts the power levels going into the Spectrometer at a user-specified rate.
     • For most additional pulsar observations, you should only need to balance the IF Rack when changing sources that are more than a few degrees apart on the sky.
2. Significant power within beam when on source (e.g. the median power level of the observations takes you out of the good response limit of your backend)
   • When doing spectral line science observations:
     • Find the half power point - Balance the IF Rack and backend off source & remember the settings. Then, balance the backend (or attenuators closest to the backend on the IF chain) on source & remember those settings. Split the difference between the high and low settings and set the attenuators closest to the backend on the IF chain to those values. Do not change these settings until either you change sources or the backend power levels become unacceptable. Note that changing the first variable attenuator upstream of the backend is most likely the preferable place to make the attenuation change. This will leave the backends balance point at the half power level.
   • When running a Scan Type that involves a peak or focus:
     • Do not rebalance unless you are about to move to a new science source. This means you should NOT use the AutoPeak, AutoFocus, or AutoPeakFocus ScanTypes, as they change your configuration, and doing so requires a power level balance.
   • When running pulsar observations:
     • Rebalance if you move to any new source with significantly less flux density or if the source is more than a few degrees away on the sky.
3. The total bandwith between the lowest & highest frequency channels of backend is large:
   • Spacing greater than 1.2 GHz might be considered large, because that forces the users to select the all pass filters in the IF Rack. When setting the signal level through the fiber IFs, we have to consider both the noise spectral density (dBm/Hz), and the total power (dBm). The density needs to be kept well above the noise level of the laser/photodiode combo (~45dB noise figure!), yet well below the power compression levels of the driving microwave amps for linearity/intermod considerations. We've tried to simplify things for the user by rolling all these considerations into the one voltage output by the TP detector and a couple of target levels. But the careful user can successfully push the envelope as has occasionally been done by spectral line observers running several dB above the 10V limit of the IF Rack detectors. It's important to realize that the TP detectors have a sudden absolute limit at 10V (via a clamping diode), but the microwave analog chain going to the Equipment Room has more gradual degradation. We could consider adding more smarts to the software to, for example, calculate the noise density based on the signal bandwidth and detected power, and either display the result WRT the noise floor or factor it into the balancing algorithims. And we could use different target levels depending on the bandwidth and whether the observation is using the rack TP detectors or a downstream backend. Depends on how complicated we want to get.
   • The solution for this, agreed upton at the 27 July Observing Issues meeting is that we should develop balance functionality that goes from 0.5 to 5 V (by default) on the IF Rack to bring the power levels on the backend to an acceptable level. If it cannot get the needed power by doing this, a message will appear stating this. The observer could then choose to re-run the balance with different voltage minima or maxima (acknowledging in the process that she is entering the non-linear regime). A couple of additional suggestions were raised:
     • When running this routine, the Analog Filter Rack power levels should be used to insure you have enough power before resorting to the Spectrometer duty cycles, which are mush slower
     • If the IF Rack cannot get enough power, is would be useful to send a message to the screen suggesting the current optical driver be put into the bad devices file and a new optical driver be tried.
     • The nonlinearity of the IF Rack needs to be well documented so that observers understand the choice they are making

Good ranges for the hardware

1. Prime Focus receivers
   • The power levels for the Prime Focus receivers should typically be between 0.5 - 5.0 volts. Outside this range the response is nonlinear.
2. IF Rack & DCR (Digital Continuum Receiver):
   • The good range is between 0.5V - 5V. Outside of this range you can have a nonlinear response. As mentioned above, the microwave analog chain to the Equipment Room is linear to within 1% to 10V and degrades to 1dB (~20%) 10dB above that level. When we finish upgrading the ODM's with better amplifiers (should be completed this summer), the gain linearity is better than 1% over the entire range of the square law detectors. Gain compression begins to be just detectable at a 10V (+6 dBm power out) reading from the square law detectors. The square law detectors are another story; They have variances, depending upon the particular device, and are accurate to within 1% up to about a 5V reading. Some are better than others and are accurate over a larger range (1% at 9 V). Of course one could think of situations where some out of band interference may drive the first amplifier into saturation, while the second amplifier is "protected" by the filters in the ODM. These scenarios are too numerous to document, obviously. The limits stated apply to the rack Total Power detectors - DCR observations.
3. Spectrometer:
   • You should be within 1.5dB of the ideal power point. More information on the noise levels to expect if you deviate from the good range can be found in Rick Fisher's document, available at http://www.cv.nrao.edu/~rfisher/sampler_xfer_fn.ps
4. Spectral Processor:
   • The optimum value is -6 dbm. See baseline report summary, section 5.1 for a description of how the optimum value was derived.

Other Issues for Discussion

1. Would it be useful for the astronomer to be able to choose to balance the various devices through out a scan as well as pre-scan?
   • Overall, though, this can already be done with the Balance Observing Directive. And while this is not the best idea, particularly for spectral line observers, we should allow the ability to balance/tweak the attenuators of any individual peice of hardware during a scan.
2. What is the ideal method for dealing with balancing in the presence of (strong) unknown RFI?
   • All automatic balance mechanisms should have the ability to sample the power levels a number of times in order to determine the best balance level. Ideally, the default would be to sample the power levels 3 times, but the observer should be able to change that number based off his/her RFI environment.
3. A related issue is that balancing when the high cals are firing is inconsistant because the TP can change by several dB between Cal On and OFF, and the balancing algorithims are asynchronous with the cal signal (may only be true when the DCR is in control). Any balancing script should have the ability to have the cals on or off during the balance, with the default being off.
4. Can anyone foresee problems similar to that found in the Spectral Processor (the attenuators having "dead spots" and non-linear areas) or other unique problems that will occur when attempting to balance the converter rack or any other instrument?
   • From RonMaddalena: MarkClark has great experience with the Converter Rack attenuator and their various flaws since he uses them to achieve Spectrometer balancing. In a nut shell, the attenuators are unique in that they have 1/8 dB steps, which is probably overkill. We'll need to decide the accuracy of the desired setting but something like 0.5 dB is a likely number. The steps aren't perfect 1/8 dB, which drove Mark nuts for his software, but relaxing the setting to 0.5 dB should mask this flaw. Another flaw that Mark hasn't 'discovered' is that the CR's samplers you'd be using to assess the target level have a dynamic range problem. They read zero long before they should. This flaw reduces the usefulness of balancing the Converter Rack under some situations. Galen has plans, but no money or time, to replace these samplers.
   • From RogerNorrod: Yes, the converter rack detectors are not much use, except for rough indication. Any balancing algorithims should not use them, but use power measured at a downstream backend or the Analog Filter Rack. In addition to the detector scaling limitations, note that the signal bandwidth at the Converter module detector is in almost always larger than that at the backends' detectors/samplers.
5. What accuracy is desired in setting the converter rack attenuators?
6. Can the BCPM balance algorithm be fixed so that it truly balances the BCPM, or do we still need it to balance by 1V off?
7. Will we need to support user specified target levels for the various devices? e.g. target of Y for the converter rack AND a target of X for the Prime Focus receivers and a target level of Z for the Spectral Processor?
   • This will not be rolled into a script. If observers have some reason for wishing to observe this way then they can do so with calls to each piece of hardware.

Tools Currently Available for Balancing

1. Within CLEO/Astrid the following hardware can be automatically balanced:
   • IF Rack: Within the M&C system, the IF Rack balances to the input desired voltage. Astrid sets these values to be 3V for the high frequency receivers and 1V for the low frequency receivers. This balances only once, based off the current readings of the samplers.
   • Spectrometer: The Spectrometer balance in the M&C system and Astrid attempts to meet the desired duty cycles - 0.84813 & 1.37578 for 3- and 9-level use, respectively. The choice for these numbers are described in Rick Fisher's document, available at http://www.cv.nrao.edu/~rfisher/sampler_xfer_fn.ps This balances only once, based off the current readings of the Samplers.
   • Spectral Processor: The balance for the Spectral Processor through CLEO is flawed, as the automatic balance button does not always result in the desired power levels being reached, despite the availability of additional attenuation. This problem has been fixed within the config_tool/Astrid version of the balance, which sets the default power levels to -11. This can be overridden with the "target level" option:
     • Balance("SpectralProcessor", {"target_level": 4}) (This balances only once, based off the current readings of the Samplers.)
   • BCPM: The BCPM can be balanced during a "monitor" scan. This sets the internal attenuators to their ideal value.
2. Within CLEO/Astrid the following hardware can be manually balanced:
   • Prime Focus receivers: The Prime Focus receiver power levels can be balanced using the astrid Balance Observing Directive. The following options are available:
     • Balance() -> balance the entire IF path including the PF receiver
     • Balance("RcvrPF_1") -> balances only the PF1 receiver
     • Balance("RcvrPF_2") -> balances only the PF2 receiver
     • Balance("RcvrPF_2", {"sample_time": 2}) -> balances the PF2 receiver with a sample time of 2
     • Balance("RcvrPF_2", {"cal": 'off'}) -> balances the PF2 receiver with the noise diode turned off.
   • Converter Rack: Currently, there is no easy means for balancing the power levels on the Converter Rack. You can, though, add or take away attenuation from a given Converter Rack module using the GetValues and SetValues Observing Directives:
     • attn1 = GetValues("ConverterRack", "CMAttenuator1")
     • SetValues("ConverterRack", {"CMAttenuator1": float(attn1) + 1.0})

Backend Specific Instructions for Balancing

1. CGSR2 observations
   • Balance the receiver (Prime Focus only).
   • Balance the If Rack.
   • Change the Analog Filter Rack 100 MHz converter filters numbered 9, 10, 13, and 14 to the 50 - 100 MHz filter value.
   • Change the Converter Rack CM9, CM10, CM13, and CM14 attenuators so that the power levels in the analog filter rack are at 0.5 - 0.8 Volts.
   • Change the Analog Filter Rack 100 MHz converter filters numbered 9, 10, 13, and 14 back to the external filter setting.
2. Spectral Processor
   • Balance the receiver.
   • Balance the IF Rack.
   • Set the Convertor Rack attenuators so that 0.1 - 0.2 Volts of RF power are present on modules that are in the IF path to the used inputs of the Spectral Processor.
   • Balance the Spectral Processor

Changes Needed to implement above scenarios ( OUT OF DATE - IGNORE )

This section is out of date and superceded by the MR section above!

Listed in implementation order:

1. Need the ability to set the desired power levels for the Converter Rack and balance to those levels. (ModificationRequest4C505)
2. Need ready ability to tweak all attenuators from within Astrid both after and during observations. This includes both adding/subtracting attenuation, querying the attenuator values and sampler values, and setting the attenuators to a given value. These should be very simple balance functionality, and the observer should not need to know the details of her IF chain. E.g. if you are running the BCPM and want more power in channel 2, she should be able to just say so, and not need to refer to the Converter Rack or IF Rack number. On the other hand, anyone running a user-supplied (not GB staff supported) backend will need to be able to refer to specific peices of hardware (e.g. add 1db attenuation to IFRack 1). (ModificationRequest8C505)
3. The Spectrometer warning messages need to be changed to accurately reflect when an observer should be warned after a balance. (ModificationRequest9C505)
4. All balance functionality should allow the observer to turn the cals off (or on) when the power levels are sampled during the balance. The cals should then revert to their pre-balance state.
5. All balance functionality should have the ability to sample the power levels more than once, to avoid RFI effects. The number of times the sampling occurs (default=3) and the time to wait between sampling (default = 1ms) should be changable by the observer.
6. Need an observing script to implement the balance mode described in Scenario 2, spectral line, above, as well as sufficient test time to develop the needed documentation
7. Need an observing script to implement the mode described in Scenario 3, spectral line, above, as well as sufficient test time to develop the needed documentation
8. Need to change the error messages output from the IF Rack - IF power text