Hi guys,
We are having another issue and was hoping you could weigh in. Im having a hard time getting a fix on our points on this one.
Minimum 1 minute point time and the base is no more than 13km away.
I have added a few base stations in there and an additional rover rinex file that is for an earlier point in the day.
Download link is here: WeTransfer - Send Large Files & Share Photos Online - Up to 2GB Free
Hope you guys can help,
Thankyou
Hi @uavis,
I checked the data you sent us, and it seems the receivers are experiencing some interference (electronic or field obstacles).
The rover’s data shows several broken cycles slips, which means there is some interference between the receiver’s communication with the satellites, causing it to not achieve a fix solution.
It’s hard to give a specific reason, but it could be caused by the environmental conditions of the area you’re surveying or some electronic device nearby that is interfering with the signal.
Below is the data information for the satellite visibility tab and the sky plot. You can see that the signal frequency has many gaps and interruptions. This guide explains how the data on Emlid Studio works.
Hi @oless.
We were walking around site and at points having the rover in the car until the next location.
Would this account for the broken cycles?
If so, does that mean our observation times were too short to PPK the data through the Stop and Go option on Emlid Studio.
Or do you think that there is some other type of interference going on that cause the additional broken cycles?
Regards
I would suggest a closer base if possible (on site) where you baselines are short. It’ll help in PP your data as short baselines will converge quicker with a fix solution.
https://www.javad.com/jgnss/javad/news/pr20151113.html
I always have a base on site of our boundary/flight projects. Even if you’re using RTK/RTN. If for any reason you loose RTK/RTN, you can still PP your points. Especially if a point has a questionable position. It will save you time and $$.
I’d also increase logging time to a minimum of 3 minutes. for each GCP. If you’re PP using the targets as control, it’s imperative to have good accuracy for both the horizontal/vertical components. This is where all your final data will start.
Also make sure your base is logging at the same interval rate as the UAV. If not, you won’t get good results.
From only looking at the .csv.
The substation doesn’t appear to be the problem. You actually got a fix directly adjacent to it in the direction of the base.
After point 8, they are all SINGLE. Looks like you got disconnected from the base.
Yes. We disconnected from base after Point 8.
We then turned on logging and collected points while logging. We logged a gcp for 1 minute each time.
It’s the ppk processing that is coming back strange. Only 19 of 33 points being processed.
I’m guessing it’s the time spent logging each gcp is not long enough
Hi Victor,
We ended up going back and re measuring all the GCP’s at a longer observation and for the most part they have all come back great.
I am trying to get the Local East and Northing though once i complete the Stop and Go Process and am struggling on how to do this. Can you point me in the right direction
For the broken cycles, it’s difficult to pinpoint an exact cause, but as @timd1971 mentioned, the environment you’re working in could have an impact on your data collection. For instance, an electrical solar power plant might generate electromagnetic interference that could affect GNSS receivers.
Regarding the Local Easting and Northing coordinates, we recommend creating a new project in Emlid Flow 360 and importing your collected data. This will allow you to switch from a global coordinate system to a local one. We also have a Support Tip on our Community Forum that explains this process in more detail.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.
