We had fix with our rover in field but for some reason Emlid studio is not recognizing this. It is possible that it is because we used Field Genius but also can you not process rover and base data without fix and get precise information? If you run ppk in the field without the rover connected to the base station you will have single observations. So after processing in emlid studio is the .pos file accurate to the base station’s position? We used coordinates run through an opus solution so those are good. The next question is how do we derive coordinates from the .pos file? As I mentioned we used FieldGenius not knowing that you had to use a csv file from Reachview to get a corrected csv file. Look forward to hearing back from someone at emlid for some help!
You should still be able to use the processed over data. It may take some timestamp matching with your processed rover POS with your field genius data. I haven’t ever used field genius so I am not sure how that would look. First, you would submit your base static data to OPUS or NRCAN PPP. Then, you would bring your base UBX/Rinex (1sec rate) base file into Emlid Studio in the Kinematic section. Then bring in your rover UBX/Rinex and Rover or base navigation file. Then, manually key in your lat/long (presumably Nad83 2011) and ellipsoid height (metric) from your OPUS solution. Lastly, Check your processing settings and then process. You will then have a corrected (ideally fixed) POS file with every epoch collected by the rover. Review time stamps and positions against your field genius data.
Thanks Zach! I will give this a shot. Youre saying should be no problem even if the rover was not in fix - we can correct our data by manually entering our opus solution on the base file in emlid studio. I have updated the timestamps in the “reachview 3 csv” with timestamps recorded on the FieldGenius csv (very tedious) and hope that it will work and we will get a fixed/corrected pos and csv file out of emlid studio.
Yea….were you not doing RTK over LORA while collecting? Even when doing PPK, i’ll usually be running RTK over LORA if I am in range. As long as you were logging at both Base/Rover, you should be good to get a fix. Unless, of course, your baseline was too far or you were in a harsh GNSS environment at either/both the base/rover.
No we were running rtk. Had the base pretty close but at one point during the day the rover for about 5-10 seconds went through a series of fix/no fix beeps. Almost like it had lost fix while we were working but didn’t make any sort of sound indicating it wasn’t in fix, had lagged, and was catching up. Also never showed to be out of fix in FieldGenius. Not a lot of y’all trees or buildings in the area either which is weird. Had big wide open sky for the day except when shooting a few shots under canopies on fence lines and stuff. Didn’t think much of it at the time but I’m wondering if our collection is garbage. Was hoping we could just post process everything with the log files from the rover and base but when we run it in emlid studio stop and go it only corrects a portion of our coordinates. And on top of that one of the corrected positions is way out in left field from a known point (power pole).
RTK and PPK solutions doesn’t depend on each other. Even if the RTK link is intermittent, and you occasionally get FLOAT or SINGLE solutions, you’ll be able to calculate precise coordinates as a result of post-processing in Emlid Studio. PPK doesn’t require a link between base and rover, raw data logs are enough to get centimeter accuracy.
I agree with the @Zaz5400’s advice: you can manually input base coordinates from OPUS to achieve absolute accuracy instead of the relative one while using the RINEX header position.
If you work via NTRIP, it is likely related to the poor Internet connection at some locations. The rover can go to the FLOAT solution in such cases even if the sky view is clear.
If I don’t miss anything, you couldn’t post-process because the CSV file was rejected by Emlid Studio. Did you manage to import it finally if Emlid Studio corrected a portion of your coordinates?
I believe that we need your raw data logs and the CSV files to evaluate their quality and try to reproduce it. You can send them via PM since there can be a sensitive data or email us via email@example.com.
We did manage to process our log files and got a .pos file. However not all positions were corrected (45 out of 56). When checking the ones that did get corrected those positions dont show to be anywhere close to landmarks on google earth (such as a power pole we collected the position of). Perhaps there is a scale factor that does not import into Google earth well.
Were they not corrected as FIX solutions, or not corrected at all? If they weren’t corrected as FIX, there could be obstructed sky view that prevented from getting FIX. If they weren’t corrected at all, probably the observation time in CSV file and raw data log doesn’t match.
If you send us logs and CSV file, we’ll have a chance to examine them and to figure out what exactly happened. Feel free to do it via firstname.lastname@example.org.