PPK Stop and Go Processing Failures

I have multiple files that i am struggling to get fixed solutions on my stop and go processing.

Can i share the files here and see what the issue is?

Yep, upload via WeTransfer or similar, and provide the link here.

Hello @UAVIS,

You can surely post the link to files (via WeTransfer, for example) here or sent them to support@emlid.com. We’ll be glad to help investigate it.

1 Like

Here is one example while not Stop and Go it is just a static process.

I logged an unkown point for approximately 8 hours. i have used a 1 hour CORS base Rinex at 87km away to try and process the location of the base on site.

I am getting FLOAT only solution and no fix?

Is this a single or dual frequency receiver ? Which Emlid model do you have ? Do the receivers have a clear view of the sky Multi-path is not good for any receiver. Also time on station for PP is important. PP an 87km baseline with only a minute or less will not give a reliable fix, if one at all.

87km baselines are a little long for post processing if you don’t have adequate observation time

That may be your problem.

Hi Jake,
I also ran it through Emlid Studio 1.6 and received the same Float results that you had obtained. I submitted the converted ubx to rinex 3.03 GPS only, 30sec data rate file to AUSPOS V2.4 and also to CSRS-PPP SPARK for their analysis. Both AUSPOS and CSRS-PPP returned results, which are enclosed here.
Your 13hr static RS2 Base data looked very clean and Google Maps showed a relatively open site position for your Base receiver. Also the HUGH00AUS0 AUS CORS Station was a 4 Sat constellation Dual-Band receiver,
AUSPOS_3378_1692887113378-99999999.pdf (792.5 KB)
with of course very good data. It didn’t looked like there was a closer station, maybe the White Mountains Nat. Park PNTL00AUS0 station is a possibility.

I guess, most likely it would be the distance factor for only getting the float results in Emlid Studio. To me, your going to have to rely on PPP for the position.

Edit: I see the included HUGHENDEN AUSPOS Base file was for only an hour duration, when I believe it should be for the duration of your Emlid Static Base observation.
Regards, Mark



GPS20230817203044AUS.pdf (1.3 MB)

Respecto a este tema, quisiera saber si el tiempo de medición en una línea base de 87 km (por ejemplo) existe algún tiempo mínimo por norma para que funcione correctamente el procesamiento con stop and go?? Espero explicarme y su apoyo.

Les comento que yo tengo un problema similar y solo optengo solucion en flotante. Espero me puedan ayudar
Saludos

@UAVIS,
I changed some settings and was able to obtain a Fix solution in Emlid Flow using static processing. You can download the file containing the best solution here. It contains only an hour of your observation as this is the duration of the AUSPOS Base file.

I used a combined filter type, increased the elevation mask to 25 deg, and in Integer ambiguity resolution turned off GLONASS option. The combined filter type allows ambiguity resolution to go forward and then backward and chooses the best solution. Increasing the elevation mask helps if signals above the horizon are disturbed, for example, because of obstacles.

2 Likes

A post was split to a new topic: Confirm that easting values look correct

A post was split to a new topic: Can;t get a fix solution on Stop and Go