[INSTRM-1183] Record telescope offsets Created: 16/Feb/21  Updated: 27/May/21  Resolved: 17/Feb/21

Status: Done
Project: Instrument control development
Component/s: ics_gen2Actor
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Normal
Reporter: cloomis Assignee: cloomis
Resolution: Done Votes: 0
Labels: SuNSS
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to INSTRM-1182 Use live telescope status when using ... Done

 Description   

We current just record the "FITS.SBR.

{RA,DEC}" positions in the PFS FITS headers. Those are not the simple slew positions, and clearly include at least some telescope offsets: the values change continuously.

We need to do better. What component offsets are available from Gen2 (guide? manual?) and what are their coordinate systems? What does FITS.SBR.{RA,DEC}

actually represent? Is there a good example we should follow?

eric ?



 Comments   
Comment by cloomis [ 16/Feb/21 ]


In the Gen2 Status catalog eric gave a link to in an earlier ticket, I see STATL.DEC_OFFSET and STATL.RA_OFFSET. Do these describe user-specified offsets?

Comment by eric [ 16/Feb/21 ]

cloomis, Gen2 status values simply make available the coordinates received from the telescope (TCS) in various formats.  The FITS.SBR versions of these are formatted to the sexigesimal format typically used in FITS headers.  Because tracking and guiding both continuously correct the telescope, these values fluctuate in small increments or decrements about the commanded position.  It sounds like what you want is to detect tracking or guiding, with the appropriate dome open status, and then check the commanded position, which does not change until the telescope is commanded to a different coordinate.

The status values for the last command position are FITS.SBR.RA_CMD and FITS.SBR.DEC_CMD

Comment by eric [ 16/Feb/21 ]

As regards the offsets, I will double-check on this, but I believe even if the telescope is commanded by an offset, the commanded values will change to reflect the offsets and so will the instantaneous RA/DEC values.

Comment by eric [ 16/Feb/21 ]

BTW, this is extremely easy to check on the telescope if we have 10 minutes of free time, even if the dome is closed.  Since we are often waiting for darkness with HSC, should be no problem to arrange a quick test.

Comment by cloomis [ 17/Feb/21 ]

Two question:

Is there actually a standard we should follow, or should we record user offsets as internal W_ cards?

  • RA_CMD vs. RA: do you know what the components of the differences between them are? One can guess at some of them, but it would be nice to know,....
Comment by eric [ 17/Feb/21 ]

@cloomis, sorry but I am completely missing the point here. What offsets are you talking about? Dither positions?

Comment by cloomis [ 17/Feb/21 ]

Mainly any user-applied offsets, like what would be applied by the HSC "SetupField ... OFFSET_RA ..." commands.

Comment by eric [ 17/Feb/21 ]

I think you will find that the RA/DEC recorded in the HSC FITS files is with the offset applied.  If the offsets are noted within the instrument-specific keywords, I am not aware of it.  The offsets are given in the phase 2 queue files though.  Probably should have someone from the HSC instrument team answer this definitively though.  Surely, @rhl should know the answer to this WRT HSC files?...

 

Comment by cloomis [ 17/Feb/21 ]

Given that it is in the FITS.SBR namespace, I take it it would be acceptable to add RA_CMD and DEC_CMD to the header cards?

I am inclined to do that, as well as to add W_RAOFF and W_DECOFF just to make those explicit and accessible for those few times we really care.

Noted that we should ask HSC team.

Comment by cloomis [ 17/Feb/21 ]

Added RA_CMD, W_RAOFF etc

ics_gen2Actor merged at 44dc1bf, tagged 1.4.7
ics_actorkeys merged at 7b0d890, tagged 1.4.10

Comment by cloomis [ 27/May/21 ]

This was a total lie: we do not have real info from Gen2

Generated at Sat Feb 10 16:32:44 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.