@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.
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.
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
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.
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.
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.)
