@tb_rtk I second the “custom” GEOID model. This will be a necessity for any surveyor to have. Typically we create a custom .bin file that is a portion of the entire model for use in the field, to help with live processing. Right now, with the REACH, we apply the GEOID offset after post-processing.
It appears that you can select a custom GEOID in RTKLIB under “OPTIONS -> FILE -> Geoid Data File”. I haven’t tested it yet, but I’m guessing we could place a .bin file on the REACH and have it use that instead of the other options?
@igor.vereninov Do you know if this is something that will implemented with the ReachRS?
We will look into implementing custom geoids in ReachView, thank you for the hint!
Important note, the software will be the same for Reach and Reach RS except for availability of hardware-defined features (like LoRa and battery). Apart from that, both receivers will be getting updates simultaneously. Including the planned point collection module.
Thank you for the suggestion and please keep them coming, we are are constantly monitoring this thread
@igor.vereninov I’m sure your programmers will find it, but it appears to already be in the RTKLIB code. It just needs implemented… “file-geoidfile” and "geoid.c"
Create a simple way, through the web interface, to upload a custom file. Have RTKLIB read the uploaded file to have accurate Orthometric Heights.
The .bin files to download for the U.S. are here: https://www.ngs.noaa.gov/GEOID/GEOID12B/GEOID12B_data.shtml
I agree, it should be a fairly easy integration. Some Android apps even allow for custom ASCII geoids. The problem isn’t really a massive issue for small areas, but when you working over long distances, it can really make a big difference. I usually work exclusively in Ellipsoidal heights until the very end, and then I add them to the geoid model made as a grid and extract ortho values. Its a swine, but its accurate.
Then again, for working RTK wise with the new Reach RS and less post processing, its going to be an essential part of the workflow.
@igor.vereninov Sorry to keep bothering you
I have had my head down lately churning out some large projects… Finally coming up for some air and the ReachRS update made me read the forums more closely
Do you have any details on the “Surveying Tool” that you’re developing?
There are some very good suggestions on here regarding fixed, float, accuracy, etc. that might all be handled in your surveying tool. Just curious what all will be included in the Surveying Tool “app” so I don’t give suggestions for work already in progress?
It may already be included, but sampling the output GPS stream (NMEA?) with the last dozen or so observations and comparing them to give an approximate “live” positional accuracy would be useful along with the fixed/float state.
@cczeets No bother at all, we are happy to have you back
We are working on Stop&Go with ability to name points, add comments and export them. I think that we have a solid understanding now about the core requirements for this and hope to roll out a simple version soon. After that we can move on to more complicated features and workflows.
I’m using the Reach on a Pixhawk. It looks like the Reach uses WGS84 based elevations and the standard GPS uses MSL (EGM96 or approximation) based elevation. They can differ by up to 107m. I’ve wondered what would happen if the Reach was used as a backup GPS and the first one failed. Would the Arducopter software think that the copter’s altitude changed by 10s of meters or would it know what the baseline altitude was for the secondary GPS.
Anyway, it’d be nice if the Reach’s altitude could be configured to be MSL.
Thanks for the request, we will add the ability to configure elevations.
Hi @igor.vereninov, talk about export file, I have a request If you do not mind, that is export to dxf, and dxf file can be import again to ReachView, it is used for stacking out.
And the coordinate adjust to other system, such as in my country use TM-3, that adopted from UTM. thank you
Add GUI support to configure a moving base scenario
Add ability to configure and display all status information via MAVLINK messages so that WiFi isn’t required.
Document a REST (or whatever make sense) API that can be used to programatically configure the REACH and monitor the detailed status information to support 3rd party GUIs.
A message that notifies about GPS glitches etc… So that problems with the base/rover can be noticed in field.
Publish each release as an image and don’t force the user to update before the user interface can be used. I want to be able to use a given version without being required to update to minimize risk.
Just wanted to mention that this issue has been fixed and Reach will report both WGS84 and MSL heights in ERB protocol as ArduPilot expects it. The fix will be rolled out with one of the next updates.
@igor.vereninov I noticed that 2.2.4 was just released. It doesn’t look like the altitude datum wasn’t updated in 2.2.4. Are you publishing a list of changes for each minor release? It’d be nice to know what changed for testing purposes.
Not included in this update, changes are here: ReachView beta v2.2.5
It’d be nice to just have a CHANGES file or page that listed each version and the changes. I’d also love to see firmware images available for each version to allow updates without WiFi and to install a specific tested version.
We’ve had some difficulties with the Edison’s Ethernet over USB driver. Does the Reach support a straight serial connection over USB to obtain the UBLOX or RTCM3 correction messages from the base? (A direct RJ45 Ethernet connection would be nice in the future.)