I have created some synthetic data from a numerical propagation using Orekit. I use the PV coordinates from the numerical propagation and subtract the ground station PV coordinates to obtain a vector from the ground station to the satellite at a given instant in time, and I then take the norm of this to get a value for the range of my satellite at a given instant in time.
I have then added noise to this data to represent the inaccuracies associated with my fictional ground station. I have used the SLR python example as a basis for an orbit determination process and I find that with repeated measurements I can obtain an accuracy of ~10m (normal and across-track) as compared to the initial numerical propagation coordinates. However, I am finding that the error along-track is always 30m ± 10m depending on where in the orbit the satellite is.
I expect greater error along-track but I am suspicious that the value is always 30m as this is roughly the distance travelled by my satellite in the time for a signal to be emmitted from the station, reflected off the satellite and back to the ground station.
Am I correct in thinking that the Range() function that I am using makes corrections for the time-of-flight and updates the arrival time of the photons accordingly? If so, how does this work, and is there any way for me to disable these corrections to see if this reduces the error I see in the along-track direction? I understand that this is not physical and for that reason probably isn’t a configuration option but thought I would ask (I am using Python btw). I guess the alternative would be for me to add in time-of-flight to my ranging measurements rather than using an instantaneous range value?
Thanks in advance!
You are right, the
Range measurement does include time-of-flight.
You cannot ignore it, but in fact if you want to create synthetic data you should not do it as you did. The synthetic data should include the time of flight, and it should also include other effects like tropospheric delay, ionospheric delay and even more fancy stuff like clock offsets.
All this is already available in Orekit which provides measurements generation methods. Look at the measurements generation section in the documentation.
This feature allows you to consider all the measurements modifiers supported by Orekit (like the various delays I mentioned abvove), and also to take into account the scheduling stuff (performing measurements only when visibility is ensured).
I forgot to mention that the measurement generation feature also supports adding simulated measurements errors, both random noise and constant biases can be generated.
It also allows generating measurements aligned with some time scale (like every whole minutes in UTC) within the feasibility periods (like visibility from ground station).
Hi Luc, Paul,
There may be some good reasons for not including light time delay. I’m guessing, though I haven’t measured, that including light time delay takes some significant additional computational time. According to Montenbruck and Gill using the average of transmit and receive times for two way measurements accounts for light time delay to first order. Is the second order light time delay worth the extra computational time? That seems like a valid trade-off to make for simulations or if the measurement errors are large. Perhaps a simple range class without light time delay would be a useful contribution.
Thanks for your speedy replies! I didn’t realise Orekit had this functionality already - I wonder what else I haven’t stumbled across yet! I’ve now switched over to using the generator approach and I get much better precision in the along-track direction so it was the transit time issue.