Archive for the 'Software' Category

TELECAN project comes to a close

Friday, November 29th, 2013

For the last 12 months our company has been in a collaboration project with the University of Las Palmas in a project called TELECAN.

This activity does not have a GNSS component at this time but it has been a fantastic learning experience for our company in the filed of Earth Observation, and it has brought together disparate members to work together towards a common goal. The partners of the project have been; ULPGC-GPIT, ITC, University of Agadir y SAC.

The final presentation was on 29 Nov, 2013 in the “Jornadas de Teledetección Espacial” and immediately afterwards there was a round table motivating a very interesting discussion based on the presentation.


The project has covered the production, storage, publication and display of Earth Observation products as they are related to renewable energies. This has covered the generation of 13 products, some generic EUMETSAT products, some from a Scientific Application Facility for nowcasting and some dedicated developments by this short project, as shown in the slide below.

TELECAN meteorologia energetica products

TELECAN meteorología energética products

But in truth the biggest component from our part has been capacity building and technology transfer, we see this project as a technology project, even though there has been a scientific component that is not the focus from our point of view. Our company has created a storage and publication system for the many products that the scientists generate in near-real-time. This storage, classification and vision system has been started from scratch internally Layers and GeoServer, two technologies we did not handle before. You can access the service clicking in the image below and find a sample of the products that the TELECAN scientists are generated in near-real-time.

portal web de productos de Meteorologia energetica

portal web de productos de Meteorologia energética

I will link to the presentation once it is loaded in the TELECAN webpage who are the ones authorised to distribute it.

regards to all!!


SAC helping the ESA/ESOC GPS Reprocessing

Saturday, November 29th, 2008

The IGS Reprocessing is a fantastic activity which I have highlighted before in this blog.

The IGS reprocessing involves recalculating all the GPS products (Station coordinate files, Satellite orbits, Station and Satellite clocks and Earth Rotation Parameters). Most of the IGS Analysis Centers are participating in this effort to take all the IGS GPS data from 1994 to 2008 and recalculating everything with the current state-of-the-art programs and techniques. This will produce more precise and continuous GPS products for the lifetime of the IGS. All the details can be found at the IGS Analysis Center Coordinator Website on Reprocessing.

At ESA/ESOC/OPS-GN (Navigation Support Office) we are one of the original IGS Analysis Centers so we wanted to participate in the Reprocessing. Unfortunately we had no spare processing capacity, and it was not clear what new machines should be bought to take on this challenge.

To help resolve this situation our company, SAC s.l., provided access to the ESA/ESOC Navigation support engineers an Intel Quad Core PC with Ubuntu 64bit, named SAC01. On this new machine we could start doing compilation tests, short runs, speed tests, data handling tests, etc. The machine was bought and configured by SAC s.l. in February 2008 and located in Las Palmas, Spain, at the professional housing services of a local Internet Service Provider (ISP). The machine was accessible via ssh and via FreeNX which allows for graphical display export easily to any other internet-able computer. The machine, SAC01, has installed the ESA/ESOC software Napeos POD software:

SAC01 Ubuntu QuadCore PC for POD ESA/ESOC Napeos POD SW on SAC01

SAC01: Ubuntu QuadCore PC for POD

By the end of 2008 we will have reprocessed and delivered to the IGS all the days from year 2000 to 2007, using 150 stations per day. This has involved downloading and checking about 200Gb of GNSS data from the CDDIS. The processing was executed in parallel, leaving one core free for Operating System processes, so that 3 days are run at once. This raises the temperature of the PC considerably but there is enough cooling power at the ISP to handle it!!

The reprocessing has involved 150 stations per day (green crosses), it has generally taken 50 minutes per day (red crosses) using 30/31 satellites (blue stars), summaries of four of the years are shown below:

2000-2003 reprocessing statistics

2000-2003 reprocessing statistics

Also noted are the total number of GNSS stations downloaded from the IGS (blue squares), and the stations rejected from the processing (pink squares).

At the start of 2009 the ESOC reprocessing results from SAC for 2000 to 2007 will have been checked, submitted and validated at the IGS making them the official ESA/ESOC contribution for those 8 years. The excellent results obtained finally convinced ESA/ESOC to buy two similar machines which will be used to produce the 1994-1999 reprocessing internally.

We are very happy at SAC s.l. to have supported ESA/ESOC in this innovative and successful way,

Ignacio Romero

P1-C1 bias … and other Code biases

Saturday, March 15th, 2008

The C/A code and the P code encoded in the L1 “should” be coincident so that a pseudo-range derived with the C/A code; “C1″ should be equivalent to one derived with the P code; “P1″ so that we could use them interchangeably, in the IGS we agreed years ago to use P1,P2 & L1,L2 to create the iono-free observables to estimate GPS orbits, clock biases, etc.

The problem is that some receivers do not generate a P1 so we just use C1 in its place. Therefore we end up mixing in one epoch of data measurements for the satellites from many receivers and we have to mix C1 and P1 measurements from the same satellite and this is the problem, that the satellite clock estimated with this “mixture” will not be correct and our whole estimation of clock biases will be affected since therte is now way to separate the P1-C1 bias at this point.

An additional problem is that old receivers that do not generate P2 in the modern sense of an independent observation of the L2 code. The P2 pseudorange observable from this reduced list of receiver types (mainly older ones) are actually formed by a process which tracks the cross-correlated (P2-P1) pseudorange to produce a P2 which also needs to be corrected by the P1C1 bias!:

P2 = C1 + (P2-P1)

The corrections f(i) are applied as follows to C1 and the P2 if it needs correcting:

C1 –> C1 + f(i)
P2 –> P2 + f(i)

Since the signals encoded on L1 in the satellites are NOT coincident, it is easy to see that C1 and P1 are delayed one with respect to the other, so we cannot simply mix them in the processing without correcting one of them, in this case the agreement is to bring C1 to P1 by adding the P1-C1 bias to the original measurement.

Since we agreed to use P1 for all the receivers if the P1 is not available we take the C1 and add this correction factor which is very stable for each satellite but it is satellite specific and can be quite large:

biases f(i) are always in units of ns and are listed in PRN order from PNR01 thru PRN40:

data bias / -0.233d0, -0.033d0, -0.163d0, 1.234d0, -0.944d0,
+ 0.444d0, -1.132d0, -0.416d0, 0.366d0, -1.651d0,
+ 0.591d0, -9.999d9, 1.529d0, 0.108d0, -1.326d0,
+ -0.525d0, 1.391d0, -0.012d0, -2.026d0, -1.228d0,
+ -0.392d0, 0.532d0, 0.130d0, -0.069d0, 0.575d0,
+ 1.083d0, -0.189d0, -0.232d0, 0.643d0, 2.016d0,
+ -0.073d0, -9.999d9, -9.999d9, -9.999d9, -9.999d9,
+ -9.999d9, -9.999d9, -9.999d9, -9.999d9, -9.999d9 /

The biases are an output of the Ionospheric processing which characterise the Ionosphere state from the delay due to the effect the free electrons have on each frequency (L1,L2) as they enter the atmosphere, therefore since many receivers have both C1 and P1 the IGS Ionospheric Analysis Centers can see the “code bias” and they report it regularly to the IGS and everywhere else.

There is another bias from P1-P2 which the Iono people calculate since the P code should be encoded in L1 and L2 at exactly the same time but this is not so, therefore a bias between the P codes exist as well.

Yet another code bias between P2 and C2 (the new GPS L2C signal) but not much work has been done of this since it is new and few satellites have L2C.

In the beginning we corrected new modern receivers to mix them with the older ones (pre-2000 era):
Handling mixed receiver types

Later we started correcting the older receivers to make them consistent with the modern receiver measurements (from April, 2000 onwards):
New pseudorange bias convention

We now have the biases published officially by CODE for everyone to use:
Monitoring (P1-C1) code biases

The latest updated set of values:
Updated p1c1bias.hist

Selective Availability OFF forever

Saturday, December 15th, 2007

I was a recent arrival to the GNSS field in the year 2000 when president Clinton turned off by surprise, to us at ESA at least, the SA degradation to the GPS satellite clocks. At that time at the IGS we were only estimating orbits and clocks and for our work this SA-off had no immediate effect. It did have a longer term effect in the IGS as we started to plan for a clock prediction product latter materialized in the ultra-rapid product updated 4 times a day with 24 hours of predicted orbits and clocks. This product can now substitute the broadcast navigation message for real-time users to provide improved real-time positioning results.

Now president Bush has cleared the air and declared SA dead, by not adding the capabilty in the design of the new GPS satellites, as had been recommended by the DoD. I believe that this reflects the fact that a re-introduction of SA would harm the economic fabric that has been built of single frequency users which rely on stable satellite clocks for increased positioning performance.

SA was artificially “moving the satellite clock” so that the timing measurement which underlie the navigation system could not be as precised as it should be. The GPS satellites have 4 very precise atomic clocks on-board which are used to generate the timing messages, if you purposefully degrade the atomic clock output superposing a signal the timing messages are affected and the position cannot be calculated as precisely. The degradation was based on a function which only authorised military users could effectively remove from the timing message to recover the inherent accuracy of the system. Since SA has been off for almost 8 years and with the improvements in the quality of the GPS navigation message the GPS currently delivers accuracies much higher than originally specified for the civilian single frequency users.

The clock bias values calculated for that day for PRN10 easily show the jump from SA to no-SA on May 4, 2000 at 04:00 UTC indicating the recovery of the stable satellite clock bias :

Clock Bias PRN10, May 2, 2000, SA turned OFF!!