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… 
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
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
@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.
3 Likes
@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.
6 Likes
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.
2 Likes
Thanks for the request, we will add the ability to configure elevations.
2 Likes
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
Regards