I am glad to inform that I finally figured it out.

Congratulation! Do you change the output format or what is/was the solution?

Is it possible to convert XYZ sigmas to lat-long-ellipH ?

Yes, of course. You can use the propagation of uncertainty or a Monte-Carlo simulation.

Why are the colums labeled y x z in the tables but one is supposed to enter the values x y z ?

In geodesy, usually the east, north and height components are refereed to y, x and z, respectively. In contrast to a mathematical system where the angle of incline is defined counterclockwise, in geodesy, the angle (i.e. the azimuth) is defined clockwise. Since JAG3D is a geodetic adjustment tool, the column heads are labelled by y, x and z.

/Micha

Is it possible to convert XYZ sigmas to lat-long-ellipH ?

Why are the colums labeled y x z in the tables but one is supposed to enter the values x y z ?

I think what we need to do is convert the local ENU baseline to a ECEF baseline.

Due to the original baseline is referred to ECEF, you should disable the ENU conversion.

I don't see how a topographer would be able to directly produce a ECEF baseline

Each GNSS receiver provides the position in WGS84. Here an example output of my u-blox sensor

The coordinates are given in Lat / Lon / ell. Height and can be simple converted to WGS84 X/Y/Z coordinates. If you observed two points, the baseline is derived by the coordinate differences.

unless they have some commercial software that has this feature

No, that's not right, see the screenshot above.

There seems to be a missing link between JAG3D and RTKLib

No, see e.g. page 14 in the manual: X/Y/Z components in ECEF frame. RTKlib supports ECEF. Just use it.

regards
Micha

I think what we need to do is convert the local ENU baseline to a ECEF baseline.

https://gssc.esa.int/navipedia/index.php/Transformations_between_ECEF_and_ENU_coordinates

I don't see how a topographer would be able to directly produce a ECEF baseline unless they have some commercial software that has this feature and then they would just do the adjustment in the same software. Most open source users would like to enter the ENU baseline they get from RTKLib into JAG3D and have the software take care of the rest.

There seems to be a missing link between JAG3D and RTKLib, which could be fixed in either one and then we would have a complete post process and adjustment solution. Since I can't do this myself what I am trying to do is clarify the process and then see how we can create interest in programmers of either software to make the necessary changes.

Thanks

I still do not understand if the problem is mismatched concepts between software

Baselines are nothing else the coordinate differences in a specific but known frame, i.e., $\Delta X = X_2 - X_1$. GNSS is refereed to WGS84. So, if you don't use any settings, the raw data are refereed to WGS84. For that reason, RTKLib must support WGS84 out of the box. Your baselines are not refereed to WGS84. You have select some settings to convert the raw WGS84 coordinates to something else.

a software bug

No, because I have tested several examples like this. It works fine. The problem is, that your coordinates are not congruent to your baselines. JAG3D needs congruent data (refereed to the same frame or an congruent frame).

I can produce new data to other goverment CORS or to private poins using a pair of GNSS receptors.

Please provide WGS84 coordinates and baselines (or use at least the same convention for both, the coordinates and the baselines).

/Micha