RS2 will not maintain fixed solution

Received the RS2 little over a week ago, and have attempted to collect points in different locations about 5 times (probably about 10 hours). In a 2 hour session, the unit will only achieve a fixed solution a couple of times for few seconds and quickly revert back to float. I am in Southern California, am using one RS2 with the CRTN NTRIP infrastructure as a base (8.5 km baseline), and everything seems to be working properly. I usually have 12 to 17 satellites in the green (>40) with base satellites in grey (12 to 15), age of differential low (<1s), clear horizon, and PDOP between 1.2 and 1.6. I am using GPS, GLONASS, GALILEO, and QZSS. BEIDOU seems to cause the location to jump all over the place. Not sure what I am doing wrong. Any help would be greatly appreciated. Report attached.SimpleReport20190727.pdf (61.1 KB)

Maybe try this:
Instead of STATIC, set to KINEMATIC.
Instead of 40 SNR, try 35
Since you are using only 1 ROVER RS2, BASE MODE settings won’t apply, but maybe Enable RTCM3 message 1124 when / if using LoRa later.
Not sure if this pertains to RS2??, enable GLONASS AR MODE.
I do not use NTRIP, I use LoRa. But your settings may need to be looked at here?
I.e. send position to base: single (maybe this should be FIXED?) Maybe you need it’s (the NTRIP CORS BASE) position also?

See what that does.

Then try enabling BEIDOU too after if better results, for even faster better results. The more satellite constellations the better if able to use them.

It is worse when set to Kinematic (never fixes and RMS is high), and I started at 35 and moved to 40 for SNR - seemed to fix more often since I am tracking many satellites. I have base mode turned off, and there is no setting on the RS2 to turn on GLONASS AR Mode. There is also no interface to change the NTRIP settings (perhaps this is in a config file somewhere?). Base station coords seem to come from the caster.

1 Like

Can you try recording the ubx on the rover, and corresponding NTRIP stream as well, and post it here? Just something like 20-30 minutes.

3 Likes

Going by the status map for CRTN, it looks like there are over a hundred stations to pick from, and many are listed as ‘down’ (in red):


Have you checked that your station’s status is ‘up’ (blue)?
Have you tried a different station?
Can you post a screenshot of your satellite graph (showing grey bars; widescreen if possible to show the most satellites)?
Do you have 5 or 6 ‘G’ satellites with good SNR for both base and rover?

As @wizprod mentioned, the raw log files would be helpful for troubleshooting (UBX and RTCM3).

2 Likes

It shows FVPK station is up. Something screwy.

path: CRTNWAYPOINT:***@132.239.154.80:2103/FVPK_RTCM3

Fairview Park?

Yes, using Fairview Park in Costa Mesa. Have tried Santa Ana (SACY) and Cypress (BLSA) with no results. Screenshot of satellites:


Log files (though I have not figured out how to view them yet - RTKLIB?):base_201907281615_RTCM3.zip (678.2 KB) raw_201907281615_UBX.zip (8.2 MB)

1 Like

Hopefully you’ll get some real help now that you’ve provided those files. I get the purpose of NTRIP and CORS etc, but I personally prefer using LoRa and using my own base, so I don’t have to deal with a base network out of my control. But, yes, things should work either way… hope u get it worked out.

It’s probably just too many people out there! ; ) I used to live in many different areas there in SoCal… just awesome. ; )

EDIT: curious… is there a reason why your using Static instead of Kinematic since collecting multiple points? Seems this should be Kinematic no matter what?

Started with Kinematic, though I am trying to collect ground control points for UAV mapping, so the rover sits on the same point to collect that point (survey tool), and then i move onto the next point after collecting the point. I have only obtained a fixed solution in the static mode, and only for about 5 seconds at a time. It may be that I will need to purchase my own base, and post process the results, but I am hoping that the CRTN NTRIP will work.

2 Likes

Yeah, ideally you shouldn’t have to…but it is more flexible… but yes, agree. You’ll get it worked out with some of the great pro help here…and if defective, I am sure Emlid will be happy to oblige.

You should be getting better results at least with the GPS.

It could be the “and then I move” part that is getting you. If you move, then switch to kinematic. If you stop and feel like you want to use continuous, then switch it back.

Also, and separately: in your screenshot above, you have enough GPS-only satellites to obtain a fix. Disable all other constellations. Try with GPS-only. See if you get a fix. If so, then add the constellations back, one-at-a-time. Maybe one is causing you grief.

Good luck!

1 Like

I have tried it with all combinations with no results (GPS only, GPS/GLONASS, GPS/GALILEO, GPS/GLONASS/GALILEO, and other combos with QZSS and BEIDOU at various frequencies. I thought it might work best with GPS/GLONASS as CRTN NTRIP uses these constellations but no results. I also tried setting up 2.5 km from a CRTN base station in a very open field tracking 22 satellites and still no fix. Very frustrating. And I am just sitting over a point for an hour without moving and no fix. CRTN troubleshooting mentions NGA antenna calibration file - would this be relevant? Seems like it should be working, but it will only achieve a fixed solution about 5 seconds in an hour time span.

1 Like

I’m looking at your log file. Something seems wrong.

Can you describe the location you were at or post a picture?

Was there any sky blockage at all? Any electrical/transmitter equipment nearby?

2 Likes

Well, I had started with the ‘old’ RTKLIB for processing. Much better results with the ‘new’ RTKLIB for use with RS2 (see the docs).

OK, so probably similar to (but not the same as) what you experienced, where RED=single, YELLOW=float, and GREEN=fix:


That is the result of processing the full log based on the base location being set by data in the converted RTCM3 file. It just picks one base position (and it does not move).

This is the actual position of your “base” during the logging:


See that is moves over 10km during the log. You probably tried a couple of different stations during this log and that is why it moved. If the RTK processing engine isn’t ‘reset’ after you do that, then you are asking for trouble. Reboot works, or you could just try removing and then adding back a satellite constellation. Basically just doing some action that will reset the RTK processing.

So I picked the last part of the log where you can see the base was stationary for a very long time. These are the results of processing that segment of the log:

You did loose the fix several times (maybe there was blockage over the antenna, etc.), but it is a pretty good log with over 95% fix.


So, from what I see, I would recommend that you set the NTRIP settings first and then reboot the RS2. Your time to fix should be very short. Also stick with kinematic mode until you have some successes under your belt, then you can switch back and try static mode.

Please report back after your next tests. (Hopefully with the results you were looking for :slight_smile: )

2 Likes

That is very interesting. During that session, I did try several different bases. I used the closest one for the last part of the log, but the RS2 reported float status for the entire duration that the log is reporting fix. Perhaps it is a problem with the RS2 or Reachview reporting the the correct current solution?

1 Like

After reviewing the logs, it seems that a fixed solution is being established, but the unit (flashing solution status indicator) and the Reachview app are reporting float solution. I re-flashed the unit and re-applied the update, but this did not change anything. Might there be something wrong with the RS2 itself, logging one state, but reporting another?

1 Like

Don’t mean to complicate things, but since you have only 1 RS2, you may also want to look into secondary testing using rtk2go.com to help rule out if CRTN is having trouble ? I do not use it, but others here do. I think they are based in LA, so may be some nearby?

According to the logs, everything is working as it should regarding achieving a fix in approximately 10 seconds and holding the fix throughout the observation. Here is 5 minutes I captured this evening:

Problem is, the unit did not acknowledge the fix solution at all. The RMS is low indicating a fixed solution when trying to use the Survey tool, but the tool will not capture the point because it thinks the solution is float, when the logs say it is fixed. The Reachview app and RS2 also indicate a float solution. Something is not communicating properly within the RS2 itself. Perhaps defective unit?

3 Likes

A strange thing, that is.

Well, if that .pos file you are showing is straight from the RS2 (not post-processed), then the hardware is fine; the processing software is fine. There is just some glitch between the processing software and the UX (user interface).

I would save a full system report (found in the settings/gear-icon menu) and send it to support@emlid.com along with a link to this thread. Save your log files in case they want them as well. That is a just proactive measure to speed things up.

Then let’s wait and see what Emlid has to suggest.

3 Likes

Hi @danrich1961,

I’ve also tried to process your logs and the PPK result seems to be fine.

Also, the RINEX logs from your base station don’t show SNR values (check the pic below), whereas the screenshot of the Status tab you posted above displays the base SNR bars. Are you sure this screenshot correlates with the log you shared?

That’s why I think it’s not a hardware issue. It seems there is might be something wrong with the data that base broadcasts so it’d be great if you have a chance to test with another caster.

May I ask you to share your RTK solution files as well?
Please also send me the Full system report in PM, as @bide suggested.

1 Like