Hi Cees, On Mon, Jun 1, 2020 at 5:30 PM C. Bassa <cgbsat_at_gmail.com> wrote: > Hi Andreas, > > Apologies for the delayed response; your email got flagged as spam and > only just saw the email in my spam folder. > heeee, that was not intended to be spam :). And no worries, I am not in a hurry. This is for the long run until I understand everything better. > > On Thu, May 28, 2020 at 10:28 PM Andreas Hornig > <andreas.hornig_at_aerospaceresearch.net> wrote: > > When I understand you correctly, you took my IODs and plotted that on > the starmap. Then you found the right satellite and took the TLE and also > plotted that on the starmap. What I did not understand yet is how you > calculated thte 1.5 seconds. You selected one of my points and checked when > the satellite on the TLE propagation path is closest to my point, and then > checked the timestamp of the TLE and compared it to my IOD timestamp? > > Yes, that's about it. For a given measurement (position at a certain > time) and a corresponding prediction (slightly different position at > the same time), you can compute the positional offset parallel to the > direction the satellite is moving, and perpendicular to its motion. > The parallel offset can be converted to a time offsets using the > angular motion of the satellite. > Okay, good. I convert my measurements to vectors first (from center of earth to assumed sat position). My code is currently only using that as inputs. Maybe I should try to directly use my angles-only measurements. > > > Why did you use a circular orbit? Just for a quick check? > > With data from a single pass it is impossible to determine all > parameters with enough accuracy. Several of the parameters will be > degenerate, meaning that they are correlated. Only with data from > multiple passes can you independently constrain all orbital > parameters. In this case, a circular orbit is the easiest guess as it > only requires 4 instead of 6 orbital parameters. Furthermore, a > circular orbit is the first guess for any satellite. Looking at the > 15258 satellites in LEO (mean motion larger than 10 revs/day), 10580 > have eccentricities smaller than 0.01. > Yeah, makes sense. My current result is what you see here https://photos.app.goo.gl/5UWRsxXKGv5fcxXi9 After 60 iterations with my solver it seems it has run into its assumed result. The perigee is okayishly close to the result, but the apogee is still too far away :). For comparison, I also included the TLE parameters from 2020, 4, 20, 6, 48, 32.13061362504959 into the graphs. So at least the time after perigee pass will be different, because mine is calculated after the previous one, which was not the one from the TLE. > > > When I will be at this point, I will try to get a fit with an eliptical > orbit. > > Like I said above, without data over a significant part of a single > orbit, or over multiple orbits, you are unlikely to get meaningful > constraints when fitting for eccentricity. > yes. I would also need more measurements for my test, as you can see here https://photos.app.goo.gl/5UWRsxXKGv5fcxXi9 unfortunately I do not have more (yet) from starlink and I also find it really difficult to find the same satellit again on th photos :D. But I will try to find observations on this list of the same (other) satellite with different revolutions or observation locations. That should work better. > > > Did you directly take Ra/Dec for your fitting? I intend to use the > position vectors I get from the Gauss Method. > > Yes, my method takes a set of orbital parameters and computes > predicted RA/Dec values for comparison with the observed values, and > tries to minimize the positional offsets. > > awesome :). So far, my code works okayish, but slow. But that is my coding :D. If someone has Starlink observations from the same starlink sat from different orbit revolutions or times, it would be great to get this for my tests. Best regards, Andreas _______________________________________________ Seesat-l mailing list http://mailman.satobs.org/mailman/listinfo/seesat-lReceived on Sat Jun 06 2020 - 17:44:44 UTC
This archive was generated by hypermail 2.3.0 : Sat Jun 06 2020 - 22:44:44 UTC