Bad NTRIP estimations

Hello everyone,
Last month I brought an Emlid Reach module to improve the positioning accuracy and precision of a rover. The module will be used to locate a buoy which has attached an acoustic device (USBL) which provides with the relative position between the buoy and an acoustic modem located in an AUV. In such a way that having a geolocalize buoy I am able to geolocalize the AUV.

TEST 1
I have start testing the module with the following config, fixed in an static location.
Positioning mode: Kinematic
Systems: gps, sbas, glo, gal
Dynamics model: off
Input source for base corrections: off

For this first test the module was fixed in a roof with really good visibility, for a period of 30hours at 1Hz.
Next figure show the obtained measurements in meters. With this first config I obtained a positioning error standard deviation of approximately 1m.

TEST 2
In order to look for a better an improved performance I have tried the same configuration in periods of one hour for 1Hz, 5Hz and 10Hz.
Positioning mode: Kinematic
Systems: gps, sbas, glo, gal
Dynamics model: off
Input source for base corrections: off

It seems that the precision it is not related to the measurement frequency.

TEST 3
For this test I have used ntrip corrections.
Positioning mode: Kinematic
Systems: gps, sbas, glo, gal
Dynamics model: off
Input source for base corrections: ntripcli
www.euref-ip.net
80
MALL0

The estimations seem to be very accurate. However, as shown in next picture, at some moments it produces some bad measurements and then takes a long time to converge. Resulting in an standard deviation of 4m.

I would like to ask you if anyone have had this problem in order to share possible solutions.

Thanks!,
Eric Guerrero

Reach image version: v1.2
ReachView version: v0.4.9

2 Likes

What integer ambiguity res did you use? instant, continous or Fix&hold
Bad fix may also be on the ntrip providers side, you wanna check if thay had issues or any other downtime during this period.
Is this a paid or free service?

Hi,
I am using the default advanced configuration, in which the ambiguity is set to continuous.
The test was performed during the past 24h, I don’t see any issue in EUREF MALL0, would you recommend me any other place to look for ntrip issues?. It is a free service.

Do you think that I should try with another integer ambiguity resolution? I don’t really know how it could affect the results. In the previous tests, without introducing corrections, this problem didn’t appear.

Continuous should work just fine. Continuous converge much faster then this, it must be something messing up signals or the sync to base.
Did you check your internet connection for downtime or bad ping/latency?
This deviation that occured for about 2 hour? it must be something that happen outside the reach unit. Maybe something blocked the antenna or some of the vitale satellites

Edit: and check flares for your time and location
http://www.solarham.net/

I could also suggest to upgrade to ReachView 2.2.6 as it has numerous improvements. If the issue persists please provide raw data and corrections logs and we will be able to analyze what happened.

1 Like

2.2.6? :blush:

3 Likes

Hi!
I am not able to see any disturbance in the base station MALL0.
The experiment conditions were well executed, no shadows and proper internet connection.
It seems like some ntrip corrections are not well integrated and deteriorate the positioning.

I have performed another experiment, with the module located indoors, in a window facing north. It was assumed that the measurement dispersion would be wider, but I wanted to check that without any possible shadow (for example birds), the module still produces noisy measurements at some moments.

Log files:
https://drive.google.com/open?id=0B86P_GMInddoYmpFYjFsZTBDZTQ
https://drive.google.com/open?id=0B86P_GMInddoemFTMmNyRFhlX00

Hi!,
I will update to the new version of ReachView, but before reflashing I would like to be able to obtain proper measurements using default settings. The log files of the Test 3 are the following:
https://drive.google.com/open?id=0B86P_GMInddoS3VWRHRhUTR5VVE
https://drive.google.com/open?id=0B86P_GMInddoN253RlZEekRYS0k

Do you require any other file?
Thanks!!!

Hi Eric, could you please share the solution file from the Test 3 as well?

Hi ivereninov,
I used a tcpclient as an output source for the solution, without keeping record of the solution into a file.
I will remake the Test 3 during this weekend, would you propose to test a different configuration?
Thank you!

Eric, could you please update to the new firmware? It has positioning improvements and it will be more efficient to search for issues in newer version.

Please log raw, corrections and solution in LLH format.