Hi,
I’m slowly moving forward with understanding how it works.
New questions that crossed my mind, I’d really apreciate the help.
If I put in the coordinates of the base from let’s say phone gps (consumer grade accuracy), will that affect the accuracy of final solutions from the rover?
I don’t need the global accuracy, it can be shifted. I need good, rtk local accuracy, within the newly established coordinate system. Yes, with unknown global shift, which doesn’t matter for me. Does it matter for the results?
Perfect would be a possibility to set the base as 0,0,0 and work in local datum. Do you work on it?
How long does it take,more or less, to get RINEX data from the rtk station which is situated within 80 km. (static mode)?
Somewhere I saw 8 hours observations, which would be a bummer.
Second thing, both devices need to be connected to the internet network. but can it be a different network?
Two hotspots from two different phones? Is it be possible to post-process accurate solutions from the data gathered in that manner?
In short, No. Absolute accuracy will be only as good as your phone can do. Relative accuracy between base and rover can still be as good as the published accuracy (2cm).
If all you need is relative accuracy between base and rover, then your base coordinate does not need to be accurate. However, you should still make it as accurate as you can with the tools and information available to you.
For the on-screen display, the coordinates are in LLH (Longitude, Latitude, Height) only. For the log files, you have some options: LLH, XYZ, ENU, NMEA, ERB.
I’m taking a pass on this one.
Yes, but you have to do something extra to forward one of the ports to the open internet.
I’ve asked for the same thing where the base is 0,0,0 in x,y,z system no matter where you place it. currently running output through an arduino due converting to x,y,z then zeroing it out to accomplish the same thing. I work well away from internet in mountains and over snowpack 10-20ft above ground so trying to look up accurate base coords is futile when all I need is an invisible magic 3D tape measure covering a work area. Would be very nice to relieve the burden placed on the arduino in my system of the x,y,z conversion and let it just do its thing as a machine interface.
What are you running on the Arduino that can’t be run on Reach with something like this:
On your tablet or phone, set up a TCP server to listen on, say, port 7777: nc -l 192.168.2.15 <-- change 192.168.2.15 to Reach’s IP address
In reach’s root shell, run: nc 127.0.0.1 8888 | myconversionprogram.sh | nc 192.168.2.1 7777 <-- change 192.168.2.1 to your tablet/phone IP address
In ReachView’s rover config tab, under Solution 1 output -> tcpsvr port 8888
Now start the Reach and you should see a stream of coordinate output on your phone/tablet.
You might need to use the -k (keep listening) in conjunction with -l, in case the connection drops, but something like this should do the job for you I think.
I only use the reachapp for setup and has nothing to do with my application. The arduino is already in the system and interfaces with the hydrualic controls of the vehicle. Plus I’m not up to speed on messing around with scripts on the edison. The tablet interface I’m working on is just a display with simple option buttons/tabs…no navigation or implement tracking takes place on the tablet just calculates distance between 2 points as well as a point normal to a plane for display purposes. The architecture of the system is the Due is running a very simple cross track navigation program, Reach is connected via serial to the DUE as a sensor, Android is connected to DUE via wifi as a monitor with simple button options and the DUE analog/digital outputs interface with the machine. It’s a very simple system similar to a pixhawk or like flight controller.
what really is frustrating is that rtklib already outputs xyz coords but there is absolutely no documentation on parsing the output stream. sure you can view it in a serial monitor but noway to break it down to usable variables. parsing the existing xyz output would be ideal a eliminate duplicating calculations.
I am however considering switching from the nmea(using a variant of tinygps+ to parse) output to the ERB using this protocol https://files.emlid.com/ERB.pdf as it contains some more relevant info for my application.
But anyways back to subject. It would be great if Reachview allowed a localized 0,0,0 base setting requiring no base coord input and maybe a simple reset button in the reachapp…just go out in the field and turn it on. And it you move the base just hit the zero reset button
the ERB format does look like the way to go, although the RTKLIB solution output format (including for XYZ) is documented in appendix B.1 of the manual.
The output would be space-separated fields, with records separated by CR/LF:
Time1
Time2
X (these are components of ECEF frame in meters)
Y
Z
Q (quality)
ns (number of satellites)
sdn (these are standard deviations)
sde
sdu
sdne
sdeu
sdun
age (age of differential)
ratio (ratio factor)
From there, you could use awk '{print ($3,$4,$5)}' to extract the X, Y, Z
yes I looked into autocad360 at one point and zeroing in the app is easy…its the requirement of having to input actual reference coords in the reach base which is a hang up. It really needs a relative coord system mode as an option. It’s really useless to try and look up ref coords that could be under 10-20ft of snow
Another factor is when coverting the output stream from llh to xyz they are earth centered in cm with 0,0,0 at the earths core! That is a large number requiring double floats to be declared. It would be better to be using coords where the rover is measuring a few hundred meters at most from an origin in the work site and not the earths core. That large number can stay on the Reach/Edison and dont want it anywhere else
Great tip! but what about check sums and such? I do not know much about ripping apart these streams other than what I’ve learned from the tinygps library, ublox data sheets and the erb protocol. I’ve been searching for the similar protocol explanation for the xyz output and have come up blank…even with the guys from Emlid
Yeah, there’s no checksum in the RTKLIB output stream. I suppose the only validation you could do with the XYZ output stream is pass it through a regex filter that checks the right number of fields are present and the values in those fields are sane, then discards any records that don’t pass the test.
But if you need a checksum to validate against, then it looks like ERB is your protocol.
I’m sure this ‘feature’ of zeroing the rover at an arbitrary point, or having 0,0,0 at the base station will be available in ReachView someday. It just might not be in done time for this season’s snow park Maybe Emlid could have a staffer available who can work on software features for $$$ to get the ball rolling.
No prob. I had to look it up, but yes, the NMEA streams all have checksums at the end of the sentence, like *28 and I don’t know what you mean by ID, but there are different NMEA sentences being output, and the one with the X,Y,Z is named GPGGA or GPRMC, so that could be the ID you speak of. And hopefully the tinygps people coded in the checksum validation, I mean why wouldn’t they?
Maybe Emlid could have a staffer available who can work on software features for $$$ to get the ball rolling.