In the Time Estimation Details the times sometimes do not agree with those in the Time Estimation Summary.

- Implication for user: Minor inconvenience when Time Estimation Details are displayed.

- Recommended action: The times given in the Time Estimation Summary are the ones that should be used.

From HSpot 5.0.4 onwards, the treatment of the spacecraft velocity shift needed on the HIFI Local Oscillator (LO) frequency has been revised. So far, HSpot was only taking care of the shift due to the source velocity entered by the user in the AOR main panel. At the time of submission, the Mission Planning System was using the reference frame provided by the user and did compute the remaining Spacecraft velocity at the time of the observation. For the LSR frame, which is used by most of the HIFI observations, this velocity can be as high as +/- 51 km/s. However, an erroneous truncation did apply in the uplink code used so far, which clipped this velocity to +/- 31 km/s. The effect was only really noticeable in HRS observations, where the intended line could appear mis-centred compared to the sub-band centre, and in the worse cases (at high frequencies) drop outside of the band coverage.

When this error was discovered, the HSC took measures to not schedule observations where this truncation applied so that the effect on observations collected so far was extremely limited. By waiting a couple of weeks usually, the velocity applying to a given observations would fall within the acceptable limit so this also did not force us to delay observations too significantly.

In order to solve this problem, HSpot will automatically shift the LO frequency into the Solar System Barycentre (SSB) frame, in which the Spacecraft velocity is always within the +/- 31 km/s range. In this way, the uplink code will never abusively truncate the intended LO frequency. In effect, this means that beyond HSpot, all observations will be treated in this common SSB frame. Of course this additional redshift will be considered on top of the source velocity that has been entered by the user in the main AOR panel.

There are some important consequences to take note of here:

1.- This shift is NOT date-dependent and only varies on the source co-ordinate. This is why when changing source in a given AOR, HSpot will ask you whether you want to apply the corresponding frequency shift to the existing Local Oscillator setting in your AOR - you should say YES.

2.- This shift does NOT apply to moving targets because the spacecraft velocity with respect to the target will always depend on the date and will be fully computed by the Mission Planning System at the time of observation.

3.- This shift does NOT apply to Spectral Scans because there is not entry for redshift of velocity frame needed in this mode.

4.- Most important: if you re-load an AOR prepared by an HSpot version older than 5.0.4, HSpot will not apply this correction as it will assume that this latter was already applied when the AOR was initially designed. So In order to have this additional correction properly taken into account the frequency setting has to be prepared from scratch in the frequency editor. This means that if you want to re-use AORs that you may have prepared in earlier programs with HSpot version older than 5.0.4, you will have to reset the settings in the Frequency Editor window.

For already existing AORs in the HSC data-base, a bulk correction has already been applied and we will contact each user individually to inform them about the changes.

A serious bug has been found when working with HIFI in HSpot with Linux SUSE 9.1 and the KDE window manager. This bug, which is in KDE, causes system crashes when windows are opened to define HIFI AORs.

- Implication for user: Serious.

- Recommended action: Do not try to run HIFI AORs with this OS/platform combination.

There is a bug in the frequency editor when only the HRS is to be used. In the first (or only, if high-resolution mode is selected) scroll-down menu for the transition, the menu only features the -no line- tab, despite the presence of an available transition in the window of interest.

- Implication for user: the user cannot select the transition of interest in the first HRS sub-band scroll-down menu.

- Recommended action: we can propose two work-arounds for this problem:

i) Select WBS simultaneously, then go to the frequency editor to assign the lines as needed (the bug does not apply then). Go back to the main window, deselect the WBS: the settings are kept for the HRS (please check again the settings in the frequency editor to confirm that they have remained as desired).

ii) The second approach consists of filling in manually the value of the requested frequency in the "Observed Frequency" box (it should turn white when ready to be filled in). Click somewhere else in order to get the chosen frequency applied.

HIFI time estimation can take more than the nominal 10 seconds for AORs of more complicated modes (spectral scans and mapping AORs with OFF positions). In extreme cases a time estimation make take up to a minute. Users should beware not to hit the Abort button too soon!

	Note
	This problem has been greatly reduced since the release of HSpot v3.3 and the situation appears to have improved slightly more since HSpot v3.4, but may still be important on occasions when the system is under heavy load such as before a call for proposals.

- Implication for user: Can be serious. HIFI time estimation may be extremely slow if many AORs must be computed.

- Recommended action: This problem is particularly serious when there is heavy load on the system, but there is no real solution at present apart from exercising patience. The user should be aware of this and try not to run large numbers of time estimates at peak times (e.g. near an AO closure).

For the HIFI load chop with OFF and frequency switch point modes there is the possibility of providing an OFF position that is offset in RA and Dec from the target position. Currently, if the offset reference box is checked then the following two errors are seen.

1.- If any RA offset is used the OFF position does not change its RA but changes its declination position in the visualisation overlay instead.

2.- The target position (on position) is not shown at all.

- Implication for user: Visualisation of AORs does not work correctly. AORs must be hand-checked to ensure that they are correct.

- Recommended action: If an offset in declination only is used then the visualisation is correct.

Time estimations for spectral scan AORs currently will not be given accurately if nominal times (a few minutes) are placed as a time goal to scan a whole band.

- Implication for user:

- Recommended action: Users are advised to use time goals closer to the minimum times needed (3000+ seconds).

When the WBS-only is selected, the best goal resolution possible should be at least 1.1 MHz. However, in the default time estimator window, this value is set at 0.480 MHz, which will result in an error and an explanatory error message. When the WBS-only is selected, the user should adapt the best goal resolution possible accordingly.

- Implication for user: .

- Recommended action:

In the Time Estimation Details the times sometimes do not agree with those in the Time Estimation Summary.

- Implication for user: Minor inconvenience when Time Estimation Details are displayed.

- Recommended action: The times given in the Time Estimation Summary are the ones that should be used.

If an AOR is prepared with a visibility constraint and the AOR is then calculated, when that AOR is overlaid, the constrained visibility windows are retained.

- Implication for user: This is principally an inconvenience.

- Recommended action: This is principally an inconvenience to users but, if it presents a serious problem, the best solution is to select and overlay a different, unconstrained AOR, before switching back to the original to overlay.

There are display issues close to the celestial poles.

- Implication for user: This is principally an inconvenience.

- Recommended action: For AORs very close to the poles we are aware of various issues that are mainly irritations to the user. These do not stop users from preparing AORs in these regions, but grid and AOR overlays should be treated with suspicion as they may be incorrect.

There are some pending issues of relatively minor importance with the display of moving targets. In particular, if you display a moving target with a 3-colour image background the display parameters for the first colour layer are not propagated to other layers, so you must take care to enter the some date for each layer of the image.

- Implication for user: This is principally an inconvenience.

- Recommended action: If working with a three colour plot as background, note down carefully the date that you have choosen to display so that you enter the same date and time for each layer. Alternatively, work with a monochrome image.

Buttons not visible (only in Mac)

Sometimes, depending on the screen resolution, some buttons on the bottom of the AOT window may become cut out and not visible.

- Implication for user: There is no indication about this (no scroll bar is displayed) and the user cannot open an observation estimation window, or do a visibility check. This usually happens if the AOT window cannot use the whole vertical space of the screen, as in cases when there is a dock bar on the bottom.

- Recommended action: To overcome this situation, a way out is to auto hide the dock or change its placement before opening the AOT window. However, this problem should be very much reduced in importance for users in HSpot v5.0.4.

There is a known problem in the system whereby, occasionally, the submission of a proposal may hang silently without returning the pop-up confirming successful submission. This only happens when the system is under heavy load such as closure of Calls for Proposals.

- Implication for user: Inconvenience only.

- Recommended action: If more than a minute passes without the pop-up being returned the proposal submission should be aborted and repeated.