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.
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.
good to know, thanks…
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.
I don’t think there is any distinction in the rinex header specifying static or kinematic.
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.
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.
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.
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.
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
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 firstname.lastname@example.org so we can try to obtain the OPUS solution together.