L2 GPS missing/Header error - Post processing ReachRS2 + pospac Lidar

Hi Arnaud,

It’d be great if you could share the answer from the software dev team with us.

At the moment, it’s not clear why post-processing fails. Our RINEX files are standard and can be processed by various external software. It’d seem that the issue is indeed due to the specific requirements of your software.

Would it be possible for you to upload a RINEX version of this file? It’d help us to find out the types of observations included in it and check if post-processing with the RTKLib can be performed.


Hi @polina.buriak

Yes with pleasure, I will share the answer. For the moment I am still waiting for the message from the support, as I said to them about my test with the header, they are investigating another way. I will let you know as soon as I have more information.

This is the rinex version of my drone trajectory (T04 converted with pospac Trimble solution): https://drive.google.com/drive/folders/1twwKnfqyYz5N7prP2BjyCoqZW5uoaSe7?usp=sharing

Btw, at the end of the process, pospac generates an ASCII file, which is the corrected trajectory that I import in my software to generate my point cloud accurately. If you can do that…it’s mean I waste a lot of money in this software :sweat_smile: But anyway, I believe it is not possible as the file must contain information from the inertial unit, like degree of inclinaison in XYZ etc… this is the file in question : https://drive.google.com/drive/folders/1QDNj8XT5og2OV4i5fd37Gr3Bc6znXXrM?usp=sharing

Hi Arnaud,

Thanks for the logs! I’ll look into them and get back with the results.

Regarding the corrected trajectory file, I’m afraid getting IMU data from the Reach receivers is indeed not implemented into the software at the moment.

I think he meant the lidar sensor’s integrated IMU as his linked file contains that data.

1 Like

Yes Gabriel, you are right it is the IMU from the Lidar that I was speaking. :wink:

Btw, i tried with the new firmware 2.22 and the problem still here

Hi Everyone,
I get 2 answers from applanix. this is the first one :

The RINEX file is missing a lot of L2 obs, and you can tell when POSPac is trying to do base data interpolation: The time interval goes from 401998 - 406084 to only 403568 – 404391.
This lines up with your original theory …. The issue is this antenna does not record L2P frequency, I am waiting for a follow-up comment from development on the next course of action, I will keep you posted.Unknown

And finally, the second one (received this morning) who confirm that L2 is missing many epochs :

FYI … Data files must contain dual-frequency pseudorange and carrier phase observations (L1 and L2).
L2C is fine, but this doesn’t sound like an issue with the antenna itself. It looks like it is missing many epochs of L2.

…look like I will have to buy a REAL antenna…

So, does Applanix support L2C or does it necessarily requires L2P?

If it should work with L2C only, then we can check further on why it doesn’t work as expected.

@dmitriy.ershov Applanix support L2C but it’s looks the software requires L2P records or is missing a lot of L2 epochs as the dev team said :

Data files must contain dual-frequency pseudorange and carrier phase observations (L1 and L2).

L2C is fine, but this doesn’t sound like an issue with the antenna itself. It looks like it is missing many epochs of L2.

At some point they may want to start supporting L2C only for modern receivers. Perhaps they will be able to provide you with a timeline.

Unbelievable !!

I get a file who is working from the RS2 !

But I don’t understand why… maybe the update 2.22 ??? I tried this update 4 days ago and it changed nothing but it looks that my test from yesterday is working now. I changed nothing in the setting, just my antenna was logging for more than 2hours and half so maybe I get enough record to process in the software…

But at this point, I need to understand why this test is working because I don’t want to get the same problem as before during a job. I will send the file for verification to applanix to confirm that’s the data are good because I have a doubt about the coordinates after the RTX computing.

This is a screenshot before the process :

and after the process :


It looks like it is a big change for the altitude… so I don’t know if I can trust these coordinates, or maybe it is because the software attributes a different frame to the project following the records from the antenna…

btw this is the file who is working (for reference): ERS20260.zip (4.3 MB)

Since L2C availability is based on satellite generation, it’s possible that during the second test you had more satellite vehicles broadcasting L2C visible to the RS2 and that made the difference. Would have to check the files. If that’s the case, it would mean that your setup working is dependent on the constellation alignment at the time of survey. A longer occupation would likely help with this if the problem has been the software the software determining the bases location as it gives more opportunity for L2C satellites to move into view.


A good test would be to plan two observations with different skyplots, trying to get one that minimizes newer satellites and the other maximizing.

In any case, Applanix will need to update their software because of this tidbit from the US government (it dates from 2008, so I don’t know if the plan has changed) :

The U.S. Government acknowledges global use of GPS codeless and semi-codeless techniques and commits to maintaining the existing GPS L1 C/A, L1 P(Y), L2C and L2 P(Y) signal characteristics until December 31, 2020 when the second and third civil signals (L2C and L5) are planned to be broadcast from a minimum of 24 GPS satellites. After the planned transition date, the characteristics of the L1 P(Y) and L2 P(Y) signals transmitted by any or all GPS satellites broadcasting two or more civil-coded signals may change without further notice and may preclude the use of P(Y) coded signals for high accuracy applications.

In theory, by next May, there should be 24 satellites with L2C capability in space (one is currently on standby and 3 are planned to launch).


yes it’s what I was thinking too.

ok looks good hope the plans are still on the way

Also, as a quick free tool recommendation: GNSS View is a free skyview app that allows you to select constellations and signals based on a current or planned location and time. I just loaded it up and confirmed that you can select it to show only GPS satellites broadcasting L2C and GLONASS satellites broadcasting L1L2 (which is what I believe you said your software requires). Also allows for you to select a mask angle and it estimates HDOP and VDOP. Can help you avoid bad times for setting your base.


Thanks I will download it, it is interressant :slight_smile:

Hi Dear Team, @dmitriy.ershov @polina.buriak I get an answer from applanix :

Hi Arnaud,
As I mentioned earlier our software requires data files to contain dual frequency pseudorange and carrier phase observations (L1 and L2).
The problem data you sent is missing many epochs of L2. This is not an issue with the antenna itself or POSPac but I believe this is an issue with Emlid’s firmware (a bug) – see print screens below.

I have not yet heard back from Emlid support but I believe this is the issue … should the number squared off be a “4” or “8”? I have asked them is this a bug that has been fixed and is it addressed in 2.22 – when I hear back from them I will let you know.

Hi Arnaud,

Thank you for sharing the response!

This is the number of the observation types recorded by the unit. It can be more than 8 if the unit tracks different satellite systems. As fas as I know, it should not affect the post-processing.

However, if during the conversion to RINEX 2.11 in the RTKConv you specify only GPS or GPS + GLONASS satellite systems, it’s possible to get 4 or 8 observation types. In the file you managed to post-process, there are indeed only 8 observation types as only GPS and GLONASS were enabled.

Also, it really looks like the log you managed to post-process contains data from more satellites that are capable of transmitting the L2C signal than the unsuccessful log. It seems that this difference was essential for the software to perform post-processing. This brings us back to @Africawaterdoc’s suggestion:

We’re currently in touch with the Applanix support to figure this out.

Ok thanks, keep me updated

Hey admin- definitely following this thread. I think you’ll have a lot of people looking at this for the same use case, lidar base station. I’ve looked at self configuring a receiver with the ZEDF9P board But if you were able to work out this bug, I’d certainly rather just purchase your receivers than break out the soldering iron. So I’m anxiously waiting an update on this thread because we use POSPac as well

Hey, it looks finally someone understands me. Dear @Cire210 , this situation is just a nightmare !! I am disappointed by both of the sides: EMLID and Applanix. Each side sends back the fault to the other one. Emlid said that it is the fault of Applanix because the software doesn’t want to process the data (due to the poor L2 data logged). Applanix said it is the fault of Emlid because the receiver record only L2C, and I must check with emlid if they didn’t send me a bad antenna from a bad batch from the factory, and I should buy one of their recommended antenna, which cost minimum 4000$… BTW I didn’t get any news from emlid from my last post.

I made a new test a couple of days ago, and pospac was working with the log file. I pushed the log at 5hz and after, with rtklib I exported the rinex file with the option every ‘0.5s’ . I noted also that the base station need to log during minimum of 2h30min otherwise pospac will fail…and even with 2h30min we still not sure. So to be sure I can get a minimum of accuracy I always bring the RS2 with the RS+ which is logging also in the same time, and in case of pospac don’t want to process the data, I can calculate the position of the Base station with RTKLIB…but, of course, it is more material to bring, more stress, more work…etc…

Goog luck Eric

1 Like