ReachRS solution std: xyz vs llh

[Johannes_Eberenz]

I’m looking at the std (+/-) below the position on the status page, and notice it is the same for soliton in LLH and xyz (ECEF)… while those should be quite different (H should typically have more error then lat long, while in XYZ ECEF it depends on your position on the ellipsoid …?)

Looking into the status msg from the reach (yes sniffing around a bit i the developer console), i only see xyz messages for std pos xyz float std (m) rover:0.223,0.208,0.301, while for position we also see llh…

am i correct to assume that always the ECEF xyz std is displayed, even if position is in LLH?

[bide]

Good catch!

I’m looking at version 2.10.0, and I see these lines in the code:
var coord_accuracy = (msg[‘solution status’] == ‘fix’) ? msg[‘pos xyz fixed std (m) rover’].split(’,’) : msg[‘pos xyz float std (m) rover’].split(’,’);

        $("#lat_accuracy").html(coord_accuracy[0]);
        $("#lon_accuracy").html(coord_accuracy[1]);
        $("#height_accuracy").html(coord_accuracy[2]);

So I believe you are correct that the values are always reported as XYZ, and there should be a test if in XYZ or LLH mode and some transformation matrix applied to get the values reconfigured for LLH mode.

[egor.fedorov]

@Johannes_Eberenz

am i correct to assume that always the ECEF xyz std is displayed, even if position is in LLH?

Well, the number is the same no matter what kind of coordinates you use. It shows the position accuracy relative to your coordinate. Why would it depend on how the coordinates are represented?

[Johannes_Eberenz]

Correct me if I’m wrong, but I think xyz is in ECEF, so the axis directions are not relativ to earth surface, but to earth center, so the numbers are similar, but the directions are not as suggested in the display.

This is relevant as typically vertical accuracy is worse than horizontal… but this is relative to earth surface, not center.

Overall not a big issue… just not correct

[egor.fedorov]

Ok, I checked it out once more. Turns out these numbers are different for solution output and for status, so you are right.

While calculating stds for solution output the coordinates are actually transformed from ECEF to local. For the status, they are not converted and you see ECEF variances. So, bug noted

[Johannes_Eberenz]

would be great, when you fix this, if you could also tackle the missing std values in single mode