[FOSS-GPS] Question of reference satellite selection

Shaocheng Zhang gnss.zhangsc at gmail.com
Sun Mar 21 08:39:26 EDT 2010


Thank you Michael and John,

Michael's solution is quite good, I think that's how Trimble Office software
"planning" do for the prediction of the available satellites, but I think it
will influence the compute efficiency in real time algorithm. And also, John
told me the method to shift one reference satellite to another, and I will
try to use single difference observation to create equations like Ax=b, and
try fix double difference ambiguities when I need the fixed solution.

Regards and Thank you again.

Shaocheng Zhang
School of Geodesy and Geomatics, Wuhan University, P.R.China
Email: gnss.zhangsc at gmail.com


On Tue, Mar 16, 2010 at 2:01 AM, John Morris <john at coyotebush.net> wrote:

> For long measurements, you will want to shift from one reference satellite
> to another.
>
> As an analogy, double differencing is similar to a surveyor comparing
> altitudes between a set of hills.  You don't know the absolute altitudes,
> but you can figure out how high each hill is relative to the others. To get
> the job done, you pick one hill as your benchmark and define the variables
>       Hill(1)-Hill(benchmark) = x1
>       Hill(2)-Hill(benchmark) = x2
>            ...
>        Hill(benchmark)-Hill(benchmark) = xbenchmark = 0
> Based on your survey measurements you create a set of equations:    Ax = b
> which solves for the relative altitudes.  (Since xbenchmark is zero,  you
> don't include xbenchmark in the equations.)
>
> Now, you decide you want to use a different hill as your benchmark.  You
> need to redefine your variables and find an equivalent set of equations
> based on the new benchmark. It takes some figuring out, but you end up with
> a fairly simple procedure based on the following:
>     xi' = Hill(i) - Hill(newbenchmark)
>            =   [  Hill(i) - Hill(oldbenchmark) ] - [ Hill(new) -
> Hill(oldbenchmark) ]
>            =      xi - xnew
>
> If you are more mathematically inclined than I am, you would see the new
> set
> of equations as a linear transform of the old ones, and you would express
> it
> as matrix multiplication.
>
> A second problem you will encounter with long measurements is the repeated
> gain and loss of satellites. One solution is to assign a separate ambiguity
> variable to each period of time you track a satellite, but over time you
> will create an unlimited number of variables.  To prevent unlimited growth,
> you will need to "eliminate"  lost satellites from the equations.
>
>
>  - John
>
>
>
> -----Original Message-----
> From: foss-gps-bounces at lists.osgeo.org
> [mailto:foss-gps-bounces at lists.osgeo.org] On Behalf Of Michael Tandy
> Sent: Monday, March 15, 2010 4:06 AM
> To: Open Source GPS-related discussion and support
> Subject: Re: [FOSS-GPS] Question of reference satellite selection
>
> Well, you have the almanac and ephemeris for all the satellites you can
> see,
> so you can calculate each satellite's future elevations, right? So you
> could
> do something along these lines:
>
> for x = each satellite visible
>  for time = now to (now+6 hours)
>    calculate satellite x's elevation at time
>    if elevation < 10 degrees
>      print "Satellite x visible until time"
>      break
>    end if
>  end for
> end for
>
> Let's say you started your survey today, at midnight UTC time, that you
> were
> at my location, and that you apply an elevation mask of 10 degrees.
>
> You would see the following satellites, at that time:
> SV 2, elevation 28.76
> SV 4, elevation 13.53
> SV 12, elevation 49.46
> SV 14, elevation 36.90
> SV 29, elevation 51.25
> SV 30, elevation 84.05
> SV 31, elevation 38.94
>
> Those satellites would be above the 10 degree elevation cutoff for:
> SV 2: 1 hour 57 mins
> SV 4: 16 mins
> SV 12: 1 hour 40 mins
> SV 14: 1 hour 7 mins
> SV 29: 4 hours 11 mins
> SV 30: 2 hours 52 mins
> SV 31: 3 hours 53 mins
>
> Hence, if you simply chose the highest elevation satellite (SV 30) it would
> be visible for over two and a half hours, but if you select the right
> satellite it can be visible for longer.
>
> I use the highest elevation satellite because my initializations never take
> anything like two and a half hours!
>
> Hope this helps!
>
>
> On 15 March 2010 09:26, Shaocheng Zhang <gnss.zhangsc at gmail.com> wrote:
> > Dear GPS Developers
> > I am a Ph.D student working on real-time GPS algorithms. Currently I
> > have a problem about the reference satellite selection.
> > As we know, most of the RTK algorithm choose the highest elevation
> > satellite as reference satellite, but when the baseline is quite long(eg.
> > network-rtk), it may take quite long time (may be more than half
> > hours) to get the ambiguity initialized, and during the initialization
> > we don't want the reference satellite changes, otherwise we may need
> > to restart the initialization.
> > So if at the very beginning, we could find the longest session
> > satellite as the reference satellite, it will help us to guarantee the
> > reference satellite will not change before the initialization
> > finished. I read GPStk's source code of "vecsol", it give a solution
> > of project the satellite's velocity "V" to the U direction of the
> > local NEU coordinate "Vu", and take the biggest "Vu" satellite as the
> > reference satellite. I check this method and find it indeed give us a
> > longer session satellite, however, when I check this method for all
> > the available satellite at that epoch, It doesn't conclude that "the
> > bigger the Vu, the longer the following observed session".
> > I am very interested in this method because It's easy to implement and
> > can be use in real-time algorithm. So I am wondering if someone can
> > explain this method in a mathematical way, or give a better solution.
> > Thanks in advance.
> > Regards.
> > Shaocheng Zhang
> > School of Geodesy and Geomatics, Wuhan University, P.R.China
> > Email: gnss.zhangsc at gmail.com
> > _______________________________________________
> > This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
> > Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
> > subscription For more information, check
> > http://wiki.osgeo.org/wiki/FOSS-GPS
> >
> >
> _______________________________________________
> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
> subscription For more information, check
> http://wiki.osgeo.org/wiki/FOSS-GPS
>
> _______________________________________________
> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your
> subscription
> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/foss-gps/attachments/20100321/5a3d520c/attachment.html


More information about the FOSS-GPS mailing list