ReachView v2.21.2

Hello, there is already a solution to the problem of transmitting the corrections of the base through ntrip.
I had been working just for lora and today I tried ntrip, the configuration for the rover works perfect, but the configuration for the base does not work.

As per my post above there is a bug in 2.21.0 with NTRIP server functionality in base mode. Emlid are aware and will patch in a future release.

Hello, guys!

We just pushed v2.21.1. You can see the updated changelog in the first message of the thread.

Best regards,
Emlid Team

3 Likes

@george.staroselskiy
Where is this or what does it show? The status page is unchanged from the previous version 2.20.0

I also noticed on RS+ the AR stays at 0.0 while status is fixed…
rs .pdf (250.2 KB)

5 Likes

Is this a stable release or another dev release?

Even numbers are stable, odd are dev :partying_face:
E.g 2.21.1 is dev

copy did not know that, thanks for clarifying.

The only way i can remember this is by thinking.
It always happens “odd” things with dev updates

3 Likes

I have a couple questions regarding the difference between the RS+ and the RS2 point outputs.
We used the RS+ last year for our research and the output CSV included RMS for X, Y, and Z. Shown below in the picture


Now when you export from the RS2 the output looks like this with only a lateral RMS instead of being broken down into X, Y, and Z. Please see photo below.

The reason I ask is when doing photogrammetry in agisoft metashape you have the option of importing GCP points and their relative accuracy, see photo below.

Where has this accuracy assessment gone in the new RS2 export of data, does the lateral_rms equate to x and y? Why is there no more vertical rms?

This is should not be used for accuracy input in Metashape in my mind. Input 2-3 cm here instead, which is the usual uncertainty of GNSS.

What is the accuracy relative to? A localization?

I would take 9 and 13 out of the equation. Or use your survey software to fix the elevations.

As I understand it the accuracy wold be based on where the actual point is at in real life (the reach unit) vs. where the gps solution thinks it should be. I am by no mean a surveyor and do not by any means think of myself as a surveyor. I might also be totally off, hence seeking some clarification about why that assessment was taken out. I have read through this thread a few times, and again could be very very off on the way I think.

Do please share more, are you saying when you import GCP’s you simply set the accuracy to 2 or 3 cm, can you share any information about why that is not a good accuracy assessment in metashape? Do you set your marker accuracy within this screen accuracy and just leave all accuracy on the gcp import page blank?

to me it looks like what we would call a gc3 or localization report. It basically shows the rmse error of the particular control point in relation to the rest as a network. I think the reference settings are how the algorithm will put weight on each control point thus filtering them on how or if they are used in the processing.

Do note that in pic 3 the lat/long were converted into UTM for a processing script that only uses UTM’s. The original exports from reaches are the two excel spread sheets. The collection workflow goes as follows. Setup base on a known survey point usually property mark (if known survey point is close enough, if not setup base and average 30 min of single points for a local base) , leave base running for at least 30 min before collecting data on the rover. Most of the time in the forested areas we are working we don’t have a fix and have to rely on a float, also sometimes the field crew gets in a bit of a hurry and doesn’t let it collect as many float points as we’d like to but given that this was previously done using folks cellphone gps its leaps and bounds better. We although still do have some short comings in our process and also our sFm processing streams but hopefully we can nail down a good workflow, its not terrible as it stands, and we are not really processing the same types of data as others are. A lot of what we do has to be a sort of rapid response while working in wildfire environments, so we often lack any lead time to plan accordingly. I will say that trying to reproduce heavy canopy environments using sFm is quite a challenge. We did a project for our county disaster emergency services on some flooding we had a cpl years ago and creating sFm in urban environments that have a great deal of structure and geometry to tie to is so much easier and actually fun, forests on the other hand are miserable or shall I say challenging!

Sorry took this off topic from original posters intent, my apology.

Any news on this?

Hi David,

I also noticed on RS+ the AR stays at 0.0 while status is fixed…

We will fix this bug in one of the future releases. Thanks for letting us know.

Where is this or what does it show? The status page is unchanged from the previous version 2.20.0

Accuracy is displayed under the Position in the ‘Status’ tab. This value for RS2 was not displayed correctly in the previous version.

2 Likes

Upgraded my unit to dev build v2.21.1 as requested in another topic.
Now I can’t SSH to the unit. Getting “access denied” for root/emlidreach .
Does the dev build have a different password? What has changed?
Can somebody confirm SSH access is not longer working?

Try as user emlid