Details
-
Type:
Story
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ts_pointing
-
Labels:
-
Team:Telescope and Site
Description
On TSS-3366 at Tiago Ribeiro's request I changed MTPtg and ATPgt XML to PointingComponent. This ticket is to request that the vendor-supplied code be updated accordingly.
This is also a good opportunity to clean up the XML further. Some issues:
- Item name "localTime" is disallowed because it is an SQL reserved word. See https://confluence.lsstcorp.org/display/SYSENG/SAL+constraints+and+recommendations
- Some of the documentation is dead wrong. For instance parAngle is described as "Local Time (UTC) as a sexagesimal string (HH:MM:SS.SSS)". Clearly a copy/paste error. In another case a parameter named localTime is described as "Local time (UTC)..." which is not self-consistent. But see my comment on time output below.
- Most items need Units to be specified
- Time output would benefit from a major overhaul:
- SAL messages already contain a timestamp for the time at which they were sent. Thus a separate timestamp is only relevant if you need to specify the time at which the data was collected. If the data is slowly varying then the default time-sent timestamp is good enough.
- Many topics send different kinds of time (e.g. UTC, MJD, JD, formatted string versions...) and this is unnecessary and a waste of bandwidth and EFD storage. The whole observatory works in TAI in seconds from the unix epoch, as output by SAL getCurrentTime(). Please only output time information in this format. Note that the computer on which this software runs will be synchronized to TAI using PTP.
One instance where we want time information than TAI is output of earth orientation data In that case all we need is UT1-TAI, UTC-TAI and the TAI at which these are valid. This is a good example of a situation where an explicit timestamp is preferred over the date at which the SAL message is sent, because UTC-TAI is discontinuous and the exact TAI may matter. Technically we could live without UTC-TAI but it's useful to have and provides a sanity check.
Attachments
Activity
On units:
Units appear in the UML model and the PDF generated from the model.
If we also want these in the XML, then the script to generate the XML will need to be modified, since it does not handle this presently.
On having one or two components, see LST-PTG-SDD_v2.2 section 5.9.1, which followed from discussions with me and others who took the time to participate in the design reviews. This specific decision was driven in part by the situation that the neither the interfaces nor the code are completely identical for the two telescopes. The common portions we agreed would utilize common code, however, as described in section 5.9.1.
I think the point here is that the SALPY library can be the same for the Aux Tel and Main pointing components. I did not mean to suggest that the underlying pointing kernel code should be identical.
I suggest we output UT1-TAI and UTC-TAI instead of ever outputting UT1 or UTC directly (along with pole wander x and y – i.e. all the interesting information from the IERS Earth Orientation predictions). The differences vary slowly. UTC-TAI is easy to get by other means, but the pointing kernels probably need to know it and if nothing else, it may be diagnostic to see what the pointing component thinks it should be.
The vendor made a change to their design, see TPC-153. I incorporated this change into the PointingComponent design, see https://github.com/lsst-ts/ts_xml/commit/d66f07e6d7e26fd33139eba522fdfade0815c306
The way both pointing components operates is different enough that this task would not be worth while.
On time:
Local Time (UTC) is a typo and I have reported this issue to the vendor.
UTC is provided in addition to TAI as a convenience for displays (see SYS-ALL-COM-ICD-0037 in LSE-70).
For pointing we do indeed want to provide more specific timestamps than the SAL timestamp. In particular, the timestamp in the demand stream to the mount is by design slightly in the future.
The iers topic already provides dut1.