Hi Olesia,
I am having a similar issue on another project.
Base station is a VRS that is directly in the project area.
Are you able to have a look for me?
@UAVIS , I saw Woolooga and it had me curious.
I had a crack at it and to be honest, I definitely don’t have an answer for you. Reading the Base Headers you supplied, 316 & 317 are using different locations (one is Kilkivan and the other is Gympie).
In any case, I figured I’d just pull the data straight from Gympie (GYMP) being the closest for your time period and the best I could get was Float across all of the points (see attached). (Note, your Rover was logging at 1s, CORS like GYMP for archival are at 30s)
Woolooga - GYMP Results.zip (4.1 KB)
I then went back and matched the time periods for your observations against the VRS and had 14 points that would not get Fix or Float. I’ve put “No Match” in one of the columns, this is likely because the time periods didn’t overlap.
Woolooga - VRS Results.zip (3.1 KB)
Knowing the area, being pretty much clear and a short baseline (about 25k’s to Gympie, I don’t know really what this means. Perhaps knowing a bit more about how you did your observations might help? I see each point was averaged over 10 minutes, so there should have been a lot more fixes than floats.
Would be interesting to find the answer to this.
Joel
Hi Jake,
I decided to post-process 3 files seperatly to check if different settings can be applied. The forth file deson’t have enough logs to post process. I was able to fix: 1) 22 points 2) 8 points 3) 9 points. So, in total 39 points out of 66. Here’s my results.
Result.zip (6.2 KB)
I used Combined Filter type and turned off GLONASS and BDS in integer ambiguity resolution. I also had elevation mask at 15 for the first file.
What are the environmental conditions in your survey area? Are there any structures, electronics, or wires that could potentially interfere with the signal? Usually this is the reason for an issue with a fix.
1 Like
Hi,
Thanks. Its strange as I have just had another site with the same issue.
Conditions are as follows:
Clear Open Sky above both base and rover.
Base run for 3.5 hours for AUSPOS processing.
When using Stop and Go we are getting a few points again that can only receive a float status and are outside of our accuracy tolerance.
Rover is collecting data for 2 minutes on the point.
Do we need to be collecting a longer sample time?
I will check with the guys in the field but from what I believe the there isnt any interference. There are powerlines on site but i dont believe they are in the area of those points.
I will check again
@UAVIS , processing the data, I was able to get a fix on all 7 points with what appears to be a better RMS as well.
CHILDERS_corrected.zip (792 Bytes)
In this case, this is what I used in Studio.
I think when you are looking at your results, you’d find the majority of the Floats and Singles are due to the device probably being slung over the shoulder. It just counts when you are on your marks. Perhaps there just needs to be a good minute (while you are positioning the device and getting plumb) before starting your point collection? I should think 2 minutes is long enough with good conditions.
Hope this helps.
Joel
I also got the same 100% as @joelbladen in the Emlid Studio. If it’s possible to get the 100% fix with the test log, it doesn’t look like an issue with the receiver or the environment but with the workflow or setup. I’d also double-check how the points were collected during the first survey.
Thanks mate.
Yeah when I processed it I got 5 but had two points still throwing considerable errors
Is there any reason why you remove the SBAS or any specific circumstance that would cause you to need to remove them?
@UAVIS , Don’t take this as truth, but it is my reasoning/logic for you.
My understanding is SBAS somehow provides correction data with the GPS Signal to improve positioning in regions that allow for it. It appears that the AUS/NZ has recently implemented it and I believe it is more for accuracy with typical GPS devices (Phones, etc). To me, it seems safe to ignore it when using kinematics, but I do not know how this differs in the results through Studio, or if Reach uses it as part of its RTK solution.
Within reason, sometimes, it can just be trial and error. I ran this with various settings and got a different set of results each time. As long as you get what you need in the end, you just know next time will be different.
Joel
Ok, cool thanks so much for your help.
It does seem that in the past few months we have had more of these issues so its interesting to note about the changes with the SBAS.
Thanks again mate.
Regards,
Jake