| Versions |
  |
|
| Author |
 Topic  |
|
Russel
Australia
49 Posts |
 Posted - 24 avr. 2006 : 06:20:47
|
Warning: this is pretty long and hard core.
If you Sirf guys are hanging around, feel free to respond
This is in reference to:
Sirf Binary Protocol Reference Manual (Revision 1.6)
Navigational Library Measurement Data - Message ID 28
My question is, what are the physical meanings of the terms:
Time Tag
GPS Software Time
Pseudorange
Carrier Frequency
Carrier Phase
That is, in technical terms, what is the precise physical model, hardware process and algorithm that underlies these numbers. Or less technically, how raw or cooked are these numbers?
My interest is in understanding the physical processes behind and the correlations between the various contributions to pseudorange. For instance, I'll give two examples.
1. The contribution to psuedorange from what I'll loosely call ephemeris error. How does this correlate between samples of a given number of sattelites and over a given length (but randomly chosen) time sequence.
2. The differences between the temporal frequency distributions of different error sources as expressed in psuedorange. For example, the random-walk type behaviour of the satellite clock versus the less well understood moment-to-moment variation in the ionosphere.
Ok, back to the Sirf pseudorange data:
The Pseudorange term is explained as "This is the generated pseudorange measurement for a particular SV..." and I'm thinking generated? how? My original understanding of psuedorange in these receivers was that a hardware timer triggered an A/D conversion and what you had was a chip number + chip (or code) phase measurement that was more or less linear (in phase terms). Add that to the bit number and so on and you had a raw psuedorange measurement that was understood as being that which was measured at the instant in time determined by the hardware timer (and therefore in terms of the receiver clock). To have this information is vital since I need to model the receiver clock and not just its drfit but its stochastic behaviour.
Then the manual continues.. ".. When carrier phase is locked, this data [pseudorange] is smoothed by carrier phase." And I'm thinking ouch, this number might be irreversibly cooked (unless you guys can tell me this is ok, or there is a simple way to reverse this adjustment.)
Then there is the GPS Software Time. The problem here is, GPS Software Time is kinda vague. Is this an estimate of GPS System Time? Or am I barking up a tree here? What also bugs me is why this number is included at all, in a message that seems to be about providing raw data? Is this number needed at all if I'm interested in the 'real' data?
And then we have 'Time Tag'. Is this just an interesting sequence number, or again, does it have to be understood in order to uncook the Psuedorange term?
Then there is the Carrier Frequency term. Now admittedly this is probably only of use to most people in terms of having a smoother velocity term. My interest is both to do with the ionosphere and the smoothness of the velocity of the satellites. Again, the manual really doesn't say how this measurment is made, and more importantly *when*.
And finally there is 'Carrier Phase'. The same how and when issues apply. Yes I'm aware this has been deleted in the latest firmware, and I'll avoid suggesting what cruel and unusual things I'd like to see happen to marketing people.  .
Apart from that I'm interested generally in how the code correlator/sampling system actually works, and I'm interested in real numbers, like jitter.
Thanks in advance to the brave  |
|
|
Ads
|
|
|
gpspassion
84985 Posts |
Posted - 24 avr. 2006 : 09:32:52
|
Welcome to the forums.
I'll move this to the tehnical forums where it has a better chance of being read, sorry, can't help much in the way of detailed replies with this ;-)
_________________________________________________________________________
Discounts and Assistance/Réductions et Assistance (Club GpsPasSion) / Où commencer? |
 |
|
|
Russel
Australia
49 Posts |
Posted - 28 avr. 2006 : 18:19:48
|
It's not *that* scary, is it?  |
|
|
|
btlen
27 Posts |
Posted - 08 mai 2006 : 10:56:16
|
I'm also curious about the amount of contamination in the "raw" SiRF messages.
But for definitive answers we would need someone to look at the SDK source code for OEM developers who pay for the VIP version. (Assuming they are allowed to tell us ...)
If your interest was in studying the Stocastic Processes of GPS accuracy (in general) then the SiRF chipset might not be suitable.
[The following section doesn't apply to benchmarking the SiRF chipset]
1) "Ephemeris Error" contribution to pseudorange: I'd calculate this, rather than measure GPS pseudoranges that are subject to other errors. The broadcast ephemeris can be compared with SP3 format GPS Ephemeris (available from http://igscb.jpl.nasa.gov/components/prods_cb.html)
- the Ultra-rapid product gives predicted orbits if you need real time data, but for "precise" ephemerides you have to wait a few days.
Geoscience Australia provides RINEX observation files from ARGN (Australian Regional GPS Network) sites for free via the Internet (http://www.ga.gov.au/geodesy/argn/) (http://www.ga.gov.au/bin/data_server/).
These contain Dual Frequency measurements of Carrier phase, P-code pseudorange, doppler frequency, and Signal-to-noise (dB-Hz) as well as (L1 only) C/A code psuedorange measurement for each 30 second epoch. Other countries have their own equivalent service.
Using the RINEX data enables:
2a) Calculation of absolute pseudorange error (the site locations are published)
2b) Calculation of ionosphere correction (from dual frequency P-code pseudoranges)
For clock, troposphere & receiver error contributions ... I suppose we would need more data to assign these, if leaving them lumped together under "misc." is unacceptable.
Satellite clock measurement is available from the same place as the SP3 data, although I haven't had cause to use this data for anything.
As for understanding the SiRF innards, it sounds like what you want is the return of Message ID 5 "Raw Tracker Data Out" (AFAIK only available in the SiRF Star I Chipset)
I only ever read about it in some ancient SiRF Binary protocol manual, before the SiRF Star II introduced Message ID 28 "Navagation Library Measurement Data" and depricated MID5. They refered to a program "calcpsr" ("Calculate Pseudorange" I assume) for determining pseudorange data from raw GPS chip counts & bit numbers given in MID5.
I was never able to find the source code for this program, nor obtain a Star I chipset GPS unit to get any MID5 data to test against. But if your interest was uncontaminated SiRF data, this sounds like the place to start.
Can anyone tell us more about Message ID 5? It seems that the user community aren't completely satisfied with its replacement MID28 either, the documentation just doesn't seem complete to me ...
|
|
|
|
Russel
Australia
49 Posts |
Posted - 08 mai 2006 : 12:31:11
|
Thanks for the response, btlen.
There are actually several versions of the Sirf Binary Protocol reference manual out there on the web. The first one I came across described Message ID 5. It wasn't until later that I realised that my SirfStar III receiver actually uses MID28. Hence my original post. I'm thinking of trying out some unrelated recievers with their own protocols. If anyone has an opinion on how the raw pseudorange data on different receivers compare, do let me know.
I've been using published RINEX data to test my code and get a feel for what kinds of models make physical sense. My biggest hassle is still the 30 second epochs. The same issue applies to the sp3 files which have larger sample times. Which means we lose some information on higher frequency components.
The ionosphere is a complex beast with lots of small scale structure. As an example, have a look at this paper: http://ssp.eleceng.adelaide.edu.au/public/theses/MKThesis.pdf . One effect I'm curious about is how the moment by moment variations in ionospheric delay correlate with the speed at which the ray (line of sight) between the receiver and the satellite moves through the ionosphere. In short, one second epochs are about what I need. The same goes with the second by second (random walk type) drifts in the satellite clock. Can a clever algorithm spot this pattern?
Back to the original topic. I think I now have a good guess at how the Sirf receiver uses carrier phase data to smooth the pseudorange. I rather wish they wouldn't do this but it won't bother me too much. The term 'GPS Software Time' is still not well defined. It could suffer from any number of 'corrections'.
Just like everyone else, I'm interested in knowing just how useful the data from garden type gps receivers are, and just what a 'best effort' fix would look like (given a particular sample time) given less than ideal conditions. That is, no differencing, no L2 data, no carrier phase and no help from ephemeris predictions (remember that the clock variance is still a big term, even in the ultra-rapid predictions - but fortunately its the correlation *between* clocks that matters).
I should also add that I'm working with models that deal with the spatial and temporal distributions of uncertainty in the contribution of each physical process to overal pseudorange error (ow my headache). And then we can ask, hey we have several contributions to error, how do we then assign portions of that error (in each individual pseudorange) to different physical effects such that we minimise the total overall improbability. Each physical process has a model with a unique personality. For instance, the receiver clock error is characterised by having a certain variance over a given time scale, but we have the constraint that the contribution of reciever clock error to each pseudrange is nearly identical (yes, Id still love to know precisely *when* each channel is sampled). Then the troposphere model has an apriori estimate of uncertainty at zenith and then that uncertainty function climbs symmetrically as you approach the horizon. And then the ionosphere even has terms that distinguish its power spectral density from other 'noise-like' terms, and hopefully terms that relate this to the satellite's movement and so on.
Fun fun fun.. Where are you, Carl@Sirf? :) |
|
|
|
Carl@SiRF
USA
157 Posts |
Posted - 18 mai 2006 : 20:18:54
|
I'll have to get GPSPassion to ping me when a topic like this shows up -- sorry I hadn't seen it.
Obviously I need to tread lightly here to stay out of the realm of proprietary information, but let me see what I can say.
Pseudorange data in MID 28 is definitely smoothed by carrier phase when possible. Russel has seen that and it is real. And SS3 does not report carrier phase strictly for business reasons. However, SS2 receivers (using GSW2 software, not XTrac) reports carrier phase data.
Some terms and definitions:
Time Tag: based on an internal timer that is reset when the receiver starts up and simply counts forward. This is used for relative timing only.
GPS Software Time: the raw estimated GPS time of the measurement. If you subtract clock bias from MID 7 you have the true GPS time of measurement.
Pseudorange: measured range to satellite, smoothed by carrier phase. Does NOT contain Iono corrections.
Carrier Frequency: This is an estimate of the Doppler. It can be created from one of two places in the tracking: either the AFC loop that tracks the change in carrier due to changing Doppler and crystal changes, or by using delta pseudorange and the pseudorange measurement interval. The software picks the best available among these two sources.
Carrier Phase: relative measurement of changes in carrier phase between two measurements. Once we achieve carrier lock, we normalize this value to the current pseudorange then track the carrier to update the value. So as long as the measurement is continuous, this is a pretty good, smooth measure of pseudorange based on the carrier phase in the receiver.
In older software we supported MID 5; we don't any more. MID 5 was in different units, but was identical data to MID 28. MID 5 was made in the tracking software from the data being sent to the navigation software. MID 28 is made from that data by the navigation code as it puts the data into a format it needs for navigation purposes.
Ok, that is about the level of detail I can give without giving away the farm here. I am sure you understand that underlying algorithms are quite proprietary, but at this level most receivers work somewhat similarly. Everything else here is more philosophy rather than details.
Why provide GPS Software Time? It is our time of measurement number. Actually, what we compute is time of transmission and range. Time of transmission is of course the bit number, 1 ms cycle within that bit, chip number, and cycle and carrier phase within that chip. But unless I tell you when I think I received that point in time, you can't tell what the range is. So we take the transmission time and received time and the difference we report as pseudorange. But this is simply at the time of measurement -- we don't know the error in our clock yet. So subtract clock bias from the time of receipt and you have the actual GPS time of measurement.
Side issue: our customers who purchase SDK software access do not get details on the measurement process as part of that code. That software is quite closely held by SiRF.
Carl - SiRF Customer Support |
|
|
|
Russel
Australia
49 Posts |
Posted - 18 mai 2006 : 22:13:57
|
I should preface this with apologies in advance for giving Carl a hard time...
Ok well.. first here is a snippet of what I get out of SD:
(I got this indoors while the receiver was tracking only one sat)
(This is a Sirf III)
28,0,0,16,3.18358885669112e+005,2.3285107257e+007,1.7575134766e+004,0.0000000...
28,0,0,16,3.18359885727763e+005,2.3302683369e+007,1.7575080078e+004,0.0000000...
(I trimmed those lines so as to not mess up the formatting on the board)
That third number should be the time tag, and it's zero in every message.
Should I be worried?
Secondly.. the issue to do with GPS Software Time is kinda like this.. At first glance it appears to be the sirf's best estimate of real GPS system time and the differences do look like what you'd expect from an average quartz crystal.
But.. The only way that I know that the software can estimate GPS system time is to already have an estimate of position. And therefore errors in the nav library's positional estimate feed back into GPS Software Time and contaminate anything that I do that uses GPS Software Time.
And then that leads me on to this. I don't need GPS Software time, I just need pseudoranges, and a good model of how the measurement is taken. But if I have to use GPS Software time to figure the time of measurement for each channel, then you can see, I have an unknown unknown (http://www.slate.com/id/2081042/) .
Would it give away too much to confirm that the inter-channel measurement spacings are guaranteed to be equal by some hardware process, or say it aint so, it's all the whim of interrupts and code? :-)
Back to MID 7. I was hoping to avoid dealing with that beast as it's even less well explained than MID 28 :) This is where I have to choose words very carefully. OK, you say.. Take the GPS Software Time from MID 28 and *subtract* the clock bias provided in MID 7 to get what you call the true GPS Time of measurement. What I think you mean here is, if you do that sum, you get the 'true' GPS System time at which that particular pseudorange measurement applies.
However, life isn't that simple. MID 7 suggests to me that the the clock corrections in MID 7 apply at the instant given in 'Estimated GPS Time' given in MID 7. and therefore for this information to be useful, it has to be extrapolated given clock drift before being used to correct the terms in MID 28 .. Umm.. are you sure? I felt that if the sirf programmers went to the trouble of putting a highly processed number into MID28, they would have thought of this and therefore GPS Software Time in MID28 is infact the softwares best estimate of true GPS System Time. Unless of course the programmers were thinking in terms of their own time standard called gps software time that was neither the time frame of the crystal or gps system time.
And again, MID 7s estimates are just that.. estimates. Nothing said about the method. And if there is filtering involved, nothing said about time constants. No, I don't expect you to comment on that last one :-)
I'm also worried that you later go on to say that GPS Software Time 'is our time of measurement number'.. do you mean ordinal.. or exact.. or exact given the correction from MID7 ?
Now I know that a lot of my worries are like 2nd and 3rd order effects, but at this stage I don't know if the law of large numbers will come to my aid, or if not fully understanding how the reciever works will cause some bias that will come back and bite me.
It really is a serious issue here, because if I'm ultimately relying on Sirf's best estimate of position, even indirectly then I'm trusting them to have done a *really* good job. I mean even taking into account 2nd order relativistic effects due to orbital eccentricity.
I'm not ready to fully comment about pseudorange smoothing. If all the filter uses as it's inputs is a sequence of pseudorange measurements and a sequence of integrated carrier phase measurements, it's easy to build a filter that looks good but hides biases due to the fact that filters inherently look backwards. Again, I might be chasing shadows, but itd be nice to be reassured that yes, the smoothing is done in a way that can't introduce unintentional bias and doesn't lose any more information than the variance of the measurement noise. It's the reassurance I'm after, not the source code :-)
On to the politics of this.
In a lot of ways, MID 5 worked the way things ought to have worked. We had hardware correlators, we could understand what was going on. I'm thinking, and you don't have to comment, that MID28 happened because sirf moved towards a hardware model based on buffers and a DSP-like engine. And the parameters from MID5 then didn't quite make physical sense.
Another thing that is probably a political comment is, am I right in thinking that the pseudorange smoothing happened because Sirf wished to target navigation rather than post-processing users?
I'll also wager this. I think when Sirf realised how good its data was that was when they decided to make Carrier Phase a premium product. The problem here is, there's only so many surveyors out there and there's several orders of magnitude more people who would love give-or-take 1m accuracy for all kinds of things. So I'm not sure of the sense in this decision.
I wonder also.. suppose I wanted to build a survey grade receiver (that thought has crossed my mind a few times). So I go to Sirf. I say I want to buy a license on a Sirf III with Carrier Phase enabled. They say, yes sure but you still cant get unsmoothed pseudorange and you still wont know more about the physics of the reciever. Am I making a good decision? It does occur to me (and yes I'm probably giving too much away of my own secrets *giggle*) that if I wanted to do this, and build a L1 only GIS grade reciever, I'd probably start with a pure radio + a/d and build a *huge* buffer, and post-process that :-)
Thanks for your help :-D |
|
|
|
Carl@SiRF
USA
157 Posts |
Posted - 19 mai 2006 : 01:29:28
|
Ok, let's try to take this one from the top:
1. You are right -- SiRFstarIII does not properly post time tag. I'll put that into the system as a bug. I hadn't noticed that since I don't normally use it.
2. GPS Software Time is our best estimate of true GPS time based on the arbitrary clock plus pseudorange. Once we make the GPS solution in nav we learn how bad that estimate was. But that is the nature of GPS: you don't know GPS time until you solve for it as your fourth unknown in the nav solution. Yes, if I mess up the position I'll mess up GPS time as well, but you won't see it here. Assuming the speed of light is 1 foot per ns, and the resolution of this value is in either ms or 10 ms, that is quite a few feet before you see anything -- 1 or 10 million feet (well, half that if we round off the number).
3. Assume I just give you pseudoranges and not time. Where were the satellites when those pseudoranges were computed? You need that in order to do a solution. Somehow you need time. So we give it to you. We could give you the time of transmission of the signals (which is what you need to compute satellite position), and time of receipt of the signal, or pseudorange (they are really the same thing), or we can normalize all measurements to a single time of receipt and report the ranges, allowing you to compute the time of transmission so you know when to solve for the satellites' positions. But regardless of how I do it, I have to give you some time. Of course it is biased -- again, that is the nature of GPS.
4. Interchannel measurement times are quite variable. That is why we normalize everything to the same point in time by extrapolating any measurement that was not done at the same time as others. All measurements are extrapolated to the same time so you don't have to use some rather complex calculations in the nav solution, but can do a point solution at the time of common receipt.
5. MID 7 doesn't need too much explanation. It has GPS TOW and Est GPS Time, which you will see match the GPS software time (with an extra decimal place reported in Est GPS Time), and clock bias and drift. Both bias and drift are computed to the same point in time, that time common to the measurements. Clock bias is the offset between the receiver clock and the computed GPS time. Clock drift is the rate of change of clock bias. However, clock bias is reported as a frequency because in our architecture that relates directly to the crystal frequency. To use the clock bias, you don't have to correct by clock drift to use with MID 28 data because their times agree.
6. GPS Software time is not true GPS time because it is the raw measurement time. Until we compute the nav fix, we can't correct it. MID 28 is set for output before nav is given the data to compute the nav fix.
7. MID 7 data comes from the same least-squares or Kalman filter as the nav solution. Nothing secret about that.
8. You don't have to rely on SiRF's nav solution, because you don't have to use our clock bias with the raw numbers. Just using the data in MID 28 is sufficient, along with computed satellite position, to compute the clock bias on your own. Heck, that's what we do!
9. MID 5 is still the form our measurements take when sending them from the measurement to navigation routines. We output MID 28 because that is the form more people wanted, and it is the form our nav uses internally. If it's good enough for our nav ...
10. SiRF definitely targets the nav population. Post processor users number perhaps a few hundred units sold per year. Nav users number millions of units per year. You do the math.
11. You tell me how good our measurements are. Users of carrier phase (we do have some) like what they get, but we are still a one-frequency C/A code receiver. I won't expect to see too many cm-accuracy solutions using this chip. Also, our tracking loops are optimized for the types of dynamics you get with navigation receivers, not static survey receivers.
Good luck with your receiver. If you get things working, I would be interested to see some results.
Carl - SiRF Customer Support |
|
|
|
paulkbiba
USA
5023 Posts |
Posted - 19 mai 2006 : 01:55:24
|
I'm making this topic sticky so we won't loose any of this valuable info.
Moderator
Don't forget the GPSPassion Club! |
|
|
|
Russel
Australia
49 Posts |
Posted - 19 mai 2006 : 12:41:34
|
I'm going to have to respond to Carl one bit at a time and even then there are some things I just won't know till I've crunched the numbers, and that could be a while. Weeks.. Months if life gets in the way :/ Perhaps coyotebush might have some ideas?
Firstly, on the issue of the Time Tag in MID 28. Before I leave Carl to run off and chase a bug, I went and did some longer logs. What seems to be happening is that Time Tag is counting up monotonically. But it takes it's time to tick over.
Here are the Time Tags, GPS Software Time and difference values I have.
21 467826.139028164 + 261.915839746 =
22 468088.054867910 + 263.015900107 =
23 468351.070768017 + 262.015839685 =
24 468613.086607702 + 263.015899585 =
25 468876.102507687
It should be noted that 2^18 milliseconds is 262.144 seconds.
More later.. |
|
|
|
Russel
Australia
49 Posts |
Posted - 19 mai 2006 : 14:07:28
|
Let's consider a generic gps receiver. We have 'local time' which is simply the count of the cycles of a quartz crystal, or some number which amounts to the same thing. Then we have GPS System Time which I hope is understood even though there are some subtleties in how it is derived. The point is that GPS system time is the framework from which we calculate the location of a satellite at any given (GPS System) time and also, that GPS system time is the same for every satellite. So I can take GPS system time at any instant and then calculate the position of each sattelite. Due apologies for the tutorial. I just want to avoid any ambiguity in what I'm about to say..
Now we consider a perfect world. That is the broadcast ephemeris has no errors. There are no other pertubations to the signal. Other than one. That is that the 'local time' of the reciever is not the same as GPS System time. Now we need to consider two types of reciever. Type A makes pseudorange measurements for all satellites at the same instant, and even though the receiver doesn't know the difference between local time and system time, it does know the interval between measurements relative to local time. Type B receiver is simply a relaxation of the same problem. It makes a series of measurements to different sattelites in sequence. It can only know the intervals between measurements relative to its own local time. Now.. these intervals and how well they are understood, matters a lot.
We have two issues. First, how do we find out the difference between gps system time and local time. The second is about how do we deal with issues related to measurements not being at the same, precise instant. I'll deal with the first one here. And what follows is all classic theory so excsue me for this..
Type A reciever. We ask, at what instant in time, would GPS system time have to be such that each satellite is in a location such that the pseudoranges intersect at a point. We then have a time and position fix. Nice.
However. Lets add some error. We'll add a delay of (say) 10m to the path of just one of those satellites. No matter how you jiggle things, you will not get things to intersecet at a point. The classic fix of course is least squares. Now we *know* in this case, the least squares fix is wrong (and it usually is to some extent in any given real measurement). This means two things. One is the position fix is in error. Secondly our estimate of the local time to gps system time difference is in error. Problem is, we now have two unknowns. one parameter. And GPS System time as we know it, has an uncertainty.
And then we extend this example to makeing a sequence of measurements (remember our receiver still makes all pseudorange measurements for one epoch at the same instant). So.. each second, according to local time, we measure the pseudoranges. This is good, because the data is relative to local time, and the local clock has an understood behaviour. (its not perfect but its understood). Of course, to convert a sequence of sets of pseudorange measurements into real position fixes we do eventually have to come to terms with system time, and then the actual locations of satellites and so on (its a loop yes). The point being we might choose not to use least squares to estimate a position fix. We might want to build in estimates of the paramters of a larger physical model. You know.. ionosphere, this satellite is having a bad hair day.. etc. In doing so we have a better fix.. and therefore a better estimate of gps time *before* our gps time estimate folds back into our final solution.
Now, lets take a black box. It's got a sirf label on it. All we are given is a set of pseudorange measurements and with that set is a estimate of gps system time. lets also assume for the moment that inside this box, the physical measurements did happen at the same instant in time. We don't know however what the tick of the local clock was when that set of measurements was taken. We have instead an estimate of gps system time at that point in time. However, the estimate of gps system time provided includes an uncertainty. And that uncertainty is tightly-coupled with the estimate of position. And that estimate is bound up with precisely what assumptions were used. Hence even given the data in MID 28, you cannot escape innacuracies introduced where sirf's algorithm estimates the position-time solution incorrectly. Moreso you can't characterise the nature of the problem. Is it numerically unstable. Is it second order in nature. Will it ultimate prove guassian. Etc.
Only one way to find out.. so you probably wont' see much of me on this for a while. But you can bet I'm trying to second guess their algorithm. Not so I can reproduce it, but so I can characterise its flaws/biases. I'm going to comment on Type B receivers in the next post. |
|
|
|
Russel
Australia
49 Posts |
Posted - 19 mai 2006 : 14:33:02
|
I hope this one will be a tad shorter. Type B receiver. The actual time of measurement for each individual pseudorange is different in this case. The best we can hope for is to know the difference in time between each measurement expressed in terms of local clock. It really isn't neccesary to normalise pseudrange measurements to a given moment for the purpose of post-processing. Infact its retrograde. I'll even stick my neck out and say this is one aspect of the design of RINEX I find dodgy. Bite me :)
Normalising pseudorange measurements so that they seem to occur at the same point in time is no trivial task. What it amounts to is having a real (raw) measurement, having a system of assumptions in which gps time and position is calculated, understanding the orbits of the satellites.. and then basically backing up in time the motions of the other satellites so that ultimately we end up with the pseudorange that would have been measured had it been taken at the normalised time.
Oh.. ow! For a start how much does one trust the algorithms. In backing up motions of satellites we've now thrown in extra errors, both clock noise on the sattelite and the receiver, the behaviour of the ionosphere between measurements, and so on. I'm not even going to begin to think how to un-convolute this. All I can do is trust (to some extent) Sirf and then try to figure out how much real difference it seems to make in practice. Again, I'll show you the numbers with a Sirf II and a Sirf III, but I do have a life :-) Well. Maybe :-S
Btw, speaking of Sirf innards I did read this and was intrigued by it.. Carl said in thread http://www.gpspassion.com/forumsen/topic.asp?TOPIC_ID=25575&whichpage=2 the following:
<quote>
SiRFstarIII operates in faster than real time, much faster in fact. But of course that means it must work in the past. It captures a snapshot of the streams of 1s and 0s in a buffer. When the buffer is full the receiving hardware switches to another buffer to collect the next samples while the tracking hardware starts processing the filled buffer. That tracking hardware repeatedly processes the buffer for each satellite it is tracking -- if it is tracking 8 satellites it processes the buffer 8 times, once for each satellite.
</quote>
If this were so, I would naturally expect that all the pseudrange measurements have the same effective measurement time, since we're dealing with the same data sampled at the same time. No?
I wonder if what you said about Sirf III in this respect is also true to some extent of Sirf II. In other words did they try out the virtual correlator system in Sirf II and then expand it in Sirf III or is Sirf III a radical change in architecture (you'd think so from the marketing blurbs.. but I think the sirf engineers had the right ideas up their sleeves from way back).
|
|
|
|
Carl@SiRF
USA
157 Posts |
Posted - 19 mai 2006 : 17:29:55
|
Wow, that’s quite a bit to respond to. Things are getting deep here. Let me first preface my response by saying that I am not a mathemetician, and don’t pretend to understand some of their algorithms. But they have them, and obviously the algorithms work. So let’s try to pare things down a bit.
1. Receivers that take all measurements at the same point in time. That point in time is of course tied to the internal clock, since that is what everything in the receiver is tied to. At some point we will learn an approximate GPS time (from reading navigation messages, for example) and can then refer our internal time to GPS time with some degree of uncertainty. We don’t really care what that uncertainty is, because it is after all just one of our unknowns in the navigation solution. But to make life easier for those reading my measurements I can report measurement time in those units and the clock bias will be some small number rather than one in the hundreds of thousands of seconds. So in this regard, much of what was in that first post is off point. The uncertainty in my Estimated GPS Time or Software GPS Time or whatever you want to call it is exactly what the uncertainty of my internal Time Tag would be, but with a different bias. And at the points in time where I make my measurements the relative times between measurements are accurate to the resolution of my timekeeping system. On the long term any good crystal oscillator wanders all over the place, but in the short term, we are quite safe to model it as much more precise, since tick-to-tick variances are much more manageable than variations over broad temperature, aging and whatever ranges.
2. The type 2 receiver, one that takes all measurements either sequentially or in some other order that puts them at different points in time. The issue here is really the same, but with one added complexity. That is that the tick-to-tick variation in the crystal is now spread over a lot more ticks. This simply means that the uncertainty of measurement time increases a bit. The fact that the satellites’ positions must be resolved at different points in time is really the same as in item 1. There the measurement time was the same, but we don’t care where the satellites were when we measured things. We only care where they were when they sent the signal we received at that measurement time, and since the pseudoranges to each satellite are different, that transmission time was different. In case 1 they were much closer in time than in case 2, but again that was just a matter of degree. So, really both receiver types are the same, but the math you need to do differs, and if you add in receiver velocity, you get a new twist. Leave all that to the nav guys and their fancy math.
One final comment: SS2 did not use the same process as SS3 with one small exception: both receivers use a fast fourier transform as part of their search algorithm, and that of necessity uses data sampled and stored. For tracking, SS2 used traditional correlators while SS3 uses the algorithm I discussed elsewhere, which Russel quoted.
Carl - SiRF Customer Support |
|
|
|
Russel
Australia
49 Posts |
Posted - 19 mai 2006 : 19:08:55
|
Tis good.
Like I said, I'll have to do some more number crunching both to have something useful to say and to illustrate more of what I'm thinking.
Thanks dude :-) |
|
|
|
Russel
Australia
49 Posts |
Posted - 19 mai 2006 : 20:31:25
|
Just a quick note. Yes, you're quite right. The pseudorange values as published in MID28 are definitely shifted by clock offset and the amount does take sudden jumps too. I see your point about keeping the clock offset relatively small.
moo! |
|
|
|
Carl@SiRF
USA
157 Posts |
Posted - 19 mai 2006 : 22:05:36
|
Clock bias changes each epoch in the SiRF architecture by the clock drift value. Clock drift, nominally 96250 Hz, equates to an added Doppler of 18,316 m/s on the received signal, so you will see the pseudoranges change by that amount plus any range change from satellite motion every second.
Carl - SiRF Customer Support |
|
|
|
Topic |
|
|
|
| This page was generated in 0,83 seconds. |
 |
|
- 
del.icio.us
Sirf nav data physical model
