Soluciones Avanzadas Canarias S.L.

Coming back to this issue we have encountered a significant problem.

As remarked before in this blog P1C1 biases we have to be able to correct the C1 measurements from GPS to mix them correctly with the P1 measurements. This comes from the fact that when the signal is encoded in the satellite there is a delay between the ‘C/A’ and the ‘P’ code encoding.

Of course we detect this offset between signals (differential code bias: DCB) in the RINEX data which is recorded by a receiver after traveling from the satellite to the antenna through the atmosphere, and from the antenna to the receiver through the cable , amplifiers, etc. Internally in the receiver the electronics can also play a role of course. In any case what we see in the IGS is the RINEX data and this is what we have to work with.

As mentioned in the previous blog entry P1C1 biases the Analysis Center CODE (Center for Orbit Determination Europe) at Univ Berne publishes the P1C1 biases as an average over many brands of receivers available in the IGS network, and generally it is accepted that these averages are to be used when doing IGS-type processing or using the IGS products.

We have found that when an IGS-type solution uses a network of receivers with only Trimble receivers (which need the P1C1 bias) the CODE values may not be the best suited since the Trimble receivers do not show the same DCBs as other receiver brands. We have reached this conclusion after MANY internal investigations and testing. It is clear that depending on what receiver types we test the DCBs are slightly different from the accepted CODE averages, but when the receivers are only Trimble then the differences for certain satellites can be very significant:

in the table above you can see the differences of the P1C1 bias from CODE, as calculated using only Ashtech receivers and as calculated using only Trimble receivers, note the differences for satellites such as G07, G12, G29, etc. in plot form this shows the differences more clearly:

This generally means that the clock solutions from using the incorrect P1C1 bias will be biased versus the satellite clock solutions from a mixed network or as published in the IGS clock combination.

Therefore to conclude, be careful when calculating satellite clock solutions when all the receivers are of a certain brands and the data has to be corrected with the P1C1 bias! This is if you are interested in the satellite clock solutions or on resolving the maximum number of ambiguities with fixed satellite clocks!

Best regards to all,
Nacho

The members of the Infrastructure Committee have prepared the following statement which was distributed to the receiver manufacturers late in 2010 by the IGS Governing Board:

”
The IGS urges all GNSS receiver manufacturers to adopt a
standardized phase alignment practice for all GNSS signal
modulations common to a given carrier frequency, in order
to minimize user confusion and to remain consistent with
the long standing and universal practice established for the
GPS L1C/A and L1P(Y) signals.

The issue of phase changes associated with some GPS flex
power modes is a much less pressing concern considering GPS
assurances not to exercise such modes till after 2020 and
considering that the GPS navigation message will be updated
to flag such events when they occur.
”

We have come to this consensus at the IGS to speak with one voice and to send a clear message that the manufacturers need to provide phase measurements on all frequencies that are aligned so that users of the measurements do not have to second guess what they are using.

It is hoped that this statement and that the IGS relationship within the RTCM sc104 will help to resolve this issue for the benefit of all dual frequency GNSS users. In the end we anticipate that either an agreement will be reached for all manufacturers to provide aligned phases on L2 as they already do for L1 and to provide the amount they align them by so that the original measurement can be reconstructed should anyone need to.

To provide the alignment information the RINEX format has had a compulsory line added to the header as follows:

” The applied corrections are to be reported in a new SYS / PHASE SHIFT header record to allow the reconstruction of the original values, if needed. The uncorrected group of observations is not reported in the SYS / PHASE SHIFT records.

In case the reported phase correction of an observation type does not affect all satellites of the same system, the header record allows to also indicate a list of the respective satellites.

The SYS / PHASE SHIFT header record is mandatory. If the file does not contain any observation pairs affected by phase shifts or if (exceptionally) the applied corrections are not known, the observation code field and the rest of the SYS / PHASE SHIFT header record field of the respective satellite system(s) are left blank.

”

This has been added to the latest RINEX format versions:

Rinex 2.12

Rinex 3.01

… more on those versions in an upcoming post!!

Best regards!
Nacho

What an issue!!

We are facing a very significant problem in the current Rinex data files , and I need to tell you about it!

The Rinex 2.11 format is defined without regard to where the phase is actually coming from (the C/A or the P code tracking). This has for the longest time not been an issue because it could only be a problem in L1 since it was the only signal with both C/A and P code. But it wasn’t a problem because the receiver manufacturers would align the L1 phase so that a user did not need to know whether the L1 phase came form one tracking or the other.

As the L2C signal spreads through the GPS constellation with the newer satellites we have encountered this pesky problem more and more. Now there are two signals on L2 as well, as we have always had in L1, the ‘P’ code and the ‘L2C’ code … so potentially the L2 phase could come from either signal tracking. In the IGS community we expected that the receiver manufacturers would again align the phase measurement transparently … but they did NOT!

Therefore we are now left with L2 measurements in Rinex 2.11 files that have a 1/4 cycle shift for certain satellites (the IIR-M and IIF ones!) from certain receivers. A clue comes from receivers that do not give you the P2 measurement, only the C2! these data are not useful for the IGS processing and I am pretty sure that the L2 phase reported therein is an L2C phase with a 1/4 cycle offset from the L2P phase. For example:

You can see that for satellites G05, G25, G29 and G15 (all Block IIR-M satellites) there is a C2 measurement but no P2 measurement! Therefore almost half of the data from this sample station cannot be used in IGS processing. We would need to apply a P2C2 bias as we do to C1, but no such agreement exists yet in the IGS to do so.

In the IGS we are working to solve this issue but it will not be easy, at least we have defined a format (not actually used by anyone!! ) which includes a compulsory line in the header to report the offset between phases on the same frequency, Rinex 2.12 format.

Solving this problem will involve the Infrastructure Committee and the Real-Time Pilot Project in direct connection with the receiver manufacturers. more to come in a future post!!

All the best!
Nacho

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.

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!)

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

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

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
Director

I have recently added vehicle management to my own car! and let me tell you about it … it is an interesting experience but the system has some way to go before it is truly useful.

I was investigating representing a new fleet management service from mainland Spain in the Canary Islands. The islands are a strange place for fleet management services and I knew the market would be difficult. The territory is obviously fractured and the islands are not very big so most commercial vehicles have a relatively small area of operations compared to mainland based vehicles.

On the other hand the Canary Islands have excellent mobile phone coverage (fundamental for fleet management) which extends into the ocean surrounding the islands so that both land based and water based vehicles could use such a system, and given the number of vehicles of both kinds a fleet service can start to make sense.

The installation in my 1978 Triumph Spitfire was relatively simple. The approved installer found a suitable connection point by splicing the cable from one of the dashboard illumination lights and we stuck the two antennas (GPS and GSM) on the dahsboard where they are hardly noticeable. The device is not very large and we stuck it out of view inside the car close to the passenger side.

These are the kinds of information you can pull up from the fleet management system online; positions over digital maps and detailed reports of vehicle movements (right-click to view larger image):

My conclusions so far are positive but there are significant posible improvements:

1. 1 minute position updates are not enough for the islands where the roads are very winding so it should be possible to select the time between updates. Some of my trips do not make any sense because the 1 minute update times skip many turns, exits, etc.
2. The response is too slow, for some reason this version of the on-line system is too slow and this discourages its use! I am not sure if the problem are the service provider resources (PC, connection speed, etc), or the number of users, or the application speed.
3. It needs to be possible to stop the display of positions in the online application, and thus to save those “messages” from the mobile device for later. If an authorised users decides to not track a vehicle for certain periods (like outside working hours) it should be possible to do so and to save the contracted messages as a result.

I would suggest that there should be a way to select the update time at least down to 30 sec. Since there are a limited number of positioning messages agreed per month between customer and provider then if the messages run out so be it … Of course this means that the customer should be able to save messages so that the device can be set to record positions more often as the customer needs. It is not the same driving to germany on the highways than driving in the mountains in Gran Canaria! and the level of detail needed here is much higher.

Those are my thoughs for now, the system continues to work fine and i am generally happy but unfortunately there have been no takers yet!

Happy positioning!
Ignacio Romero