Hello,
I’m new to Orekit and even after searching in the forum, I couldn’t find out how to achieve my current goal.
I have position and velocity data from a GNSS receiver of a satellite and want to get the osculating orbital elements from that time stamp. I’ve read, that it could be achieved with DSST Batch LS Estimator. But I couldn’t quite figure out how to use it.
Could somebody give me a hint on how to achieve this? I would be grateful

By the way, I plan to estimate the mean orbit from the osculating one afterwards. I have already managed that part, it’s just the “GNSS to osculating orbit” part left.

GNSS PVT (Position, Velocity, Time) are by essence osculating so I think you just need to convert the PVT to an orbit. This will probably be a bit crude though.

Suppose you have a PVT from your GNSS receiver TimeStampedPVCoordinates pvt_gnss. Here’s a code to build an orbit from there:

// Convert from GNSS frame to inertial frame (GCRF here)
Frame itrf = FramesFactory.getITRF(IERSConventions.IERS_2010, false);
Frame gcrf = FramesFactory.getEME2000();
Transform transform = itrf.getTransformTo(gcrf, pvt_gnss.getDate());
TimeStampedPVCoordinates pvt_gcrf = transform.transformPVCoordinates(pvt_gnss);
// Build an orbit
KeplerianOrbit orbit = new KeplerianOrbit(pvt_gcrf, gcrf, Constants.IERS2010_EARTH_MU);

You’ll notice that I have assumed that your GNSS PVT is given in ITRF frame but that will depend on what you actually have.
Often GPS measurements are given in WGS84 which is close to ITRF.

Thank you @MaximeJ ,
it works as presented by you.

This actually strengthens the problem I am facing right now.
As I told, I have postion and velocity at a given time from a GNSS receiver.
My goal was to get a mean orbit from this input, which I achieved first with EcksteinHechler and also with DSST.
I have a NORAD TLE from the GNSS data time with a difference less than one minute.
So I want to compare the TLE parameters with the computed mean orbit.
Which in fact matches quite well, except the excentricity.

Here the values:

------------------------a--------------e---------i--------arg. of perigee–raan---------M-------
TLE:_______ 7093.3 km 0.00121 98.2245° ___ 268.07° _ 304.4336° 91.9071°

Comp. Osc. are the values I got from your method to get the osculating orbit.
Comp. Mean are the values I got from DSST osculating to mean method.

Is it a common phenomenon that the computed mean excentricity can highly vary for almost circular orbits in comparison to the official TLE (which is gained by observation)?.
Could the reason be the not considered atmospheric drag in my computation?

Beware that the arguments given in a TLE are mean parameters “in the sense of SGP4/SDP4”, meaning “with the mean model associated with the TLEs”.
You cannot directly compare two mean orbits given by two different models, the underlying mathematics and physics are too different to give you a meaningful result.
So I’m not astonished at all to see that the eccentricity is different.

Yes @MaximeJ , I expected different results. But I was still surprised that all parameters matched relatively good, just the excentricity very poorly.

Unfortunately, I am supposed to:

compare mean orbital elements from GNSS data to NORAD TLEs (for satellite identification in Launch and Early Orbit Phase).

use the mean orbital elements gained from GNSS data for the ground station’s antenna pointing to the satellite for communication.

At this point, I probably have to investigate further in what extend the mean orbit from DSST is usable for antenna pointing.
Or is there a way to use the SGP4 model to get mean orbit from osculating orbit?

Unfortunately no, there’s an issue opened for this on the forge and it’s definitely not a straightforward one.

Do you only have one GNSS measurement?
If not you could try fitting a TLE on these measurements using a TLE-based orbit determination.
And then perform the comparison and antenna pointing based on this TLE.

Thank you for your advices @MaximeJ ,
I indeed have several measurements. I will try TLE fitting then.
I will mark this as solved, as it is solved for the original thread topic.
If I can’t make the TLE fitting run on my own, I will open a seperate thread if needed.

Great
Just one thing (although it must be stressed already in the tutorial), the PV measurements must be given to the estimator in the frame of the underlying propagator.
In your case this will be the TEME frame (and not GCRF as I gave you as example) since it is the frame used for TLE.

Unfortunately no, there’s an issue opened for this on the forge and it’s definitely not a straightforward one

I mean you can use the method stateToTLE but it does not always converge. There’s an issue on that as well, although not directly talking about this and lost in the limbs of gitlab. I’ll edit this message when I find it

Thanks @Serrof ,
stateToTLE worked for me.
Do you, perhaps, have more details about the issue you mentioned? Does it not converge for specific situations?