Hello, I want to change the positioning mode from Kinematic to Static. I used to see this in the GNSS Settings menu, but it’s not there anymore. What am I doing wrong? I’ve looked everywhere in Emlid Flow to change this.
1 Like
The ability to change between static and kinematic on multi band devices was removed in the latest version 31 update. There is no real difference, so you dont need to worry about it.
2 Likes
good to know, thanks…
1 Like
I just discovered a potential problem with this. I logged data for four hours today using the OPUS preset. I tried uploading the file to OPUS twice and it failed both times. The explanation I got was the data was too noisy or it was collected in kinematic mode. I will keep trying. I hope files logged using the OPUS preset can still be processed by OPUS even though they’re now in kinematic mode by default.
1 Like
I don’t think there is any distinction in the rinex header specifying static or kinematic.
2 Likes
I can confirm there is no link between what happens in the RINEX log and the positioning mode, which is a real-time algorithm to get a position.
1 Like
I can confirm that there is definitely a difference between kinematic mode and static mode when it comes to processing LIDAR data. Earlier this year we have massive amount of logged LiDAR data become useless because the mode the base was in after an update defaulted to kinematic instead of static. We need this option( whatever it does) in the background to allow us to use our 7 Emlid RS2 base stations for our business. We will not be updating past FW30.1 until this feature is reapplied.
3 Likes
Don’t ya just love it when things are screwed with when working just fine before? 
Just make it an option / choice, don’t kill the feature.
Provide the evidence to Emlid, so they can take a look.
1 Like
I’m not sure what Emlids reasoning for this … I suppose there would be a difference in the positioning algorithm used for both.
However, static implies a non-moving device… there should be an algorithm setting the base “held” position after 1 minute then continue logging using that base position for whatever length of time.
If using kinematic in a static situation, the device is “bouncing” around a meter or two causing the error when submitting to OPUS. This issue can be caused by a number of reasons whether by satellites moving, atmospheric issues such as solar flares or the type of manufacturer receiver accuracy.
I suppose there’s some reasoning behind Emlid’s methodology but there should be a setting for using either static or kinematic in my opinion.
2 Likes
Could you develop the workflow here ? How did you see that something was wrong ?
The feature we are talking about here is the real-time positioning mode of the device. It is a parameter of the embedded positioning engine. It changes how the real-time position is computed by the receiver from the raw inputs that are GNSS observations & navigation data. In other words, it changes the NMEA output - not the raw data, as they are inputs.
raw data (obs & nav) ---------> [positioning engine (static or kinematic)] ---------> position XYZ
When a device is used as a base, the real-time positioning mode is only used during the setup time. At the end of the setup, the base has coordinates with an accuracy depending on what method you chose (average single, float or fix).
Once the setup is done and the base starts to emit some corrections, the real-time positioning mode of the base should not be something to be concerned about, as there is nothing related to this in the correction data. The base could even stop computing its own position at this point, the correction message should not change a bit, as correction is made of the base XYZ at the setup (not in real-time) + GNSS observations & navigation data.
raw data (obs & nav) + XYZ at the setup ----------> [correction maker] -------> correction data
When doing RINEX logging, the real-time positioning mode of the receiver is also not relevant, as the RINEX file is only made of the inputs - GNSS observations & navigation data only.
raw data (obs & nav) ----------> [RINEX maker] -------> RINEX file
5 Likes
Hi @dronemapper23,
Static mode impacts only RTK, and error messages in OPUS don’t always allow us to determine the issue right away. So, we would like to investigate it more thoroughly. Please share raw data to support@emlid.com so we can try to obtain the OPUS solution together.
1 Like
Hi @RekonVashaun,
As mentioned by @dpitman and @Florian, Static Positioning doesn’t affect the PPK method. But we’d like to figure out what’s causing the issue and how we can help with it. Can you send the data to support@emlid.com, as well, so we can take a look?
1 Like
Any updates on this issue?
I just had the same issue today.
1 Like
Seems EMLID was waiting for @RekonVashaun to submit their data? To get a head start, you should also. Seems to me EMLID could perform their own tests also with OPUS and the changed STATIC->KINEMATIC setting??? This important setting obviously needs more looking into and clarification etc.
Please send data to support@emlid.com and we will take a look at it.
1 Like
Has there been update to this post? I have the same problem and emailed my files to Emlid.
Hi Keaton,
We got your files. We’ll look at them and let you know what the issue could be.
Is there any fix to this problem that you can post on here so everyone can enjoy it?
1 Like
Welcome to the forum!
In Keaton’s case, we were able to process the files using OPUS’s beta version. This beta version uses satellite constellations other than GPS for processing. Another option is to post-process the logs using the Static processing option in Emlid Studio. For this, you’d need a base correction file from one of the nearest CORS.
From our experience, issues with processing files in OPUS are tied to the environmental conditions rather than the static/kinematic mode. Can you send logs to support@emlid.com and briefly describe your issue? We will look into them!
1 Like
I actually just tried again and it worked this time. Thanks for responding!
1 Like