Explanation of weird values in New Horizons data?

Question

In this answer I computed (methods given later in post) the estimated time, distance, range, and resolution for the science capture for New Horizon's closest approach to Ultima Thule (2014 MU69).

While looking through the images on APL's website I noticed a discrepancy in one set of values. Specifically, the numbers given for Range for all of the LORRI images from Ultima Thule on that site appear to be about 6.5 times too large bear no relation to the computed range. All of the rest of my results seem consistent except for that figure. Can anyone explain why I'm seeing a discrepancy?

An image detail screen with anomolous value highlighted
^{Source: LORRI Images from the Ultima Thule Flyby, NASA/JHU APL/SwRI, linked-to full-size image here
Filter by REQID: KELR_MU69_CA04-MAP_L1_2019001 then look for lor_0408624825_0x630_sci_7.jpg in the results}

To be clear, I'm focusing one image here but I've seen similar for all of the LORRI images at Ultima Thule.

Here's a sample of my results for the time around when the above image was taken. Everything matches except for Range where I get ~28000 km and they list "182,686" (with no units given). For the Pluto encounter they used Mkm so having the units for this be km would make sense. The value they show though is about 6.5 times larger than what I computed. The "range" given doesn't seem at all related to the actual distance (or at least not consistently between image sequences). I tried miles, feet, etc. but nothing (except tenths-of-a-mile) comes close to fitting. Any ideas? Is it in in tenths-of-a-mile? Have I missed something obvious?

Summary of values

Below is a comparison of the values from the above example (taken during CA04) with those I computed (discrepancy in bold):

Value Published Computed
SCET 05:01:47 04:56 to 05:06
Distance not given -31900 to -23100 km
Range 182,686 32100 to 23350 km
Resolution ~140 m/px 159 to 115 m/px

Other images from the Ultima Thule encounter show similar discrepancies.

Here's a comparison with the preliminary schedule for a point during CA04:

Value Published Computed
Time K-2000 s -2209 to -1600 s
Distance ~-28800 km -31900 to -23100 km

Update: The "range" values for the raw images don't appear to be tenths-of-miles. They also don't seem to go in sequence between observation sets (CA01, CA04, etc.) but they do go in sequence within a set. Maybe it's something to do with transmit time or distance?

Image Time Range (raw) Range (processed) Notes
1 2019-01-01 05:01:47 182,686 28000 km/17000 mi Part of CA04 sequence
2 2019-01-01 04:22:19 148,795 61000 km/38000 mi Part of CA01 sequence
3 2018-12-31 09:38:13 826,749 N/A Last approach image
4 2018-12-31 07:02:03 961,979 N/A First "odd" image
5 2018-12-30 16:56:06 2 Mkm N/A Last image with km

• Processed images here or here
• Raw images linked from here:
  1: KELR_MU69_CA04-MAP_L1_2019001 lor_0408624825_0x630_sci_7.jpg
  2: KELR_MU69_CA01-MAP_L1_2019001 lor_0408622457_0x630_sci_6.jpg
  3: KELR_MU69_APROTL_L14_2018365D lor_0408555011_0x630_sci_9.jpg
  4: KELR_MU69_APROTL_L1_2018365A lor_0408545641_0x630_sci_9.jpg
  5: KELR_MU69_ROTCOVER_L1_2018364B lor_0408494884_0x630_sci_7.jpg

My methodology

• Velocity Velocity in km/s relative to closest approach point
  (source data)
  Taken from here (as of 2018-12-31)

  $V = 14.44\ \frac{\mathsf{km}}{\mathsf{s}}$

• Distance Distance in km to point of closest approach
  (source data)
  Estimated from distances shown in the Imaging schedule diagram (see below). Negative for approach, positive for departure. Accuracy is about ±50 km. Note that UT's position is ±4000 km; I ignore this margin of error (assume it to be 0).

  $D = value\ estimated\ from\ diagram$

• Time Seconds relative to closest approach
  (computed value)

  $T = \frac{D}{V}$

• SCET Spacecraft Event Time on 2019-01-01
  Derived from time based on closest approach of 05:33:30 SCET (based on "05:33" from here). Format is hh:mm. JHUAPL gives a more precise value of "05:33:00" which is 30 seconds earlier than what I used in my calculations.

• Field of view For LORRI
  (source data)

  $FOV = 0.29\mathsf{°} \approx 0.005061455\ \mathsf{rad}$

• Closest-approach distance
  (source data)
  Value is currently estimated as 3540 km; value used is 3500 km.

  $D_{min} = 3500\ \mathsf{km}$

• Range Distance in km from spacecraft to 2014 MU69
  (computed value, inconsistent with published values)
  Values shown in table are rounded.

  $R = \sqrt{{D}^2 + {D_{min}}^2}$

  Note that image resolution is computed from this. That result matches the published values.

• Width of view View width in meters on a perpendicular plane at the range of Ultima Thule
  (computed value)

  $W = 2 \cdot 1000 \frac{\mathsf{m}}{\mathsf{km}} \cdot \tan{\frac{FOV}{2}} \cdot R$

• Sensor size LORRI sensor size in pixels for 1×1 mode
  (source data)

  $S = 1024\ \mathsf{pixels}$

• Resolution In meters per pixel
  (computed value)

  $resolution = \frac{W}{S}$

---

Ultima Thule imaging schedule
^{Source: Ultima Thule Flyby Press Kit, p. 25, NASA/JHUAPL/SwRI
(cropped, edges cleaned up)}

Preliminary Ultima Thule imaging schedule
^{Source: Earth-Based Support for the New Horizons Kuiper Extended Mission, p.7, NASA/SWRI
(cropped, edited to remove page number)}

Answer 1

I've looked through your numbers, and they do seem to be correct. The range values included are likely intended to be in km, but seem to be inaccurate. The range values are not official at this point in time, and do not have access to the spacecraft ephemeris data yet. I suspect when that data comes down the range values will be estimated better.

Bottom line, both the range and the distance based on the size give similar values, for the highest resolution photographs, both of which are very far off of the values provided. In fact, the values are obviously wrong, the larger, and therefore closer, picture has a larger range then the smaller target.

Doing some further analysis, I believe the range values are assuming a closest approach of about 01:30 SCET. That is 4 hours off, which just happens to be the 4 hours difference that EDT is from UTC. My guess is that they had the time zone wrong for the range estimates, and never noticed it. Here's a plot of what the data looks like, assuming a negative range after the closest approach. Seems pretty linear to me. I mentioned this to Alan Stern on Twitter, hopefully they can address it.

Answer 2

Update: As of 2019-01-17, the page has been updated with range figures more in line with what you've calculated.

---

According to the JHUAPL website (click on 'Learn more about these images ', for some reason a direct link didn't work), range should be in km:

The following ancillary information is provided for each image posted: the date of the observation in coordinated universal time (UTC) at the New Horizons spacecraft, the exposure time of the image in milliseconds, the name of the target, the range to the target in kilometers (i.e., the distance between the New Horizons spacecraft and the target; for example, 12.1M km means 12.1 million kilometers), and the root filename of the image.

You're deriving the range from the timestamp. Are you sure there's no discrepancy there? I thought it might be a difference between spacecraft local time and received-on-Earth time, but that's not it: you'd be 6 hours out then. A difference of 100,000 km translates to about 2 hours of flight time (at 14 km/s).

Directory and file name in PDS:

They seem to be using the same file name convention on the JHUAPL site. Directory names are not visible.

data/YYYYMMDD_METMET/lor_metmetmetm_0xaaa_ttt_v.sfx

The data are all stored as file pairs of one detached PDS label and one FITS file per exposure. The directory and file names are delimited by underscores and slashes as demonstrated above:

• YYYYMMDD is year, month and day-of-month; METMET is the first six digits of the ten-digit MET clock (Mission Event Time; ~spacecraft seconds since launch);
• lor is the prefix for LORRI data;
• metmetmetm is the full ten-digit MET of the image;
• 0xaaa is the Application (Process) Identifier (ApID) for the telemetry data packet type;
• ttt is either eng or sci for EDR or RDR data;
• v is a version number; (for the UT encounter, this seems to be used to identify image strips that can be stitched together - Hobbes)
• sfx is fit or lbl for the FITS or PDS label file (or file extension on the JHUAPL site - Hobbes)

ApID:

LORRI high-rate image data telemetry APID definitions

         C&DH  binning                                                    
  APID   side  mode    compression type                                   

  0x630    1    1x1    lossless                                           
  0x631    1    1x1    packetized                                         
  0x632    1    1x1    lossy                                              
  0x633    1    4x4    lossless                                           
  0x634    1    4x4    packetized                                         
  0x635    1    4x4    lossy                                              
  0x636    2    1x1    lossless                                           
  0x637    2    1x1    packetized                                         
  0x638    2    1x1    lossy                                              
  0x639    2    4x4    lossless                                           
  0x63A    2    4x4    packetized                                         
  0x63B    2    4x4    lossy