Hello folks.
using Reachview is v2.24.2, RTKPOST v2.4.3 Emlid b33
I have a healthy survey - very open space, nice and long (>600 mb of .obs). Working my way through config settings for PPK with a snippet - about 3 hours of survey work.
I have mucked around with all kinds of configs but cannot get the first half of the survey to fix, second half is great. Start going round and round in circles and getting frustrated so I switched and ran the filter type to backward (not something I need to do regularly) … now the back half of the survey (in time) is floating and half way through the processing, boom, get a fix in the first part of the survey (in time) all the way to the end (start in time).
I have stripped this right back to just GPS & GLO, couple of different masks - same result.
Summary: Forward filter type gets fix in the second half of the survey, Backward filter type gets fix in the first half of the survey.
Obs from base and rover are good and plentiful and no irregularities around the switch (float to fix) that I can see.
Hi @wizprod.
Unfortunately I cannot readily post. Limited connectivity, but sensitive site anyway.
Thought maybe someone would have come across something similar given the unique nature of it.
Times i ran into similar issue was due to noise or bad data from one or more satellites. (yes, you can get bad in wide open spaces)
Filtering out the specific ones fixed it.
Hi @michaelL
RS2.
Using a CORS, 35 km away, to fix the rover.
Last night I tried to do a static on the other RS2 I left out as a base backup. it was jumping in and out of fix and float.
Using the static RS2 as the base (without an actual fix for it - so average position), the rover fails to fix as well. So could be something in the Cors and rover and/or base - like @TB_RTK suggested, a erroneous sat - digging deeper.
Update. the CORS station data, which is uncompressed from crx to rnx (v3.04) then converted to .obs (v3.03) for consistency, crashes RTKPOST every time. It is not that heavy - only daily 30s.
Round and round in circles, as I believe so many of us do with PPK, but it wont execute. (runs fine using the backup base I left running over unknown mark).
Any advice on the RKTPost crash would be appreciated.
Thanks
Getting mixed results from playing with the conversion from Rinex v3.04. If convert to v3.03, RTKPOST crashes and exits. If I convert from v3.04 to v2.11 then back to v3.03 it runs but no fix…
I guess the question is if anyone has had a problem with v3.04?
If anyone has any insight as to why this would be troublesome it would be greatly appreciated.
I cant understand why it would crash RTKPOST. I reduced the .obs to just L1 and it doesn’t crash? what? Results are not great though.
Cheers
Also see @fmb694 had some issues with crx from Aus. Geoscience. Rtkpost crashes before correcting reach RS+ base with Australian gnss data
Solution involved: I was using the wrong gnss correction file. I think I have been able to find and unpack the right one (.o file) and used it to post-process my base station .obs and .nav files.
I’m not sure what this means, though.
@Simon_Allen would you know more about crx and rnx from Aus Geoscience?
I have not had a problem before, the only difference is that Aus Geo have changed the file formats available from their ftp. It used to be *d *n *g *m *o etc. etc., obs would be in v2.11. Now a crx is provided and the obs are v.3.04…
Do I understand right that this RS2 was receiving the corrections from a CORS? If yes, there might be two reasons why the solution wasn’t Fix all the time:
RS2 was placed in quite challenging conditions where the sky view was blocked
an Internet connection wasn’t stable
Could you please specify how you established an RTK-link between the base and the rover? Have you used RS2 as a rover as well?
Is there any chance you can share the file from the rover so I could check it? At this moment, it’s quite hard to understand what could be the issue here without seeing the logs from the receiver.
Hi @liudmila.slepova
No real time corrections going on at any time. All PPK.
I guess I have been through quite a lot of steps now and all my messages make it a little confusing.
Summary:
Undertook survey with the plan to PPK using CORS station.
Set up local base with another RS2 as a backup.
Have tried PPK with both rover and base and never get any really good results.
The native Rinex version from the CORS is 3.04.
Using the CORS data as either a *.rnx (3.04) or as *.obs (3.04) make RTKLIB crash
Converting to version 3.03 and 2.11 with RTKCONV allow it to run but yield poor results.
Tried conversion with GFZRNX, similar results. Native output is 3.05. So I tried converting to 2.11 then used RTKCONV to 3.03. This is the most promising so far.
Have also tried just using everting in version 2.11, not that good
Most recent finding is that I will not get a fix if L1+L2. I get a fix using L1, but the vertical position on the static base has a range of 60 mm over the course of an hour. I don’t think that is right.
A link to the CORS data is in a message above.
A snippet from my base is here : Transfer - Dropbox
The base would have been in position for 3 hours minimum at the start of these segment.
I’ve looked through the observational files from Reach and CORS. The data from Reach looks fine. Reach records contains 10 satellites with SNR above 40 (G10, G18, G23, G32, R15, R21, E05, E09, E36, J03). You can check this on the screenshot below.
Reach recorded the data from 00:00 to 01:00 GPST. In this timeslot, Reach has several common satellites with the CORS records. Take a look at the screenshot below. Counting only the satellites with high SNR, there are 9 common ones. This should be enough to calculate the Fix solution.
