ReachView 2 beta Suggestions/features request

Hi @emlid, I post a request about switching kinematic and static method here Static option - #3

Maybe could be added a method in ReachView an algorithm for switching between static and kinematic, the default method is kinematic, then when stop in a point we can choose what method for calculating the point, kinematic for default or static for other option. This need a button for collecting point with static method, we push ‘start’ button then static method working, then start button name change to ‘stop’ button. If we don’t push the button, kinematic (default) will work.

So the conclusion is we move with kinematic, when stop in a point, collecting point with kinematic(default) and static (with button).

1 Like

You’re talking about “stop & go” mode :slight_smile:
We’re working on surveying tool in ReachView now as @egor.fedorov said in his post and that mode will be a part of it.

2 Likes

That’s great… Awesome!!

Another map request. I zoomed out on the status page map and realized the base station is displayed. This is a nice feature. Make it more evident with “Zoom to base” or “Zoom to baseline”.

1 Like

Hmm… one more, yesterday I did single observation for post processing, here the result I'm going to measure for post processing - #2 by dicky
I have a difficulty in namming the observation point. Can the log file name be changed? Thank you

Hi,
If I may suggest something for ReachView application. Could you add function for rename log file, such as when I observe single method for post processing data, and the data are many, I couldn’t remember about the point description. I think it could be simple application if we can add description or caption about the observation object.
Best regards

Really liking the new app interface with these new updates!

One request however…in xyz mode can we get the option for the coords to display relative to the base rather than the Earth’s center? Should be an easy addition to the view app!

Thanks!

Sorry, out of topic, but I think this is important.

When I got fix then walk under obstacles got float (that’s reasonable), but when got full sky view, hard for me to get fix again eventhough with more than 6 green bar.

Such as my report here

Any body could give me an explanation clearly.

Maybe tomorrow I will report with a video.

Thank you

Hi, yesterday I got coughs and colds, I couldn’t observed.

One thing I think emlid should have is a caster for reach user. The user could subscribe license a year.

Thank you

This is about height from ellipsoid.
Is it possible to feed Reach with an option, like correction data, so it will output correct orthometric height in reachview?
A option to load a file like href2016b.bin in reachview and it will display live height data at correct orthometric value.
I use this for postprocessing when i want exact height, i ad href2016b nn2000 file from here ftp://ftp.geodesi.no/
to option/position at rtkPOST

href2016b nn2000 is the difference between Ellipsoid and Geoide. this system is the same in Norway, Sweden and Finland

1 Like

I have had the same problem for a long time now. I would be grateful if someone would enlighten me as how to add a custom geoid model to RTKLib to get proper orthometric values. I find that the internal model is way to coarse.

Sorry, I am a bit ignorant here, but is there a geoid model in the uBlox chip as well as RTKLIB?

I guess what I mean is: Does the single position come straight from the uBlox chip or is RTKLIB processing it as well?

I think you are right. How else would it calculate ortho heights?

Just read your ReachRS update! You guys are crazy! That is awesome. That is what I would call disruptive technology. Molodtsy. Unfortunately, that is currently above my price range… No complaints… though. Is that the same reach inside and with the same reachview app as previously?
I have given serious thought to what I would like to see in a survey app…Not sure what all to ask for… :slight_smile:
I guess my biggest requests have already been covered. Saving points with a description and the ability to import points would be nice options. Then lines would be the next feature I would consider important. If I could do those things I would consider reach to fill practically all my requirements. Of course I can do it with Bluetooth etc. but it would be so much nicer to do it within the app? Is this still in the plans or has ReachRS replaced this somehow?I have also considered the background map… I have no idea what it involves but would it be possible to have mapbox available? Then we could use our own custom aerial maps through mapbox. That would be cool.Just some thoughts… and keep up the great work!

1 Like

@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?

1 Like

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 :slight_smile:

2 Likes

@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: GEOID12B Data Download

1 Like

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.

1 Like