ReachView v2.16.1 - Point stakeout

(Egor Fedorov) #1

Hello everyone!

We’ve just pushed ReachView v2.16.0 to all of our receivers! This huge update introduces one of the most awaited surveying features to our app - point stakeout. Apart from that, Reach RS+ gets the option to boot on power automatically and Reach M+ receivers now officially support LoRa radios. The plug and play accessory is already available in our store :sunglasses:.

Like all of our recent releases, this one is based on a series of updates distributed through the dev channel. I will go through most of the changes here, but more detailed information can be found in the original thread for v2.15.x updates. We’ve had an amazing response from you guys and really appreciate the feedback and the support. Thank you!


  • Point stakeout. Any point you have in your project now has the stakeout button active. Keep in mind that the accuracy threshold is frozen at 2.5 cm, but the distance is always reported in real time. I’ll let the screenshots do the rest of explaining:

  • Smart antenna/pole height. You don’t need to think about the actual antenna height anymore. Just enter the pole height and choose whether you use the thread adapter.

  • Geodata import in CSV, GeoJSON, DXF. Import projects for staking them out with Reach. You can either upload the file the normal way or paste the data as text, which is really convenient to do from a phone. Note that geometry support is limited to points.


  • LoRa support for Reach M+. The correction input and base corrections tabs now have LoRa as an option. It will be blocked until you actually plug one in. However, you don’t need to worry about turning LoRa off in the configuration before disconnecting it. The system will handle this just fine.

  • Automatic boot using the bottom connector on Reach RS+. One of the major new hardware features for Reach RS+ was support for this. Perfect for integrating the receiver with cars or tractors. Also, the settings tab now offers a special dialog to configure whether you want it to actually happen.


  • Bluetooth connection unstable for some Android and Windows devices
  • Onboard RINEX logs had some observations missing(compared to manually converted raw logs)
  • Default trail length reduced on the status tab to avoid performance issues
  • Prevent user from opening the projects twice

Thanks to everyone who helped with the testing and participated in the dev updates! Another round of dev updates is right around the corner, so stay tuned :slight_smile:

Best regards,
Emlid team

Update 15.10.18

v2.16.1 has just been pushed with some major platform stability improvements. This update is recommended for all Reach users.

Reach RS+ Connection to Mobile Wifi Hotspots
REACH M+: Inconsistent position rate <5hz with GPS+GLONASS (other disabled)
Missing events in pos file
(Dmitriy Ershov) #2

(Timd1971) #3

wow. WOW!!! ; )

(David Hofer) #4

This just keeps getting better

(Michael Lambert) #5

This is amazing! Kudos Team Emlid.


9 devices updated to 2.16.0 today

-from versions: 2.11.0, 2.11.4, 2.14.0, 2.15.2, 2.15.3
-types: Reach, Reach RS, Reach M+, Reach RS+

Only one failed to bring up 2.16.0 after the update. It fell back to the previous version as it is supposed to. Then I just restarted the update and it was successful after that :+1:

So that is a thorough test of the update process and all is working well :slight_smile:

(Egor Fedorov) #7

Thanks for the report!

The new update system on M+ and RS+ does wonders, really.

(l3technologycambodia) #8

A big congratulation to the Emlid team for your hard work of the new release. Can’t wait to see next update for UTM coordinates support, area calculation for polygons and length calculation for lines.

(Christian Grüner) #9

Updated my 2 RS+ units yesterday. Both of them returned to the update screen after the new firmware was installed, and prompted for a reboot.
It returned because of the port 5000 as I see it. And then you’re stuck in an infinite loop, until you manually remove the :5000 from the URL.

Other than that, updated in the first go, and will get some milage tomorrow.

(Christian Grüner) #10

A few findings today after placing a number of GCPs:

My first point collection failed silently. All looked good, but coordinates was 0 for all 3 values. No idea what happened. Must have been a glitch, cause all other were collected successfully.

Rotation bug is still a thing, and now the survey map is also stretched after rotation.

I had also problems with connecting to networks, that the RS+ can’t see yet. I usually start the unit as one of the first things I do when I arrive on location, and let the the RS+ make its own hotspot.
When I am then ready to start setting up my base (via an NTRIP connection), I connect to the hotspot, and ask it connect to my phone Wifi (which at that point is not on, as I can’t turn on hotspot on my phone without disconnecting the RS+ connection). While the RS+ in then searching, I then start-up my phone hotspot. This was possible previously.

(Ryszard Pażus (GeoDigitalGNSS)) #11

It is difficult to agree with you.
This is not a professional solution to the topic.
This is a mistaken approach to solving the task.
The error is here at the beginning. EPSG 4326 (European Petroleum Survey Group) is not a cartographic projection. It’s the WGS84. This method results in a square-shaped map (which computers really want) but there is no way to programmatically represent a coordinate system. Maybe it is enough for GIS, but it is not enough for surveyi with accuracy 2.5cm (staking out points, searching).
It must be resolved by conversion between Terrestrial Reference Frames as the first step. The next stage is a planar map projection (Coordinate Systems, eg UTM) and geoid modeling.
Revise it, please.

(Mazuba10) #12

All you need now are UTM coordinate systems with accompanying datums (I’m in Zambia and would love to use UTM coordinates with the arc1950 datum) and then we’ll really be in business.


Just to balance some of the comments, I wanted to say that point collection used to sit at #1 on my list, and of course, map display and especially stakeout go along with it as a package. So I am feeling very satisfied with the state of ReachView right now.

In-app CRS transforms are on my wishlist too, but they take a second seat. That might not be the majority opinion, but it is one :slight_smile:

(Timd1971) #14

The NEW STAKE OUT feature is AWESOME! :heart_eyes:


While in this STAKE OUT MODE, please let us use the zooming etc buttons by bringing them back in from collect point, but also stake out point. i.e. the +, -, all, and the target icons along the right side of the app when collecting points. maybe a TOGGLE between auto-follow and let us maneuver?
Some of us have MANY points and would like to be able to zoom out for a frame of reference of the entire staking project or areas of it while working or we may end up walking into a crocodile pit.

I know this is all great work in progress, so just a suggestion. DXF import of points. Maybe possibility of all LINES, ARCS, CURVES, SPLINES, POINTS, etc via DXF also in the near future? maybe a on/off toggle LAYER feature where we can load DXF objects file, or other point / object format files, and also a bitmap image file import that can be scaled and rotated correctly, (I.e. RTS Rotate, Transform, Scale) along with transparency overlay adjustability? I guess this would be handy for using your own drone imaging or image file export overlays.

Also, please look at Ryszard’s post above to make sure all is good. He is VERY knowledgeable. Ultimately we’ll need widely used Coordinate System implementation to choose from for true surveying use. i.e. NAD83, USA State Plane Zones, etc. It’s a complex subject, but necessary and Ryszard is heading this problem off early in the process.

Thank you for implementing STAKE OUT, this is HUGE!

(Timd1971) #15

Yes, I have this problem also. Have to drop out of SURVEY mode and select another ReachView feature and bounce back to Survey. Guess you could turn off auto-rotate on the phone until fixed.

(Christian Grüner) #16

Yep, so I do, but it’s annoying each first time :smiley:

(Timd1971) #17


Give whomever involved with the new STAKE OUT work, a RAISE!!! :grin:

(Timd1971) #18

Pole height is confusing and prone for error.

if 2m pole and “I use thread adapter” checked, it accommodates for this resulting in TOTAL antenna height (with adapter) is 2.0865 m. great.

but this same number isn’t shown when COLLECTING POINT…it states 2 m only, not 2.0865 m or even 2.065 m WITHOUT thread adapter? maybe occurring in background? EDIT: at least can check in point list. maybe add the pole height & and if use adapter etc feature here in the point collection screen instead?

Maybe also where is let’s you check: “I use thread adapter”, maybe specify as “I use EMLID provided 0.0215 m tall thread adapter” in case one is using a different brand / height of of adapter etc?

I think this has been mentioned, I’ll have to search again.

(Tatiana Andreeva) #19

A post was split to a new topic: How to improve the accuracy for revisiting the same point with stakeout

(Erro Alfaro88) #20

Hi Emlid team.

I have two reach rs. V2.16

Today was the first time I used the stakeout function in reachview. I do not know if I did it correctly but I was a bit disappointed.
Having to be pointing the cell phone to the north all the time to know in which direction the point is is very annoying.

With mobile Topographer pro you have the benefit of an arrow indicating in which direction the set point is without having to be orienting the cell phone.

Another note is that at no time when moving the antenna rover symbol ® changed to an arrow shape, it always remained in a circular shape. At all times I had a fix.