Simulating topocentric right ascension/declination measurements

This is the printout from Find_Orb (which gave the perfect match for the extrapolation, no SRP included):

Orbital elements: J77093E
Perigee 2020 Oct 28.31496 +/- 0.000154 TT = 7:33:32 (JD 2459150.81496)
Epoch 2020 Oct 27.0 TT = JDT 2459149.5 Auto-Find
M 237.84130766 +/- 0.010 (J2000 equator)
n 92.89949141 +/- 0.00295 Peri. 227.37204 +/- 0.0016
a104214.451 +/- 2.21 Node 278.86919 +/- 0.00015
e 0.8779325 +/- 2.98e-6 Incl. 51.77433 +/- 0.000050
P5580.12m/3.875d H 29.1 G 0.15 U 8.8
q 12721.1876 +/- 0.11 Q 195707.716 +/- 4.44
From 16 observations 2020 Oct. 24-27; mean residual 0".31

So the orbital period is 3.875 d (with Orekit I got 3.986) which means I get quite a significant along-track error which is increasing over time. The declination error was smaller, but with 0.7 degrees still by far too large.

The perigee was on 2020 Oct 28.3 (and on Oct 24.4), so we have a perigee right after the first measurement and 0.5 days after our predicted state.

Did you consider 3rd body attraction from Moon in the force model?

That’s a part of my input file:

Force models used by the propagator (only the ones used)

forceModels:
# Central body gravity
gravity:
degree: 12
order: 12
# 3rd body attraction
thirdBody:
- name: “Sun”
withSolidTides: false
- name: “Moon”
withSolidTides: false
# Solar radiation pressure
solarRadiationPressure:
# Estimated solar radiation coefficient
cr:
values: [2.0, -10.0, 10.0]
isEstimated: false
area: 1.0 #13.12

Perhaps you could try to put isEstimated: true for solar radiation pressure cr coefficient?
The values in the file correspond to initial guess (here 2.0), min (here -10.0) and max (here +10.0).
you may also have to test another value for area and set up a value for spacecraft mass (if there is no mass specified in the file, the default value is 1000kg). I guess your SRP is computed here for an area to mass ratio of 0.001 and a cr fixed at 2.0.

Dear Luc,

I have made a number of further analyses including also the measurements that I collected in the last two nights. When I take measurements from 2020-10-24T03:41:01 to 2020-10-28T21:32:06 (4.75 days) and extrapolate to 2020-10-29T21:16:36 (24 hours later), my errors are
0.002 deg in RA and 0.024 deg in Dec (without SRP)
0.047 deg in RA and 0.0002 deg in Dec (with SRP, but a fitted cr of 265! a=10m2, m= 1000kg)
These are reasonable results I would say.

Yet there are a few open points:

  1. in my input file I specified:

    Estimated solar radiation coefficient

    cr:
    values: [2.0, -10.0, 10.0]
    isEstimated: true

Why is the maximum value of 10 ignored and I get a value for cr of 265?

  1. This is the raw data that I have:
    2020-10-24T03:41:01.6224 RA_DEC CAHA 353.1779 49.9396
    2020-10-24T03:41:08.7936 RA_DEC CAHA 353.1865 49.9391
    2020-10-24T03:41:15.7920 RA_DEC CAHA 353.1947 49.9386
    2020-10-24T03:41:22.7040 RA_DEC CAHA 353.2032 49.9382
    2020-10-24T21:02:00.3552 RA_DEC CAHA 288.6868 13.1251
    2020-10-24T21:02:07.9584 RA_DEC CAHA 288.6889 13.1281
    2020-10-24T21:02:15.4752 RA_DEC CAHA 288.6908 13.1311
    2020-10-24T21:02:22.9920 RA_DEC CAHA 288.6928 13.1342
    2020-10-26T23:01:37.1712 RA_DEC CAHA 318.5778 39.6748
    2020-10-26T23:01:51.1680 RA_DEC CAHA 318.5791 39.6754
    2020-10-26T23:02:05.1648 RA_DEC CAHA 318.5802 39.6759
    2020-10-26T23:02:19.2480 RA_DEC CAHA 318.5817 39.6764
    2020-10-27T01:01:48.9792 RA_DEC CAHA 319.5300 39.8817
    2020-10-27T01:01:59.7792 RA_DEC CAHA 319.5320 39.8819
    2020-10-27T01:02:10.5792 RA_DEC CAHA 319.5341 39.8822
    2020-10-27T01:02:21.3792 RA_DEC CAHA 319.5360 39.8824
    2020-10-27T19:31:59.0592 RA_DEC CAHA 343.7607 49.2884
    2020-10-27T19:32:07.3536 RA_DEC CAHA 343.7638 49.2901
    2020-10-27T19:32:15.4752 RA_DEC CAHA 343.7669 49.2918
    2020-10-27T19:32:23.5968 RA_DEC CAHA 343.7701 49.2934
    2020-10-28T21:31:58.2528 RA_DEC CAHA 292.2504 17.6899
    2020-10-28T21:32:06.4608 RA_DEC CAHA 292.2520 17.6920
    2020-10-28T21:32:14.5824 RA_DEC CAHA 292.2535 17.6940
    2020-10-28T21:32:22.7904 RA_DEC CAHA 292.2553 17.6961
    and the measurement which I am only using to check my extrapolation:
    2020-10-29T21:16:35.9328 RA_DEC CAHA 307.1735 31.7847

As you can see, there are always “packages” of 4 measurements separated by just 8 seconds. In my version of NumericalOrbitDetermination it makes very little difference if I take all measurements or if I just take only the first of each package. The results are almost identical.

In Find_Orb, however, I got almost perfect results when taking the first 16 measurements (covering 3 days, no SRP included), but I got similarly bad results as Orekit, when using only the first measurement of each package. And here I am really puzzled. I thought the main problem if you have observed only 3/4 of an orbit, you get necessarily a bad grip on the orbital period (and eccentricity and arg of perigee) and it should not help much if you take one measurement per pass or if you take 4 covering just a time span of 22 seconds. But obviously in Find_Orb it had helped.

Could it be, that some rounding errors in Orekit - when the measurements are very close to each other - prevent that the extra information that is contained in the data points 2, 3 and 4 of each package, is lost? But is there really much extra information? I have really no idea …

Hello @ruediger,

I do tend to think the same as you: four measurements very close should not add much. I don’t think this could come from a rounding error of Orekit though.
Maybe Find_Orb is performing some kind of smoothing with each batch of four measurements, merging them in one measurement and removing some noise in the process? Hence the better results.
Do you know how Find_Orb works under the hood?

Maxime

I have no idea how Find_Orb works (I just installed the executable which has more features than the online version), that’s why I thought I better go for the Orekit way where I can access the full source code. But Find_Orb is quite flexible and even allows to fit the cr of the solar radiation pressure. For the example I posted above the error in the position after 1-day propagation is less than 2" compared to the 80" I get with my Orekit program. No idea how they manage do do that