I know this topic has been going on for a while, but I am not finding an answer to my question. Here is the scenario:
I set up on an arbitrary point on a very open area with a clear view of the sky for 360°. I live in the desert and not many trees around. I set up the Reach Base over this point an do an average single start up with logging at the base and a Rinex2.11 output using the ReachView3 app on my android phone. I the connect the Rover and go about my business of collecting data on property corners that I locate in the course of a day. At the end of my day, I return to the base and shut down both the base and the rover. I go home and download the base files to my laptop.
After retrieving the base Rinex2.11 file I send it to OPUS and in a short while I receive a post-processed coordinate via email. I enter the OPUS coordinate into my survey program along with the average single coordinate from my days work. I also download the CSV file containing the points that I located and tied that day. The difference between the average single base point and the OPUS point is generally around 4 feet. This seems to be the normal no natter where I work. Ellipsoid separation is usually around 25 feet and I am working in state plane zone for my area.
The next day, I go back to my project and set the Reach Base on same point as the day before and this time I enter the OPUS coordinate via manual input instead of average single. I then start up my rover and wait for a fix. It never comes. I watch the status and it is constantly going from “waiting” to “receiving”, but never a fix. I then shut down and restart with average single and I get a fix.
I know I have to enter base coordinates in WGS84, but also knowing that there is no appreciable difference between WGS84 and NAD83, I go ahead and enter Lat and Long in NAD83 from the OPUS data sheet. I also use the Ellipsoid Height rather than the Ortho Elevation. Is the difference in WGS84 and NAD83 enough to throw the base off? I have the project set for the state plane zone and geoid of the area I am working. What do I need to do to be able to use an OPUS derived coordinate?
Michael M. Ivey, RPLS
I am sure one of the Professional surveyors on this forum will chime in on this. I have never tried the using OPUS data so not much help here. I do like following threads like this to learn new things.
Hi Michael, I am lazy about converting Lat Long in OPUS to decimal in order that the RS2 will take it. I just switch over to the XYZ input for the base and use the XYZ from OPUS. I haven’t run into an issue in this way. If you are running NAD 83 state plane on the rover, you should enter the NAD 83 on the base too. I am sure you already are, but just in case make sure you are in meters on the base. I think if the elevation for 3.28 times higher than what is expected it may never want to send out corrections.
jdouglas, I thought about that after I had started this topic and I am very glad you have confirmed what I was thinking about. I haven’t had a chance to do it yet, but I will do as you suggest. I will post the result. Thank you.
You can select a NAD83 State Plane coordinate system in Survey mode on ROVER in ReachView3. But how do you select NAD83 State Plane coordinate system on the BASE to MATCH in ReachView3?
This issue has always been present and happens on other brands of GPS as well. If you start with an I am here point and continue with that then you are fine. If you enter a known coordinate that the system deems out of range then it will not initialize RTK. I assume you are creating a brand new project for entering the manual coord and bringing points back in that have been adjusted to that new coordinate?
chascoadmin, I have never had that problem with other systems. I am mainly familiar with Trimble up to the 3800. I have always been able to do an Rtk Infill go about my data collection, send the static file from the base to OPUS, translate the rtk points to the opus location and go on from there. I always do a check shot with the new OPUS point and if everything is good, then I am ready to go. I create a new project everyday, it helps me to keep things straight. I also create a new point file everyday consisting only of the points that were collected that day. I appreciate your comments Chascoadmin. I am going to try the idea of entering the ECEF coordinate for the base point right now. I will post the result.
Jdouglas, it is immaterial what coordinate system you select in the Reachview app. GPS works in WGS84 on both the base and the rover. The reachview takes the data it receives in WGS84 and calculates the NAD83 or whatever position at the rover. It is kind of like a total station that displays the data as angle, slope distance and vertical distance. The total station is not reading the Horizontal distance and vertical distance, it is calculating those parameters based on the slope distance and vertical/zenith angle. In other words the raw data from a total station is horizontal angle, slope distance and vertical/zenith angle. Any other information is calculated from those three factors.
Good luck and God Speed,
Michael M. Ivey, RPLS
That was what I thought as well. I made that note about entering in NAD83 because that it what Emlid says to do. I figured maybe they were doing something unusual in the background. But, I agree it shouldn’t be the case. I gotta believe they are working on a way to make the base coordinate situation easier. Hopefully they update sooner than later.
You can try to use coordinates in the XYZ format directly, as @jdouglas suggested above.
It would be great to check also if the latitude and longitude values are set accordingly to the OPUS. They can be swapped accidentally.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.