No fix solution even with best signal and RTMC3 data

Hi there,
We received Reach RS last week and we weren´t able to get proper RTK fix since.
I have tested it in all posible locations and no fix solution was ever made even if Reach had perfect sky view.
Got latest firmware and everything.
Reach RS is in default setting with Galileo enabled. RTCM3 stream from NTRIP base stations network.
Although something is weird. In status section there are no gray bars representing base signal and AR validation ratio is zero. Could it be that Reach can´t parse RTCM3 message for some reason? NTRIP server is sending 1004 instead of 1002 message maybe that´s the problem? I could send you logs, but can´t upload here for some reason.

Filip

Could you send screen shots of your settings? Did you get float solution? Or did it stay on single?

I am gonna send pictures tomorrow, but everything is mostly set to default. Yes, I only get single solution.

Here are raw and base logs. I tried them in RTKLIBnav and it shows float solution.
https://drive.google.com/drive/folders/0B47jXjnTj8kgTzVBTFlKRXh0cXM?usp=sharing

Is correction input turned on and configured and mode turned to kinematic? RTK settings should be set to kinematic or static. Default is single. Looks like somehow we’re not getting correction data through to rover. You are using ntrip so both units need to be connected to internet.

  1. Do you have good internet connection for both units?
  2. Can you confirm that the base station is connected to NTRIP and data is on?
  3. I should have asked sooner, is this your own base station, or a public one?
  4. If it’s connected, your rover should indicate so at the bottom of the correction input settings where you enter NTRIP settings.
  5. I have not looked at your logs but if they indicate float solution I would think your base station should at the very least at least show grey bars when data is coming through.

First step is to confirm that you are connected to the NTRIP server.
Next step confirm RTK settings on rover.
If there is an issue with the wrong message types streaming, somebody other than myself will need to have a look.
thanks

Yes it is turn on and correction are received as you can see in enclosed log. It is set to kinematic. I am using public fixed base station network. Internet connectiom is fine. Status window show 0.8s delay from last rtcm message in average. Yes rover indicates good connection to base station in the correction input window and number of messages is incrementing in time. I think everything you said is set up correctly. But the no gray bars are really weird.

Filip

OK, I see. you downloaded base files through rover? of course you have connection then :slight_smile:
One more important question: which browser and what kind of device?

Tried from chrome and android. Same result. Latest Reach Rs bought last week

Hmmm. yeah, not sure.
I think someone else will get involved in this conversation shortly :bell::bell::bell::bell:
Still send some screen shots of your settings, just in case there’s something that jumps out.

The minimal subset that is required for RTK to function is 1002 message for 1Hz with GPS observations and 1006 message for 0.1Hz with base station antenna position. Ref,this doc https://docs.emlid.com/reachrs/common/reachview/base-mode/
Also, rover is getting data from several satelites, but only one of them provides good snr above 45. So you have some sort of interference around your rover you need to find or move away from.
Hope this helps

1 Like

I will provide better data. I tested when i had 5 or 6 sats above 45 and it didn’t help. 1004 message widely used standard containing 1002 message in itself. Rtklib should be able to parse that. Here is message description https://www.use-snip.com/kb/knowledge-base/rtcm-3-message-list/
Could you confirm this? It is posible to use some sort of console or diagnotics in reachview?
I am fairly sure this is the problem. Can somebody look to sources a check the parsing algorithm.

F.

I think we both have same issue: I’m also getting 1004 messages and no fix so far…
Have you got any feedback about this or even found a way to get a fix?

I have set up a arrangement I call it a zero baseline testwith an antenna in a known point I divide the signal to a Reach GPS acts as a rover and a Trimble GPS (NetRS) actes as the base, the Trimble supply RCMT 3.0 data to the Reach GPS, data is sent via TCP / IP .
The messages sent from Trimbel are 1004, 1006, 1007 and 1013, and it works.

2 Likes

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