Hi Bernardo,
The static mode is useful when you process a log recorded above a single point. It is similar to RTKlib’s static mode.
Yes, this was my doubt, but now with your answer I’m clearly.
Thanks
Hello and thank you for this software, I think it’s great.
But I also have a little problem with it:
I have a rinex file as a base with a fixed antenna height of 0.0790 cm. If I now select “from Rinex file” as the base option in the studio software, the offset of 0.0790 cm is displayed as the antenna height. If I confirm this, the antenna height will be calculated twice as the antenna height was already used from the Rinex file. In my opinion, 0.00 should be the initial value here in order to circumvent the problem.
The problem already existed in the RTKLIB software, if I clicked on “from header” there and also entered an antenna height, the value was calculated twice.
I have another suggestion that would make our lives easier:
We fly with our drone or take photos with our camera in areas where poor conditions and multipath disabilities occur.
That is why we have just as many fixed and float solutions in our PPK evaluations.
It would be an advantage if we could somehow import this distinction into our analysis software (Agisoft Metashape). The accuracy of the different solutions plays a subordinate role for us, because we always specify 3cm accuracy for fixed solutions and 100cm accuracy for float solutions, or do not allow the float solutions to be included in the calculation.
To do this, we would need a way to somehow import the events.pos file into Metashape. This only works if we have the image name in this file.
Would it be possible to export a CSV file from EmlidStudio, where all information is available? It should be the events.pos file with a prefixed picture name. It would of course be ingenious if the user could choose which attributes he would like to output as a CSV file.
That would help us a lot, thank you very much.
1 Like
Hi Dieter,
If I confirm this, the antenna height will be calculated twice as the antenna height was already used from the Rinex file.
As I know, RINEX files from remote bases usually contain:
-
Coordinates of the marker in APPROX POSITION XYZ
-
Antenna name in ANT # / TYPE
-
Height of the receiver’s bottom above the marker in ANTENNA: DELTA H/E/N
Emlid Studio gets all these values from the RINEX header and applies them to calculate the correct position of the base’s antenna.
If the measured height offset is applied twice in your case, please share your logs and expected values. I’ll check why it happens.
The accuracy of the different solutions plays a subordinate role for us, because we always specify 3cm accuracy for fixed solutions and 100cm accuracy for float solutions, or do not allow the float solutions to be included in the calculation.
Please send the data from one of your flights to me. Possibly, I can improve your solution so that this step won’t be needed. Even if it doesn’t help, we’ll still need this data to look into your request.
Believe me, there is nothing you can do to improve the solution, I think that’s out of the question;)
The solution is bad.
The “measured height” is also not calculated automatically and always twice. I am only saying that it is misleading if the “measured height” from the rinex-File is used as a suggested value in the field for the pole height. If I accept that, and only then, will the “measured height” be calculated twice.
Hi Dieter,
I’ll discuss your request with the team. If we need more info, I’ll let you know.
If I accept that, and only then, will the “measured height” be calculated twice.
We’ve done some tests and confirmed that the height is indeed applied twice if already defined in the RINEX header. Thanks for noticing this! We’ll fix it.
For now, you can disable the Use antenna height toggle and set the Measured height to 0. It should give correct results.
1 Like
I think that’s not right, if you set the button “use antenna height” to off, the height of the Rinex file and the antenna type is also not applied. In my experience, this button must be on and the antenna height must be 0.
Hi Dieter,
In my experience, this button must be on and the antenna height must be 0.
Hmm, it indeed works this way now, but it’s not how it’s intended to be. We’ll fix it too. Thanks for your observation!
I’ve also thought about your request. I see that a CSV file you described can simplify your current workflow. So, I’ve passed this idea to the team.
Still, it should be possible to get accurate coordinates right away to forget about the filtering step at all. If there are many Float solutions in a PPK drone survey, it’s often related to RF interference. Onboard electronics and drone motors produce RF noise which affects GNSS signal reception. Reach should be placed as far as possible from them.
3 Likes
I would like to describe a little what we do as a surveying office and how we fly. In addition to the normal overflights (orthophotos / DEM) at a height of 50-100 meters, where all coordinates are fixed, we also generate views of buildings. Church, protected facades are just as much a part of it, as are walls and sometimes bridges that are worth preserving. To do this, we sometimes have to fly into areas where there are strong multipath effects or where the shadowing only allows a small number of satellites. Then of course we only get float solutions. The entire image structure is then calculated with Agisoft metashape, and then only the coordinates of the images are used as control points, which are also exact. And these are just fixed solutions. If I have 10% of the images with exact fixed solutions and these are well distributed in the project, then the accuracy is completely sufficient.
So it is not due to the drone and the interferences that occur, but to the satellites that are not being observed. We have a GPS on the drone and a GPS on a camera for the pictures on the ground. There is the same problem there.
Due to the way we work, a distinction between fixed and float solutions is essential!
Dieter
1 Like
Hi Dieter,
Wow, that’s a rather unusual application. It makes a change. I’ve passed this info to the team so that we can consider it while looking into your request. Thanks for the explanation!
Hi Kseniia,
I am doing some trials with the Emlid studio App and seems great. I have a question, probably trivial, but I can’t find a solution to get a good explanation about it. I have drone imagery acquired with a small UAV with an additional antenna for PPK. So I have a ubx file from the drone and ubx file from my reach RS+ base (the new one just replaced thanks to your support 
).
On the field, since I have no access to a known trig point, I averaged the single base position for 30 min and took a snap of my screen to remember the coordinates for the next survey ( I also physically mark on the ground that position). Now in the Emlid studio when I uploaded the ubx file I noticed after RINEX conversion that the coordinates from the header are slightly different (especially Z)
So I am trying to add averaged coordinates manually but that option seems greyed out…
What I am missing?
Hi Daniele,
Now in the Emlid studio when I uploaded the ubx file I noticed after RINEX conversion that the coordinates from the header are slightly different (especially Z)
The Average Single mode in RTK and the RINEX header provide base coordinates that can be accurate at a few-meter level. So, such a difference can indeed take place.
So I am trying to add averaged coordinates manually but that option seems greyed out…
The Average of Single Position mode will re-average your base position in Single. To enter the coordinates you’ve collected in RTK, you can choose Lat/Lon/Height.
One important note: even if you average the base position in Single for a relatively long time, it will give you only relative accuracy. To obtain absolute accuracy without a known point nearby, you can average the base position in Fix with a local NTRIP service.
Can Emlid Studio show duration of the UBX or Rinex files in UTC or other time formats?
Hi Kseniia,
I processed the data as you suggested and in fact, I achieved very good results with PPK. All camera (drone) position with fix solution. Amazing!
Thanks!
3 Likes
