CSRS-PPP service rejects Emlid RINEX file

In the past I converted .ubx log files from an Emlid M2 receiver to RINEX and then used the Canadian PPP service with those files.

When trying this again today in many cases I receive a rather terse error message from CSRS-PPP:

The RINEX file contains formatting errors in the observations at epoch 2021 2 5 12 5 4.01. Please correct and resubmit.

This is the corresponding epoch data:

> 2021  2  5 12  5  4.0180000  0 17                     
G12  21905888.569 1 115116222.317 1      2743.151          43.000    21905885.180 1  89700936.724 3      2137.902          36.000  
G13  21298179.737 1 111922689.700 1     -3633.238          45.000                                                                  
G15  20018251.311 1 105196619.707 1     -2149.701          47.000    20018248.609 1  81971380.698 2     -1675.245          41.000  
G17  21715753.584 1 114117056.135 1      -376.273          46.000    21715750.688 1  88922366.746 2      -293.393          39.000  
G19  21674489.423 1 113900208.964 1      1596.613          47.000                                                                  
G23  22347640.930 1 117437644.661 3     -1691.782          37.000    22347640.071 2               6     -1318.547          31.000  
G24  19810257.528 1 104103605.132 1       681.353          45.000    19810256.311 1  81119687.753 2       530.893          41.000  
G28  22748545.870 1 119544414.210 2     -3651.523          42.000                                                                  
R 4  20597292.148 4 110297563.221 1     -4516.376          49.000    20597283.912 4  85786960.106 3     -3512.889          37.000  
R 5  19109163.452 4 102149429.273 1      -806.655          47.000    19109161.302 4  79449547.040 2      -627.605          38.000  
R14  19448492.302 4 103671405.693 1     -2703.491          49.000    19448494.180 4  80633323.174 1     -2102.660          43.000  
R15  19166599.601 4 102420496.193 1       671.466          46.000    19166598.648 4  79660381.626 2       522.155          40.000  
R23  21614484.658 4 115622921.301 2       -64.536          42.000                                                                  
R24  22108512.587 4 118224152.677 2      2272.116          41.000    22108507.434 4  91952096.08525      1767.309          32.000  
E 2  23045321.709 1 121103981.685 1     -1902.692          47.000                                                                  
E 7  23627986.499 1 124165906.974 1       115.745          44.000                                                                  
E30  22230085.741 1 116819890.059 1       673.047          43.000                                                                  

This looks as innocent as any other epoch to me. If I remove this epoch the processing continues and then I receive a similar error message at an later epoch. Is there anything wrong with the formatting of this epoch generated by rtkconv and if so how can I prevent this from happening?

For reference these are the rtkconv settings (following the Emlid documentation):

I got this error for the first time today also. It seems to be a change (bug?) on their end. I eventually got my file to process by stripping out the GLONASS sats so you might try that.

Out of curiosity I sent again a file from a couple weeks ago that had processed fine and today it generated the error. I removed the GLONASS sats and it processed fine.

Maybe wait a few days and if it’s a bug they will fix it. You could also email their support.

2 Likes

Hi Alexander,

CSRS-PPP should work fine with RINEX files from Reach. Could you clarify whether you collected the data with a 1Hz update rate? We have such a recommendation in our PPP guide as well.

Sounds interesting. I’ve never faced issues with GLONASS sats when processing logs in CSRS-PPP. Maybe worth testing too.

I can see here that they updated the software on Feb. 2. Maybe a bug made its way in. I would report it to the service by e-mail with a sample file.

A file that generated the error on Friday worked fine today.

I had tried without GLONASS sats earlier because there’s a delay of a day or so between the availability of the more precise GPS ephemerides and the GLONASS ones. I have no idea if that was the issue. Anyway the service operated normally today on a file that wouldn’t process last week.

Thank you all for the helpful responses!

@svetlana.nikolenko: The file was taken at 3 Hz. This was working fine in the past so I did not change the collection rate here.

After some fiddling around I finally got the file to be processed without any errors. Here I had to disable all other satellites (GLONASS, GALILEO) and only leave the GPS satellites in the RINEX file. So this might be a workaround but I dearly hope that this is just a bug on their side which will be fixed soon.

Hi Alexander,

Would you mind sharing this log with me? I’d like to check how it works and clarify the issues with CSRS-PPP if they occur. You can PM me with it since it may contain sensitive info.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.