Compared to Google Maps or something else?
What problem are you referring to ?
I have requested access to your raw-files, then I’ll give it a try.
Compared to Google Maps or something else?
What problem are you referring to ?
I have requested access to your raw-files, then I’ll give it a try.
Hi. The blue dots are to the left of there actual placement when compared in pix4d (3rd picture) during processing.
I have been trying for over a year to get consistent, reliable data from them. When i post on here people say they have processed it and it was ok but no one will tell me what iam doing wrong.
since the last update they seem to have got worse, also i have started to have a battery issue that support are looking into on my reach RS+
I have shared the file with you
So, it is primarily your base position you are struggling with? Let’s try and solve this one step at a time.
What are the coordinates of the CORS station you are using?
Is there a website I can look up details on it?
Yeah. If you look at the first image it shows the location on google maps. i put the Long and latt into google. The second image is from the composite image of the site taken on the day. Allowing for the roads that have been put in it does not seem to be right. Its 11 pm here so iam off to bed but will turn on the PC first thing in the morning.
Ok but what is it? Look like text from the .pos file.
It shows the precise and official position of the CORS station you are using.
What did you use for reference coordinate before?
Using EzSurv for post-processing, I get the following for your base:
Looking at various maps, and comparing the drone images to these, I think the positions are the same. Draw a few lines on top of the old treelines/hedges and you should come to the same conclusion.
On top of that, then I don’t why the GNSS data should lie about your base position. The data seems sound, RMS is good.
In regards to the rover data, I can only get a fixed solution for Point 1. I can’t see a good reason for this, however, point 1 processes to a position that matched the GCP marking above.
Processing your rover file against your base file using RTKpost, I get a 99% fixed solution. From there, you can open the pos file in RTKplot and use Edit -> Timespan to manually input start/stop times (remember to account for the timediff between UTC and GPST)
Morning pal. The problem is, if I’m honest is I don’t know where I’m going wrong.
I used the Blackpool airport CORS station (blap) from the CORS data from os.net. When i processed the logs i used emlid studio at the request from emlid support. This is the .pos file opened in RTKPlot and the location i got. (53.782600649 -2.772270354 in case the image isn’t clear) is not the same as yours.
What reference coordinate did you use for this processing?
I don’t have any reason to believe that the units are faulty, as I was able to get the correct positions.
I think your CORS reference coordinate is incorrect (compare to the link to ordnance survey I sent earlier), and thus all resulting coordinates are also incorrect, as all processing are derived from this coordinate.
Hi pal the reference position came from the .pos opened as text and its not far from yours but its here.
Yeah, that is practically the same coordinate for the CORS station.
What coordinate did you use for your own base, when you process up against your rover?
I used the coordinates from the above image
53.782600649 -2.772270354 79.9234
These are further away from yours but still not that great
That seems reasonable the same. Not too much of difference.
So, we have established that none of the base coordinates seem to be faulty.
So it must be at the step of calculating the rover kinematic solution. Can you try and process with RTKpost instead?
I will do. but to avoid any further confusion can you show me the setting you used. That way we know its not some i do during that and we both have the same settings.
Sure thing:
just processing so ill let you know.
Well first impressions of the new coordinates are that they seem a lot better. They all seem to be in the right area. There were only a few differences in the setting but they seem to have made a difference.
The Max pos VAR for AR i had set to 0.3000
Frequencies i had set to L1
Filter type was set the forward.
Iono/ tropo corrections and Sat Ephemeris were all different.
A friend is processing it in Pix4d so ill get the results this afternoon
Sounds good ! My settings shouldn’t be too far off defaults, as I remember them!
Well it made all the difference, that a some degree of user error. The last CSV File processed a 22mm in Pix4d Thank you for your help. I will try it out again in a different location and with more GCP’s THANK YOU FOR YOUR HELP.