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

adenisot · January 28, 2020, 1:31am

Hi Everyone,
@polina.buriak
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.

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…

dmitriy.ershov · January 28, 2020, 8:02am

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.

adenisot · January 28, 2020, 8:06am

@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.

dmitriy.ershov · January 28, 2020, 10:25am

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.

adenisot · January 28, 2020, 11:02am

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)

Africawaterdoc · January 28, 2020, 11:22am

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.

Gabriel_C · January 28, 2020, 2:51pm

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

adenisot · January 28, 2020, 4:08pm

yes it’s what I was thinking too.

ok looks good hope the plans are still on the way

Africawaterdoc · January 28, 2020, 5:40pm

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.

adenisot · January 29, 2020, 1:44am

Thanks I will download it, it is interressant

adenisot · February 3, 2020, 5:34am

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.

applanix1831×292 31.2 KB

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.

applanix2682×108 24.1 KB

polina.buriak · February 5, 2020, 3:22pm

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.

adenisot · February 10, 2020, 5:48am

Ok thanks, keep me updated

Cire210 · March 21, 2020, 1:52pm

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

adenisot · March 21, 2020, 2:46pm

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

Cire210 · March 21, 2020, 3:12pm

@adenisot Yeah I’ve been watching this thread since Jan, but figured I’d jump in because I didn’t want to see it die. My curiosity is whether or not the actual board they’re using is capable of both L2 signals or if Emlid is just software limiting it. There’s enough on YouTube, and enough price differential between DIY and an used R10 to motivate me to solve this problem. Granted, rental Trimble equipment for 1-2days on lidar jobs is still really cheap, but a logistical headache…much like what you’re describing, just different headaches. I haven’t reached out to this particular youtuber, but with a Harxon antenna, I’m pretty sure I could turn this into a decent base. How to setup ZED-F9P RTK Base and Rover - YouTube

Not very helpful to you since you already have Emlid product, but shows the potential with a bit of DIY.

wizprod · March 22, 2020, 1:57am

The ublox docs are freely available: https://www.u-blox.com/sites/default/files/ZED-F9P_DataSheet_(UBX-17051259).pdf

Page 6.

polina.buriak · March 25, 2020, 9:13am

Hey everyone,

Let me sum up the information we have.

Reach receivers are capable of tracking the L2C signal only. This information is available in the Reach RS2 specification.

I have been double-checking the data from successful and unsuccessful processing for a while now. As I have mentioned before, the difference between them is the number of visible satellites capable of transmitting the L2C signal. I’ve attached the comparison of the logs.

On the left, you can see the log that the software couldn’t process. It includes 7 satellites capable of broadcasting L2C data: G10, G12, G15, G17, G24, G25, G32. Please note that G10 and G32 are very difficult to use for calculation as they have the lowest SNR and are not recorded for the whole time of the survey.

On the right, you can see the log that was successfully processed. It includes 8 satellites that are capable of broadcasting L2C data: G05, G12, G15, G24, G29, G31, G32. It might be difficult to use the L2C data from G15 and G31 for calculations because of their low SNR and the time of visibility.

Usually, this data should be enough for processing. I have post-processed the drone’s data Arnaud shared with around 98% fixed solution using RTKLib QT apps. I’ll attach the screenshot below.

As we have stated already, Reach receivers don’t track the L2P signal and on the latest firmware versions there are no issues with any L2-data losses. I am afraid there’s not much we can do about software algorithms used by third-party software.

Also, as I understood from the conversation with the Applanix support, the software is capable of processing the logs containing the data from different satellite systems. As I can see, the drone’s data contains observations on the GPS and GLONASS satellites only so multi-frequency data on other systems can’t be used in the position calculations.

It’s important to have as many satellite systems enabled as possible. It provides more data for the position calculation: the more satellite systems are visible, the more data from different satellites is used in the computation. It leads to better post-processing results.

At the moment, I can suggest the following ways to provide the software with enough data as Arnaud has described above as well:

to carefully choose the time of the survey depending on when the maximum number of L2C-capable satellites is visible. You can use various tools for GNSS predictions, for example, this one or the GNSS view app that @Africawaterdoc suggested previously
to enable all possible constellation systems both on the rover and the base. Our default recommendation is all GNSS (GPS, GLONASS, GALILEO, QZSS, and BEIDOU) enabled at 5 Hz for the rover and at 1 Hz for the base

Hopefully, this will help in achieving successful post-processing results.

Zinou · March 25, 2020, 11:30am

I can suggest also this tool so you can select only L2C capable visible satellites and choose a time of observation when the number of these satellites is maximum :

http://www.taroz.net/GNSS-Radar.html

adenisot · May 2, 2020, 5:26am

Just to inform you that I definitely solved the problem

→ I bought a set of Trimble R8S LT