This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
operations:pointing [2011/07/05 02:55] Jim Lovell [Version 3.4] |
operations:pointing [2013/02/20 22:01] Jim Lovell [Obtaining a pointing model with the PCFS] |
||
---|---|---|---|
Line 1: | Line 1: | ||
====== Antenna Pointing Solutions ====== | ====== Antenna Pointing Solutions ====== | ||
+ | |||
+ | |||
===== Reduction of observations and producing a model ===== | ===== Reduction of observations and producing a model ===== | ||
+ | |||
+ | There are two methods of producing a pointing model for the 12m antennas. There's the 'old' way using octave scripts and the power sensor or the 'new' way using the built-in PCFS pointing routines. The 'new' way is recommended because the Field System no longer uses the pointing model in the antenna controller by default. However it's important to keep the pointing models synchronised between the PCFS and antenna controller because some applications (like spacecraft tracking) still require the model in the controller. | ||
+ | |||
+ | The model parameters are implemented slightly differently in the PCFS and the Controller. Here are | ||
+ | some notes on the differences between the internal PCFS model and the model implemented within the controller: {{:operations:model_params_12m_controller_and_pcfs.pdf|Model Param notes}}. Note the sign change in one of the parameters. | ||
+ | |||
+ | |||
+ | ==== Obtaining a pointing model with the PCFS ==== | ||
+ | It's a good idea to allow about 24h of observing to obtain a new pointing solution. Then some additional time is required (a few hours) to confirm that the new solution is working. | ||
+ | |||
+ | - Start up the field system software as usual and make sure the DBBC is set up in a standard R1/R4 configuration. | ||
+ | - It's probably worth using eRemoteControl for this too and setting up the log monitor so you will be alerted if there's a problem. | ||
+ | - The pointing routine will append (or make) a log file called ''/usr2/log/sx.log'' which is later used to make a pointing solution. If this file already exists, consider renaming it so there's a fresh one for the new solution. | ||
+ | - Then, in the field system: <code>proc=point | ||
+ | initp | ||
+ | acquire</code> | ||
+ | - The Field System will then automatically choose a pointing source and determine an offset. It will continue to do this indefinitely for a range of sources. Let it run for 24h. | ||
+ | |||
+ | === During the pointing run === | ||
+ | |||
+ | Lots of messages are produced from the fivpt (pointing) routine. It's worth watching the output (initially anyway) to check it's making sense: | ||
+ | * [[operations:documentation:fivept_output|What does the fivpt output mean?]] | ||
+ | * [[operations:documentation:pointing_monitoring|Monitoring and plotting pointing data]] during a pointing run | ||
+ | |||
+ | === Ending a pointing run === | ||
+ | |||
+ | When you think you have enough data, stop the pointing run in the field system by killing the pointing routines, zeroing the pointing offsets and send the antenna to stow: | ||
+ | <code>kill | ||
+ | azeloff=0d,0d | ||
+ | source=stow | ||
+ | </code> | ||
+ | |||
+ | === Finding a pointing solution === | ||
+ | |||
+ | Open a terminal on the Field System (make sure X11 is being forwarded) then start up the pointing solution GUI: | ||
+ | <code>pdplt &</code> | ||
+ | Load the log file with ''File -> New''. To cycle through the plots use the ''Graph'' menu or ''n'' and ''p''. By default the fit residuals are shown but you can also plot the raw data under the ''Data'' menu. Obviously bad data can be flagged by clicking on points. To remove outliers automatically, try the ''Edit -> x-sigma'' option to remove points more than a specified number of sigma out. After flagging points, you can use the ''Edit -> Reprocess'' option to re-fit the data. If necessary, do some more flagging and reprocess. | ||
+ | |||
+ | The ''Edit -> Modify Parameters'' option lets you control how and which parameters are used. The default (params 1 through 8 and number 23 set to 1, the rest 0) seems to work well. Note that parameters 15, 16, 17 and 18 (frequency 2 tilt) have been used at the GSFC 12m to improve the solution. However, it's worth producing a solution using the default parameters too because this can be copied to the controller (which doesn't support the other parameters). | ||
+ | |||
+ | The ''Statistics'' menu shows you how good the fit is. | ||
+ | |||
+ | When you are satisfied with the pointing solution: | ||
+ | <code> File -> Save </code> | ||
+ | This will save two new files in ''/usr2/log''. The ''xtr'' file contains the data which can be re-loaded and reduced if necessary. The ''err'' file contains the new model: look for ''new_model'' in the file. | ||
+ | |||
+ | === Updating the pointing model === | ||
+ | To update the pointing model (which will go into ''/usr2/control/mdlpo.ctl'') use the ''update'' command. If the new model is called err2013.043, type | ||
+ | <code>update 2013.043</code> | ||
+ | Then check the new file to see if it's been updated. | ||
+ | |||
+ | To copy the model into the controller, use HMI | ||
+ | ==== Obtaining a pointing model with the Power Sensor ==== | ||
+ | |||
An octave script (fitter.m) is available for reducing scans made using "ramps" in the HMI controller and the "monochanstart.sh" scripts in ''~oper/Agilentu2k/''. The monochanstart.sh script reads from the power sensor and writes it to a file - usually ~oper/Agilentu2k/sensordata.txt. To use the script, start octave and run ''fitter'' from the command line. You will be prompted for a file name and the mjd day and seconds of the scan. The output is the amplitude (in dB), the FWHM and central location (in seconds). To best use this, scans made using a ramp where the nominal position is reached at a defined epoch are recommended as this allows for simple estimation of the pointing offset (fitter central location - ramp epoch)*(ramp rate in degrees/sec). The script is made up of three files - fitter.m, fittererr.m and julday.m and requires the debian packages octave, octave-io and octave-optim to be installed. | An octave script (fitter.m) is available for reducing scans made using "ramps" in the HMI controller and the "monochanstart.sh" scripts in ''~oper/Agilentu2k/''. The monochanstart.sh script reads from the power sensor and writes it to a file - usually ~oper/Agilentu2k/sensordata.txt. To use the script, start octave and run ''fitter'' from the command line. You will be prompted for a file name and the mjd day and seconds of the scan. The output is the amplitude (in dB), the FWHM and central location (in seconds). To best use this, scans made using a ramp where the nominal position is reached at a defined epoch are recommended as this allows for simple estimation of the pointing offset (fitter central location - ramp epoch)*(ramp rate in degrees/sec). The script is made up of three files - fitter.m, fittererr.m and julday.m and requires the debian packages octave, octave-io and octave-optim to be installed. | ||
Line 197: | Line 253: | ||
===== Yarragadee 12m model ===== | ===== Yarragadee 12m model ===== | ||
+ | ==== Version 1.5 ==== | ||
+ | |||
+ | Model v1.4: | ||
+ | <code> | ||
+ | P1 -0.0243 | ||
+ | P2 0.0036 | ||
+ | P3 0.0165 | ||
+ | P4 0.0110 | ||
+ | P5 -0.0074 | ||
+ | P6 0 | ||
+ | P7 0.9540 | ||
+ | P8 -0.0580 | ||
+ | P9 0.0021 | ||
+ | </code> | ||
+ | |||
+ | Elevation encoder offset (1.20.21) is currently -50067 = -5.0067 deg. Manual says this is ADDED to the encoder outputs. | ||
+ | |||
+ | So the Real el encoder angle is indicated minus 5.0067 deg. | ||
+ | |||
+ | The pointing model has an additional 0.954 deg correction. In this case though it means that the demanded position should be 0.954 deg higher than indicated. In other words | ||
+ | the new Encoder offset should be -5.0067 - 0.9540 = -5.9607. So new encoder parameter should be -59607 | ||
+ | |||
+ | |||
+ | Current low soft limit 20.22 = 60000 = 6.0 deg\\ | ||
+ | Current high soft limit 20.23 = 885000 = 88.5 deg | ||
+ | |||
+ | |||
+ | Notes on what was done to update the model: | ||
+ | |||
+ | |||
+ | |||
+ | Elevation Encoder offset. | ||
+ | |||
+ | 1. The current Elevation encoder offset is −50067 = −5.0067 deg. It should should be −59607 as we’ve accumulated another 0.954 degrees since it was last changed. | ||
+ | 2. This change must be made at the controller in the pedestal on the Elevation encoder module: | ||
+ | a. Put the controller in STANDBY | ||
+ | b. Navigate to parameter 20.21 which should be the Elevation encoder offset and should read −50067. | ||
+ | c. Press the “M” button to enter the editing mode and change the number to −59607 using the elliptical button with the arrows on it | ||
+ | d. Press “M: again to exit edit mode. The upper display (parameter number) should be flashing. You’re now in “temporary parameter” mode | ||
+ | e. Press “M” again to return to Status mode | ||
+ | 3. You now need to save the above change. Navigate to parameter 0.00 on the El controller module and edit it as you did in step 2, except make it’s value 1000. | ||
+ | 4. After editing and saving, cycle the power to the controller, then go back to 20.21 and make sure it still has the new value. | ||
+ | |||
+ | Lower Elevation Soft Limit | ||
+ | |||
+ | The procedure for changing this is the same as above except you’re changing parameter 20.22 which is currently set to 60000 (6.0 deg) to 50000 (5.0 deg). | ||
+ | |||
+ | |||
+ | New model is | ||
+ | <code> | ||
+ | Model v1.5: | ||
+ | P1 -0.0243 | ||
+ | P2 0.0036 | ||
+ | P3 0.0165 | ||
+ | P4 0.0110 | ||
+ | P5 -0.0074 | ||
+ | P6 0 | ||
+ | P7 0.0 | ||
+ | P8 -0.0580 | ||
+ | P9 0.0021 | ||
+ | </code> | ||
==== Version 1.4 ==== | ==== Version 1.4 ==== | ||
Line 312: | Line 429: | ||
Az 20.21 = -1141 (i.e. -0.1141 deg) | Az 20.21 = -1141 (i.e. -0.1141 deg) | ||
</code> | </code> | ||
- | |||
- |