Planetary Reference Frames with de440

[YingChangJ]

Hello,
I am playing with moon Planetary Reference Frames function.
The demo code in documentation,

from skyfield.api import PlanetaryConstants, load
ts = load.timescale()
t = ts.utc(2019, 12, 20, 11, 5)

eph = load('de421.bsp')
earth, moon = eph['earth'], eph['moon']

pc = PlanetaryConstants()
pc.read_text(load('moon_080317.tf'))
pc.read_text(load('pck00008.tpc'))
pc.read_binary(load('moon_pa_de421_1900-2050.bpc'))

frame = pc.build_frame_named('MOON_ME_DE421')
aristarchus = moon + pc.build_latlon_degrees(frame, 26.3, -46.8)

apparent = earth.at(t).observe(aristarchus).apparent()
ra, dec, distance = apparent.radec(epoch='date')
print(ra)
print(dec)

This works great, and then I looked quickly at the readme in jpl website: https://naif.jpl.nasa.gov/pub/naif/generic_kernels/pck/aareadme.txt
Binary Lunar PCKs has a 440 version with an approximate time coverage of 1550-2650. So I made some change to the demo code.

from skyfield.api import PlanetaryConstants, load

ts = load.timescale()
t = ts.utc(2019, 12, 20, 11, 5)

eph = load('de440.bsp')
earth, moon = eph['earth'], eph['moon']

pc = PlanetaryConstants()
pc.read_text(load('moon_de440_220930.tf'))
pc.read_text(load('pck00011.tpc'))

pc.read_binary(load('moon_pa_de440_200625.bpc'))

frame = pc.build_frame_named('MOON_ME_DE440_ME421')
aristarchus = moon + pc.build_latlon_degrees(frame, 26.3, -46.8)

apparent = earth.at(t).observe(aristarchus).apparent()
ra, dec, distance = apparent.radec(epoch='date')
print(ra)
print(dec)

there is an error:
segment only covers dates 13447252800.0 through 20514081600.0
which is 2396-2-16 to 2620-1-25. (it should be from 1550 to 2650)

Btw, a quick check of the range

print(ephe)
SPICE kernel file 'de440.bsp' has 14 segments
  JD 2287184.50 - JD 2688976.50  (1549-12-30 through 2650-01-24)

And the time range of moon_pa_de440_200625.bpc is claimed in https://naif.jpl.nasa.gov/pub/naif/generic_kernels/pck/moon_pa_de440_200625.cmt

Thanks a lot
YCH

[brandon-rhodes]

I have created an issue for this interesting case. Let's track progress on it there:

#952

Thanks for the report!