RE: Emlid Studio v1.5 on Windows 10 Pro
Begin a new ES session with Static processing satellite settings with all SVs checked, save, process One Best Solution.
Close ES.
Begin a new ES session with Static processing satellite settings with only GPS checked, save, process One Best Solution.
Now compare. I cannot explain why the (2) One Best Solutions are identical.
If you’re curious, both units, the one on 17U & the one on T159, are RS2+
Hi !
From what I see, you imported a .23n navigation file, which is GPS only. This way, Emlid Studio can only use GPS satellites as it’s not able to determine the position of the satellites from other GNSS.
Hence, there is no difference at the computation level between both the settings you tried.
Do you have at least a .23g file in your data ? That would allow to use GLONASS in addition.
If not, I would suggest to check the raw data logging settings in Emlid Flow.
Thank you Florian!
You are correct about the limitation of the MDOT nav file:
As for the Emlid Flow v8.9 Settings, Logging, Logging Settings:
The files that Emlid Flow exported didn’t include a .23g file:
The 23P file will do it. It is a Mixed systems file. You should find every GNSS in there.
Great! Thank you very much Florian. I have many calculations to revisit and errata to prepare. I have also alerted MaineDOT as their Data Shop RINEX downloads include just G: GPS. I’m most thankful to you for helping.
And in case anybody else happens onto this thread:
(20230713 0627 UTC-4) Postscript: MDOT’s downloaded packages do include a G file (GLONASS), and if applicable, the L file (Galileo) but not combined into a single (MIXED) ephemerides file; i.e., *.nav
A problem that I’ve noticed in Emlid Studio v1.5 is that it appears that the user is unable to load more than one nav file at a time
Hi Kelly,
I can confirm Florian’s suggestion about the navigation file.
I have a question though: if you work with two Reach RS2+ receivers, why have you taken the navigation file from CORS? Both base and rover should have mixed navigation files with ephemeris from all constellations.
Good question Kirill. Thank you for asking.
The base was post processed using 4 different methods; i.e., NRCAN, OPUS, ES with MEPH and ES with VRS. Both the MEPH (CORS) and VRS downloads came from MaineDOT and included their own nav files.
I erred in thinking that these MaineDOT nav files included all available constellations. Also, I was unaware that the Emlid P file should have been used in all cases. Emlid might consider adding a line or two to item 5. introducing the reader to the P file, as well as a cautionary note that CORS nav file needs to either include all SVs; i.e., MIXED, or the user will need to add all applicable individual constellation nav files.
The same errant nav files used in the computations for 17U were then used in the 17U-T159 computations. Before returning and revisiting the 5 Shared Solutions (from my earlier report) I must reprocess the 8 files on 17U, for both methods using the MEPH and VRS.
Hi Kelly,
Emlid Studio supports RINEX files not only from Reach receivers, that’s why it’s not mentioned in the tutorial. Moreover, the navigation file may depend on the satellite constellations tracked by either CORS or Static receivers, so the mixed navigation file is not a must in this case.
Hi Kelly,
Most post-processing programs do not indicate how many ephemerides you must enter to perform a calculation, since each professional, according to his criteria or requirements for the work, chooses which constellations to work with.
It is good to check which constellations the base is able to track, because in GPS you only work with the data in common. So I could say that if your base tracks 2 constellations, and the Rover 5, you can only work with the 2 constellations that are common to both devices even if you use a *.yyP file.
Generally the LOGFILE of the CORS indicates which constellations they track.
Thank you for your reply, and yes, I agree, most of the GNSS processing programs that I’m familiar with don’t ask for the user to manually enter the appropriate orbital data. Instead, these softwares automatically will fetch the appropriate ephemerides based on the observation file. Most will also allow the user to choose, if available at the time, to use precise orbital data, again, being automatically fetched, or supplied by the user. In a similar fashion these other GNSS processing software will also automatically fetch all of the relevant CORS obs files, or alternatively allow the user to select specific multiple CORS which will then be automatically gotten for post processing and then finally arriving at a more robust least squares solution than what Emlid Studio v1.5 currently offers with its single baseline approach.
And yes, I fully agree about checking that I got the correct nav file (!!!) and I’m quite thankful for everybody helping to underscore this need!! Additionally, the CORS Site Log file lists the complete site history including the current receiver satellite system capabilities. It’s interesting to see when the equipment was last upgraded.
So in your experience working with Emlid Studio, and you were using CORS data, including the various individual .**n, .**g, .**l, etc. navigation files, what do you do? Do you process the same obs with each individual navigation file one at a time in Emlid Studio and then average their results?
So I went back and performed a bunch of computations using the RS2+ .**p file and have fixed all of the various bits in the report that I’ve begun writing including fixing the illustration of where these 8 days of observations fall on the mark. But before making the final corrections, I thought that this image would be worth sharing as it shows the difference it makes using the correct nav file.
The (8) NRCAN and (8) OPUS post processed results were averaged and their 2D location was used to center the full scale georeferenced photo of the mark in Global Mapper Pro v24.1. Their points are accordingly shown fairly tight in 2D.
The larger diameter EmlidStudio icons represent the GPS only nav file post processed results, (8) MEPH & (8) VRS. The smaller diameter EmlidStudio icons show the benefits of including GLONASS in the (8) MEPH results, and the benefits of GLONASS and GALILEO in the (8) VRS results. And if you’re curious, MEPH is 34.4 kn from the mark 17U. The VRS is located just a few meters from 17U.
Kelly, does the monument not have an assigned coordinate from which to georeference the photo?
Edit, looking at the marker, is it actually just a pseudo monument?
Hi Dave,
Thank you for asking and sorry I wasn’t overly clear.
Yes, the mark, 17U, has an assigned coordinate. For these recent Emlid tests, its assignment is predicated on about 100 hours of observations using (2) separate RS2+ units. And no, the photo isn’t a fake; it’s a recent photo taken during these tests, fully scaled, georeferenced and properly oriented with north as shown. It’s absolutely great nerd fun and I encourage anybody to do this. Global Mapper is perfect for doing the final steps, but you’ll also need, a camera tripod and more than one photo (without moving the camera) which needs to include a ruler. Ferrous marks make compass readings happen outside of the frame of the photo, but on other marks the photos can include the magnetometer reading or compass reading in the same photo. In Photoshop, or whatever editing software, crop, scale, rotate, and define the document size in real units; e.g., 10 cm. That’s a quick overview of the process, but if a tutorial is wanted, send a private message to me.
You’re welcome to read a little more on this part of these tests in the attached PDF
Shared Revisited 20230714 0929.pdf (2.2 MB)
Very interesting image and visual analysis.
Generally when I process in Emlid Estudio, I am careful about the baseline distances, although Emlid Estudio (and RTKLIB) can process long Base Lines, whenever it exceeds 30 km the result moves away from the geodesic mark (performing 2cm checks), if the observation is very short, and I using at least GPS AND GLONASS. I try not to exceed that distance and if I have to do a greater distance, then I use more robust software.
Hi Bernardo,
Thank you for the reply.
I am careful about the baseline distances, although Emlid Estudio (and RTKLIB) can process long Base Lines, whenever it exceeds 30 km the result moves away from the geodesic mark (performing 2cm checks)
When you say the result moves away, I understand this to mean the distance between the CORS and the surveyed mark increases while using Emlid Studio. Is this understanding correct?
I don’t understand what is meant by performing 2cm checks - please explain.
Could you also answer the earlier question above:
So in your experience working with Emlid Studio, and you were using CORS data, including the various individual .**n, .**g, .**l, etc. navigation files, what do you do? Do you process the same obs with each individual navigation file one at a time in Emlid Studio and then average their results?
Lastly, and other than Emlid Studio, what post processing software do you use?
Kind regards,
Kelly
In the first part I mean that when over 30km when making a baseline between two known geodesic marks, I have seen that the error starts to rise over 2cm, 3cm or more.
That’s why with RTKLIB or Emlid Studio, I don’t like to exceed those baseline distances.
Regarding the second question, my processing depends on the type of Geodetic Marker required. If a very precise mark is required, I observe several hours, process with minimum GPS and GLONASS, and never process only with GLONASS or only with GPS, always as a minimum for processing the two constellations simultaneously. If the distances are greater than 60-70km, and I need a high precision point, I wait 15 days to use precise ephemerides.
Regarding the software, I use different manufacturers, Trimble, Leica, as well as RTKLIB or Emlid Studio, gLab.
