Uploaded image for project: 'Commissioning Activity Planning'
  1. Commissioning Activity Planning
  2. CAP-816

High-Frequency Data Array Timestamp Definition

    XMLWordPrintable

Details

    • Task
    • Status: To Do
    • Blocker
    • Resolution: Unresolved
    • None
    • None
    • None

    Description

      The only "time of read" timestamp for most/all data-arrays is from a single time (such as cRIO_timestamp).  We apparently need to establish a better way of defining how to unpack these sequential data arrays to re-construct the time-stream telemetry (for example to rendezvous with other EFD telemetry).  Certainly can be done by hand, but we need this to happen with minimal effort for most end-users.

      Attachments

        Issue Links

          Activity

            mareuter Michael Reuter added a comment - - edited

            What this means is that the cRIO_timestamp attribute needs to be a packed array like the other data. This means a change to the interface XML. Then once the interface is available the LabView code needs to be changed to provide a measurement time for each data point in the packed array. I'd recommend this for the AT related data that uses the packed arrays.

            mareuter Michael Reuter added a comment - - edited What this means is that the cRIO_timestamp attribute needs to be a packed array like the other data. This means a change to the interface XML. Then once the interface is available the LabView code needs to be changed to provide a measurement time for each data point in the packed array. I'd recommend this for the AT related data that uses the packed arrays.

            C++ code needs to be changed for VMS. I can do that.

            pkubanek Petr Kubanek added a comment - C++ code needs to be changed for VMS. I can do that.
            cslage Craig Lage added a comment -

            I did a little more work on this. On the AuxTel, there is lsst.sal.ATMCS.logevent_target data, which is non-packed data which is the target that the mount is aiming for. We can then compare this to the packed lsst.sal.ATMCS.mount_AzEl_Encoders data and ask how much we have to shift the packed data so it lines up with the unpacked target. The answer is we have to shift the packed data about 1.67 seconds earlier. Then everything lines up nicely, at least within the error I can see. See the plots below, made by this notebook: https://github.com/craiglagegit/ScratchStuff/blob/master/notebooks/Plot_Tracking_UTC_08Nov21.ipynb

            cslage Craig Lage added a comment - I did a little more work on this. On the AuxTel, there is lsst.sal.ATMCS.logevent_target data, which is non-packed data which is the target that the mount is aiming for. We can then compare this to the packed lsst.sal.ATMCS.mount_AzEl_Encoders data and ask how much we have to shift the packed data so it lines up with the unpacked target. The answer is we have to shift the packed data about 1.67 seconds earlier. Then everything lines up nicely, at least within the error I can see. See the plots below, made by this notebook: https://github.com/craiglagegit/ScratchStuff/blob/master/notebooks/Plot_Tracking_UTC_08Nov21.ipynb

            I just realized this is assigned to me. I still don't think this should be the responsibility of the lsst_efd_client package since it's inherent to the system, not a data handling issue. I guess I could add some mechanism to include an offset factor per topic, or something, but I would be very uncomfortable defaulting that.

            krughoff Simon Krughoff (Inactive) added a comment - I just realized this is assigned to me. I still don't think this should be the responsibility of the lsst_efd_client package since it's inherent to the system, not a data handling issue. I guess I could add some mechanism to include an offset factor per topic, or something, but I would be very uncomfortable defaulting that.
            cslage Craig Lage added a comment -

            I agree. I thought the agreed-upon fix was to add a timestamp for each datapoint in the packed array, as mareuter suggested above.

            cslage Craig Lage added a comment - I agree. I thought the agreed-upon fix was to add a timestamp for each datapoint in the packed array, as mareuter suggested above.

            People

              krughoff Simon Krughoff (Inactive)
              bstalder Brian Stalder
              Angelo Fausti, Brian Stalder, Craig Lage, Dave Mills, Michael Reuter, Petr Kubanek, Robert Lupton, Simon Krughoff (Inactive), Stratejos Slack Intergration bot
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

                Created:
                Updated:

                Jenkins

                  No builds found.