Archive for the 'Hardware' Category

Galileo 5,6 launch and orbit update

Thursday, August 28th, 2014

PRN01 … not quite working as expected

Sunday, September 13th, 2009

PRN01 is one of the latest GPS satellites launched on 24 March 2009. Over the summer we have been investigating what the deal is with this satellite which is still not set to healthy.

When a GPS satellite is launched it goes through a period of a few weeks of commissioning. This period involves in-orbit checkout, etc, including the activation of the navigation payloads and others. As soon as the navigation payloads are activated many of the stations of the IGS network will start recording observations for the satellite, so in the IGS we will produce precise clocks and orbits for the satellite. A few days after that normally the satellite is declared healthy for all navigation users and the satellite is available.

For PRN01 the situation has been a bit peculiar as you can read here GPS SVN49 and L5 Signal. The satellite was essential for GPS to lock the L5 frequency for GPSIII use in the future. A reserved frequency to be used in space applications has to be used from space within a certain number of years or it is released by the ITU for anyone else that needs it. Therefore as SV-49 was going up anyway to completent the GPS constellation they decided to add an L5 demonstration payload to the satellite so that the L5 frequency filing would not be in jeopardy. But after months and months the satellite never became “healthy” so it is not available for general navigation use and it is a doutbful “spare” satellite in the GPS constellation.

My wonderful colleagues at ESOC Tim Springer and Florian Dilssner have now investigated the situation an published the results in InsideGNSS, one of the best industry publications. Read their investigations online: SVN49 and Other GPS Anomalies, Saving GPS SVN49, GPS Signal Anomalies. There are other further investigations out there of this issue and possible solutions, but these three from my colleagues at ESOC are the first three I saw published.

I will not try to summarize all the issues which are very well explained above, basically they connected the L5 demonstration payload in a spare port to feed the signal to the transmitting antenna. In doing so they have introduced significant elevation dependent errors mainly in the L1 signal. While some elevation dependent issues are sometimes observed with different GPS satellites, none have ever had it as bad as this one!

The issue continues to be under investigation and the satellite will remain unhealthy until the Air Force is satisfied the problem is completely understood and a workaround implemented.

Good positioning!!
Ignacio Romero (Nacho of the IGS!)

GPS-GLONASS biases … a receiver issue

Tuesday, June 30th, 2009

GNSS receivers decode all the signals ‘more or less’ at the same time, the time is really set by the GPS but the other systems (Glonass) have a bias so that apart from the clock bias per satellite there is an inter-system bias between the constellations (at least that is what we thought!! here is a paper I wrote sometime ago on the subject: GLONASS_POD

The plot below shows the state of the art when I was still in charge of glonass processing at ESOC some years ago!! you can see that we estimated one bias per receiver and per arc (2 days of data) and the biases are very stable each day and they are ‘grouped’ per receiver type. all the Javads tend to behave ‘similar’ and all the Ashtech Z-18 the same … but the estimated clocks were still not very good so then we estimated ‘one bias per satellite per data arc per receiver’ this is more reasonable, as the previous was an average over all the glonass satellites. The average (in the plot) is enough to get reasonable orbits.

InterSystem Bias

Now at the ESA/ESOC IGS Analysis Center we estimate the intersystem biases per receiver and satellite pair, and we have excellent orbits and clocks for glonass, the size of the intersystem biases is similar to what you see in the plot for each receiver type except each satellite/receiver pair varies a bit around those initial averages per site.

The explanation is that internally the receiver takes longer to decode the glonass satellite signals and since glonass works in different frequencies for each satellite (FDMA and not CDMA) then the bias must be frequency dependent.

Certain ‘batches’ of receivers using the same electronics produce very similar biases per satellites but it still has to be estimated all the time.

For Galileo I would assume a general intersystem bias with GPS will work but this is still unclear to me at this time, maybe many biases are need per satellite and per measurement type?? … not sure yet!!

Happy positioning!
Ignacio Romero (Nacho of the IGS!)

SAC helping the ESA/ESOC GPS Reprocessing

Saturday, November 29th, 2008

Space is not free anymore ??

Tuesday, January 29th, 2008

GPS Control Center updated!

Tuesday, October 16th, 2007

Where is GNSS heading

Sunday, September 9th, 2007

RealTrack football (I mean soccer!)

Wednesday, August 15th, 2007

what GNSS signals do we have …

Wednesday, June 13th, 2007

  • C1 ; Ranging to the satellite based on the Civil message.
  • P1 ; Ranging to the satellite based on the Encrypted (high-security) message.
  • L1 ; Number of cycles since satellite acquisition.

  • P2 ; Ranging to the satellite based on the Encrypted (high-security) message.
  • L2 ; Number of cycles since satellite acquisition.

GNSS options

Friday, August 4th, 2006