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.

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.

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