Not able to reach fix position since ReachviewApp update to 0.4.3

Hi,

Last week I was able to fix RTK position off-line, logging Base and Rover files (with ReachView 0.0.3) and postprocessing them with RTKlib. I updated both to v0.4.2 for having access to time marks and reflashed both modules with the last Image (via the web repository). Since I did it I have access to time marks but it is unable to reach not float nor fix RTK position. I tried off-line and tcpsvr/tcpcli for base correction transmission. I can see the grey bars on Rover Status, with several GPS sats in green (more than 5). I tried to swap latitude/longitude coords. of the base (according a recent topic in the forum) without success. I was playing with different basic rover configurations, no success.
Since I updated the ReachViewApp I noticed that after changing the configuration the rover is unable to update to the new one, I have to reboot the module to control the configuration again.

Is there a ā€˜secretā€™ parameter I was not able to detect that I have to control from version 0.03 to 0.4.3?

Thank you for attention.

Regards,

Albert

Hi!

What is your current version, after all? When working in RTK mode, did you have grey bars on the rover? How did you get base coordinates?

1 Like

Hi, Egor,

Finally one hour ago I could fix the position in RTK!, nevertheless I donā€™t know what exactly I did to success.

I am working with v0.4.3 in both modules.

I was changing a lot of parameters, I have to recognize that in a non methodical way, so I donā€™t know exactly I have done.
Yesterday we had the whole time the gray bars, but I couldnā€™t see float nor fix position status. Today, after changing a lot of parameters I could see float status, perhaps after recalculating the base position (programming it in rover single mode and averaging its position during 30ā€™). Do you think that this could be the problem?, After updating both modules from v0.0.3 to v.0.4.2/0.4.3 we programmed the same base coordinates as the ones we used last week with success, when we performed an experiment placing the ROVER on a linear motion unit, moving back and forth several times. We had a repositioning error less that 2cm horizontal, I can send you the graphs with the results.

Both modules are in GPS-GLONASS-5Hz, and linked by tcpsvr/tcpcli by means a hotspot. Now Iā€™m trying to reach a RTK fix position off-line, this is the way that I have to work with I our experiment.

Today I found the same problem trying to save and/or change the configuration in the rover unit after serveral iterations. But I could do it after changing to base and returning to rover.

Regards,

Albert

1 Like

Great to know that. Wrong base coordinates could definitely prevent you from getting a fix, as the RTK algorithm relies on them being correct.

Iā€™ll look into the rover problems, thanks for the report.

1 Like

Hello Egor:
You say above ā€œ Wrong base coordinates could definitely prevent you from getting a fix, as the RTK algorithm relies on them being correct.ā€

Doesnā€™t this directly conflict with the documentation for the Base Configuration where it says:
"ā€¦.However, if you are only interested in roverā€™s relative position accuracy, you may use a less accurate position for the base."?

I just want to make sure that Iā€™m understanding what you are saying. If my base station coordinates are not that good would it prevent me from getting to the status: fix? Does it become more difficult to get to a fix with increasing inaccuracy of the base coordinates? How ā€œgoodā€ do these coordinates have to be to consistently get a fix?

Regards,
Matt

Hi!

Well, single GPS solution is more than enough to get fix status. However, swapping latitude and longitude gives an enormous error, too much for the system to get a stable solution.

Thank you for the clarification