TL;DR Looking for ways to get accurate pointing TLE despite good observations on SATNOGS.
Hi all, our team has been recently having issues with tracking our satellite, 57487 NuLIoN. Our satellite is currently orbiting at 465-464km at a 5 degree inclination orbit.
We have been getting good observations with minimal doppler shifts, but when it comes to tracking with a rotator, we find that there are azimuth and elevation offsets that cannot be resolved by our current method of generating TLEs.
Here’s our step-by-step flow for generating a TLE:
- Queue observations for 24 hours on Satnog stations.
- Use Satnogs-Waterfall-Tabulation-Helper to generate DAT files for each of the observations.
- Combine all resulting DAT files into a single DAT file.
- Run RFFIT on the combined DAT file using the old TLE that was used for the latest observation.
- First we fit with no parameter selected.
- Use Mean Motion, Mean Anomaly and Ascending Node to fit.
- Write interim TLE file to storage
- Take interim TLE file and propagate it using sattools/propagate.c to the current UTC time.
- Take propagated interim TLE and run RFFIT with it on the same combined DAT file.
- Same steps as in step 4.
- The resulting TLE from step 6 is our final generated TLE for the day.
We repeat this process each day to generate accurate TLE, but from our one year of handling satellite passes, we notice that we will have to apply a time offset (e.g as the TLE gets older, the satellite position has shifted along track rather than off track). For example, given a brand new generated TLE, each 1.5 hour pass will result in an addition of 1 - 2 seconds of time offset per subsequent pass.
In order to accurately determine the time offset required, say on the next day, we use an SGP4 propagator as well as an Orekit DSST propagator side by side to measure the time of peaks. This is equivalent to loading two TLEs into gpredict and comparing their pass timings. Example, if today was Tuesday and I wanted to know what the time offset would be like on Wednesday, I would follow the following steps.
- Take the TLE from Monday and propagate it from current time until the end of Wednesday. Create a list of all azimuth and elevation observations during the time period.
- Generate a Tuesday TLE by following the step-by-step flow, and propagate it from current time until the end of Wednesday. Create a list of all azimuth and elevation observations during the time period.
- Compare the two lists together. The timing difference in Time of Closest Approach is our time offset, while our azimuth and elevation offsets required can be taken for each future pass.
- Repeat for Orekit DSST propagator.
This was not a big problem for us and it allowed us to properly determine time offset without much hiccups for a good year until recently in May, when our satellite was possibly affected by something (we had our systems rebooted between passes). We recovered it, but noticed that as time went on, the quality of the tracking was beginning to degrade where instead of just an along-track offset (time offset), we were experience off-track offsets(azimuth elevation offsets). Originally it was a small amount, such as -0.1, or -0.2. But these past few days have seen offsets reach -2 or even -4 for azimuth, while elevation offsets are around 0.5 to 0.6
It is hard to tailor all three offsets during a single given satellite pass, especially when its low altitude makes for fairly short passes. I’m trying to figure out a way to improve this process, and I already had a few suggestions.
- Fredy has suggested to also try using rffit to tailor inclination and eccentricity, since they define shape of the orbit that would perhaps help more of the off-track offsets rather than the along-track offsets.
- The waterfall-tabulation-helper’s output is not as accurate as an rfplot into rffft method.
- Use more stations.
We’re working on suggestion 1 now, but fitting eccentricity gives us a error on the rffit output. For suggestion 2, we’re unsure of where the raw IQ data that the satnogs-client records is stored in order for us to use the rfplot into rffft method. right now we use GQRX for that method, but we would like to integrate into our already scheduled SATNOGS observation rather than doing it manually.
Suggesstion number 3 is a bit more difficult due to the nature of our orbit. Unfortunately Spacetrack has not been providing us with an updated TLE since last year December, so we are heavily reliant on SATNOGS for our tracking (we do not have a GPS on the satellite - an oversight for sure).
We’re hoping anyone else who reads this may have some insight or experience to share if you have dealt with any of the problems I’ve mentioned here. If you have read this all the way through, thank you for taking the time to read this. Please do let me know if there is anything wrong with the steps I have taken here. I can provide a flowgraph for clarity on the process as well if necessary.
TL;DR Looking for ways to get accurate pointing TLE despite good observations on SATNOGS.
Here’s our most recent observation for reference.
