ReachView 3 Beta

News
276

Thanks Alistair, those results look good.

1 Like
277

Getting some weird data it seems. I am using EPSG 8719. Set a base up over a known point and just did average single so I can compare the base launched coordinates to the published data point. Rover was set at 2m for the pole height. Surveys fine, but when I check the CSV generated, it says my antenna height is now 2.44m instead of 2m. I checked the points I shot and they now show as 8.004usft instead of the 6.5616usft (for 2m pole height). I will be checking these shots against other control/the plans tomorrow to see if subtracting out the difference gets me to the correct elevation. If so there may be a bug in the pole height not remaining set.

278

The absolute position of the rover is accurate only to the same accuracy as the position of the base station. So even if you use RTK to get a base position it doesn’t guarantee you accurate coordinates. See this article about placing the base for more information.

2 Likes
279

Hi, @dbuchanan

You are using CRS that includes vertical datum NAVD88 height (ftUS). It means that your points will have orthometric (geoidal) height instead of ellipsoidal one due to geoid height correction applying. I suppose that’s the reason of changing height of your points.

You can choose a CRS that has the same horizontal CRS that you have used, but has no vertical datum included - EPSG:2230(NAD83 / California zone 6 (ftUS)). Please, try to collect some points with this CRS and report to us if height is still incorrect.

Thank you!

1 Like
280

Okay, I will give that a try instead and report back. Thanks!

1 Like
281

One way to do it instead of waiting to PPP, is you setup your base on an unknown location, then if you happen to have two other benchmarks/control points around, you can shoot those and do a least squares fit with all your data to those two bm/cp’s. It works reasonably well for me (+/- 0.10’). Trimble Business Center has a powerful least squares tool that can accomplish that. It is similar to localization (which would be rad if Emlid eventually implements this).

1 Like
282

This is much like localization, but it can be done on the fly in the field. This would alleviate all my above questions as well, but I know we are getting there. :wink:

3 Likes
283

The Android app version 4.7 Beta has just released! This version brings some important updates related to coordinate systems and point collection. We look forward to receiving your feedback!

The full changelog:

  • Now devices with a firmware version lower than DEV 2.23.8 need to be updated to work with ReachView 3.

  • Due to technical issues, we had to remove multiple CRSs based on a non-EPSG geographic coordinate system.

    Removed systems 
    ESRI:53075(Sphere_Wagner_V)
ESRI:53077(Sphere_Natural_Earth)
ESRI:53078(Sphere_Natural_Earth_II)
ESRI:53079(Sphere_Patterson)
ESRI:53080(Sphere_Compact_Miller)
ESRI:102038(The_World_From_Space)
ESRI:102061(Everest_Modified_1969_RSO_Malaya_Meters)
ESRI:102096(Bab_South_Palau_Azimuthal_Equidistant)
ESRI:102163(Lisboa_Bessel_Bonne)
ESRI:102237(Pohnpei_Az_Eq_1971)
ESRI:102498(GOES-16_East_ABI_Fixed_Grid_ITRF2008)

  • Added new coordinate systems for Ghana :ghana: and Sierra Leone :sierra_leone: (ones which use Gold Coast Foot unit of measure).

    Added systems 
    EPSG:2136(Accra / Ghana National Grid)
EPSG:2159(Sierra Leone 1924 / New Colony Grid)
EPSG:2160(Sierra Leone 1924 / New War Office Grid)

    @richie1aubyn We would appreciate getting test results from you!

  • We now use a different way to calculate accuracy estimates. The RMS numbers you see will be slightly higher, but they will also be more realistic.

  • Added a new notification to NTRIP profiles manager in the Profile tab. If you create or edit an NTRIP profile, and any Reach is connected at that moment, the app will now ask you if you want to change settings on that Reach.

  • Fixed the correction input settings screen, which was failing to display current LoRa parameters.

  • Points of the project are now muted when the collector tool is active.

  • Various fixes and improvements.

4 Likes
284

So I was able to do a least squares adjustment and I come in within a hundredth of both GPS ties and I feel fairly confident with the values horizontally. Elevation wise I think I am okay, but the discrepancy between the following values of the rod height make me nervous/unsure. In the attached image you can see how the antenna height is different in each location. I tried with both NAVD88 (ortho height) and Ellipsoid height.

img1
img11080×2340 157 KB
img2
img21080×2340 315 KB
img3
img31080×2340 304 KB
img4
img4960×323 131 KB

285

Great @andrei.kuznetcov. I will do so. I’ll keep you all posted. Thank you

3 Likes
286

will you add the mexican geoid (GGM10) in the future?

287

New iOS app version 4.1 Beta is up for testing in TestFlight!
In this release we bring many updates to coordinate systems, project import, and point collection! We also have fixed some issues that you have reported since our first release, thank you very much for all the feedback!

Here’s what is new:

  • Now devices with a firmware version lower than DEV 2.23.8 need to be updated to work with ReachView 3.

  • Due to technical issues, we had to remove multiple CRSs based on a non-EPSG geographic coordinate system.

    Removed systems 
        ESRI:53075(Sphere_Wagner_V)
    ESRI:53077(Sphere_Natural_Earth)
    ESRI:53078(Sphere_Natural_Earth_II)
    ESRI:53079(Sphere_Patterson)
    ESRI:53080(Sphere_Compact_Miller)
    ESRI:102038(The_World_From_Space)
    ESRI:102061(Everest_Modified_1969_RSO_Malaya_Meters)
    ESRI:102096(Bab_South_Palau_Azimuthal_Equidistant)
    ESRI:102163(Lisboa_Bessel_Bonne)
    ESRI:102237(Pohnpei_Az_Eq_1971)
    ESRI:102498(GOES-16_East_ABI_Fixed_Grid_ITRF2008)

  • Added new coordinate systems for Ghana :ghana: and Sierra Leone :sierra_leone: (ones which use Gold Coast Foot unit of measure).

    Added systems 
          EPSG:2136(Accra / Ghana National Grid)
      EPSG:2159(Sierra Leone 1924 / New Colony Grid)
      EPSG:2160(Sierra Leone 1924 / New War Office Grid)

  • Added more detailed hints when entering values in the NTRIP profile wizard.

  • Interactions with projects now will be restricted in case if required grid/geoid files are corrupted or missing. In such a case, the app will ask you to download missing files.

  • Now all geoid and grids use .tif format instead of .gtx and .gsb. Previously created projects may ask to re-download grid/geoid files. Sorry for the inconvenience.

  • Update the EPSG systems list in accordance with the EPSG v9.8.9.

  • Add new vertical CRSs:

    • EPSG:5709(NAP height) :finland:
    • EPSG:3900(N2000 height) :finland:
    • EPSG:5717(N60 height) :netherlands:

  • Add new experimental vertical CRSs:

    • EPSG:5621(EVRF2007 height) (along with ‘gugik-geoid2011-PL-EVRF2007-NH’ geoid) :poland:
    • EPSG:5729(LHN95 height) (along with ‘CHGEO04A’ geoid) :switzerland:

  • Change default base CRS for all projected and compound CRSs based on geographic ‘CH1903+’ :switzerland: and ‘DHDN’ :de: to ‘ETRS89’.

  • We now use a different way to calculate accuracy estimates. The RMS numbers you see will be slightly higher, but they will also be more realistic.

  • The collector tool now reuses the description of the last collected point for a new one. You still will be able to clear it via the Edit dialog.

  • Project import was upgraded to support point metadata, like solution status and antenna height. Here’s a full list of supported headers: Easting RMS, Northing RMS, Elevation RMS, Lateral RMS, Antenna Height, Solution Status, Averaging Start, Averaging End, Samples.

  • Sometimes the device scanner was failing to detect receivers’ firmware version, which resulted in non-verbose error messages when trying to connect to a Reach. This issue has been fixed.

  • Fixed the correction input settings screen, which was failing to display current LoRa parameters.

  • Now, when the ‘follow rover’ mode is active, the rover will always be centered on the visible area of the map.

  • ‘Fit to project’ functionality was fixed, now your points will be centered on the map, without disappearing under point info screen.

  • Minor fixes and visual improvements.

We’re looking forward to hearing more feedback from you!

10 Likes
288

Hi @dbuchanan!

We’ll investigate this issue. Thank you for such a detailed report!

1 Like
289

@egor.fedorov Yes, looking forward to it. I have other use for API.

290

A post was split to a new topic: AR ratio on dev firmware

291

Hi @andrei.kuznetcov, I conducted a test yesterday. I decided to collect some points on the field yesterday for comparison. My subordinate collected the same points in WGS84 with reachview 2 whilst I collected it with reachview 3. Compared the coordinates of both after converting the wgs84 collected in reachview 2 to the “Ghana national grid”. Coordinates from reachview 3 were off by (approximately 1010ft in the northing values and 89ft in the easting values).

Then I went back to look inside the parameters within the ghana coordinate system and realized you omitted a 7 parameter Bursa Wolfe datum transformation parameters.
Thus, from wgs84 to Ghana Grid { X(m)=199; Y(m)=-32; Z(m)=-322; Rotation X(sec)= 0; Rotation Y(sec)=0; Rotation Z(sec)=0; scale (ppm)=0 }

Or vice versa, from Ghana Grid to WGS84 { X(m)=-199; Y(m)=32; Z(m)=322; Rotation X(sec)= 0; Rotation Y(sec)=0; Rotation Z(sec)=0; scale (ppm)=0 }
I’ve taken the courtesy of copying and pasting the details from the EPSG official web page and highlighted what I’m referring to in “bold” under this write up. Thank you for all the efforts. We’re almost there comrades… :blush::blush::blush:Anyway, Reachview 3 is superb

PROJCS[“Accra / Ghana National Grid”,
GEOGCS[“Accra”,
DATUM[“Accra”,
SPHEROID[“War Office”,6378300,296,
AUTHORITY[“EPSG”,“7029”]],
TOWGS84[-199,32,322,0,0,0,0],
AUTHORITY[“EPSG”,“6168”]],
PRIMEM[“Greenwich”,0,
AUTHORITY[“EPSG”,“8901”]],
UNIT[“degree”,0.0174532925199433,
AUTHORITY[“EPSG”,“9122”]],
AUTHORITY[“EPSG”,“4168”]],
PROJECTION[“Transverse_Mercator”],
PARAMETER[“latitude_of_origin”,4.666666666666667],
PARAMETER[“central_meridian”,-1],
PARAMETER[“scale_factor”,0.99975],
PARAMETER[“false_easting”,900000],
PARAMETER[“false_northing”,0],
UNIT[“Gold Coast foot”,0.3047997101815088,
AUTHORITY[“EPSG”,“9094”]],
AXIS[“Easting”,EAST],
AXIS[“Northing”,NORTH],
AUTHORITY[“EPSG”,“2136”]]

4 Likes
292

Hi, Richard

Thank you for testing!

Could you please tell as what is source of corrections that you used to get results in WGS84? It can be not obvious but ReachView2 gives you coordinates not in WGS84 but in the same CRS that your base configured in.
So if the source of your corrections were configured in your local CRS, as it is usually done for most of regions to nullify tectonic movements of the continent, there is no need to use datum transformation parameters from WGS84, only projection should be applied.

Also it would be helpful for us to know what NTRIP is commonly used in your region, if you have any links please share them to us.

2 Likes
293

Hi @andrei.marshalov
We normally don’t use NTRIP (Been it VRS or CORS) in my Nation for RTK purposes. We use CORS but only for post-processing purposes (rinex data of the CORS is readily available at the end of each day by the operational body).

With that said, I own 2x RS2s so I always use one as my base for rtk purposes. I normally just ‘average single’ my base when I don’t have a control near where I’m working in (which was the case yesterday). Average single usually gives me a base coordinate of about 1.5 metres to 2.5 metres within the actual coordinate of the base point I mount so I have no issue whatsoever.

Thank you!

3 Likes
294

A while ago I reported problems with crashnig RV3 app. Ever since I was working with Survey Master and NMEA output because I could not get RV3 to work.

I would like to downgrade/ re-install a non-dev firmware version because I have upcoming jobs where I need reliablity.
Which is the most reliable FW version for normal survey in RTK mode?

295

Hi Seth, thank you!

Definitely have something like this in our plans, nice guess.

2 Likes