Here are a few hints, but I’m not sure it will help, some are even minor details.
When you build the
OneAxisEllipsoid, don’t get the equatorial radius from the gravity field, but rather use the constant from the same place you get the flattening (i.e.
Constants.WGS84_EARTH_EQUATORIAL_RADIUS). The radius in a gravity field, is basically a scaling factor related to dynamics. It could have been chose by gravity field designers to any value, even one not really related to geometry. The radius used to build
OneAxisEllipsoid on the other had is a geometric model that precisely defines a reference shape.
Instead of an empty
InputParameters for atmosphere model, you could switch to Orekit version 10.2 and use the new
CssiSpaceWeatherData that was contributed by Clément in this version, it will use up to date flux (and of course you should also update the flux data somehow by yourself).
In the frame transform, you could void calling
getTransformTo twice, just save the transform (or better save the full transormed PV) rather than recomputing everything and extracting once position and then velocity. This is just an optimization, the result will not change at all and your implementation of frame transform seems fine to me.
I am wondering were the velocity in vxList, vyList and vzList comes from? Are they already present in the file you loaded? Do you compute them by finite differences from positions in the file? If they are present in the file, there may be a glitch as velocity in ECEF may be computed either as velocity wrt inertial frame projected to ECEF by just using a rotation or velocity wrt inertial frame transformed to ECEF by applying both rotation and velocity composition so they are really velocity wrt Earth frame. Here you assume the velocity are expressed wrt Earth frame and you convert them back. If they were in fact inertial velocities just rotated, then to get the inertial velocities back you should do it differently (i.e. call
transform.transformPosition on the position part and
transform.transformVector on the velocity part to prevent Orekit to include velocity composition). I don’t think there is a problem here however, you most probably did the transform the right way because if you didn’t, you would have really inconsistent results. If you computed the velocities by finite differences from position-only ECEF data, then this would probably introduce some inaccuracies. The velocity data would really represent velocity wrt ECEF (which is good and corresponds to what you transform back to inertial frame), but they would include interpolation errors that would skew the orbit slightly. So if in your file you have only position (or if you don’t trust the velocity that is present), then you should probably better ignore the velocity and feed Orekit only with
Position masurements, not
PV measurements (then back to the initial posts in this thread: you’ll have to add support for
Position in the tutorial).
If your data include only
PV measurements and you don’t trust some of them more than the other ones, the weight is irrelevant, you could scale all of them up or down by the same factor without any effect. Weight is only important when you mix data with different trust levels, this factors allows you to hint the optimizer to use more some measurements than other ones. It is rarely used. In most cases everybody will just use the default weight set to 1.0 and only use the measurements sigma as a way to normalize measurements.
The sigma should (roughly) represent the standard deviation of the measurement errors. If your data comes from a GNSS receiver, you probably have a data sheet from the manufacturer. You should typically expect meter-level sigma if it uses only code measurements, and centimeter-level if it uses phase measurements as well. If you don’t have these information, you can retrieve the residuals from the output of the tutorial printed at the end of a run (look at “residuals σ” for each measurement file in the log).
In the list above, I think the
CssiSpaceWeatherData and the
Position only measurements are the most important ones.