Error - Singular measurement covariance

[Mauro V. Bueno Jr.]

Hello guys,

I'm trying to ajdust a net on salsa, but it is showing me this error message.

Do you know what could it be?

Thanks in advance.

Mauro.

[Clark Hughes]

Hi Mauro,

The issue is with the covariance matrices. The error message (and the yellow warning triangles and tool-tips) indicate these matrices are non-physical. The one that's visible in the record editor looks made up; where did these values come from?  Your GNSS processing software should be returning the vector and its covariance, so maybe you've made an error in transcription? If you want to just get rid of the errors and get SASLSA to process, set all the off-diagonal covariance values (xy, xz, yz) to zero; the triangles should go away, and the project should solve. Let us know how it goes.

Clark

[Mauro V. Bueno Jr.]

Hi Clark,

I made the processing on Emlid Studio and it generated these values:

But, as you suggested, I set the covariance values (xy, xz, yz) to zero and the project has been solved:

Thanks for your advice.

Mauro.

[Clark Hughes]

Hi Mauro,

Thanks for the update; I'm glad that worked. It looks like the printed values from Emlid Studio may be precision-limited (and surprisingly small). At any rate, I'm glad to know that worked. Thanks again,

Clark

[Jose Ernesto Muñoz N.]

Hello colleagues
I am from Chile, and I am in a field of topography adjustments. SALSA is undoubtedly a software that can be useful in my profession, but the manual is unclear, although I have it translated,
Question: As I start a first analysis job with the software, I have a file in CSV format, with GNNS data in UTM.

[Clark Hughes]

Hi,

Can you expand on your question? It sounds like maybe you're trying to understand how to get your GNSS vectors into a format SALSA can read? If that's the case, take a look at the LSA file specification (Chapter 13 in the version 1.15 user manual) to see how that's structured. Maybe post the file or a portion of it?

Clark

[Jose Ernesto Muñoz N.]

Hola Clarck

gracias por la ayuda,  he leido el capitulo 13 que recomendaste, pero aun no comprendo mucho. Tengo la lista AQUI y lo que quiero  es: Aprender a usar salsa en su totalidad, analizando mis puntos, de un levantamiento con GNSS. Clark ..!Quiero aprender a usar SALSA para mi trabajo diario como topógrafo, dado que estoy en un curso de Geodesia.

Muchas gracias.. 

Ernesto

[Clark Hughes]

Hi Ernesto,

I'm not sure how to interpret that csv file. Can you describe what each column is, and the units?

Clark

[Jose Ernesto Muñoz N.]

 A : es un correlativo de numero de puntos tomados en terreno

B: coordenadas UTM  este

C: coordenadas UTM Norte

d: Cota

E: descriptor ( si es el punto de una casa, camino, cerco etc...)

Gracias

[Clark Hughes]

Ernesto,

Ok, so you have a list of station coordinates; what do you want to do with them? For SALSA to execute an adjustment, it needs measurements. I see that you have redundant coordinate sets for each of your stations; perhaps you want to combine them in some way? I don't see any uncertainty information; you'll need that in order to do a geodetic adjustment. You referred to these as "GNSS data" but it appears to just be a list of coordinates without any measurement data. Let us know if you have further questions.

Clark

[Jose Ernesto Muñoz N.]

Muchas gracias Clark.. Un colega de chile me señalo que ´salsa aplica para cuando hay muchos datos redundantes, en este caso son solo mediciones de diferentes puntos... Agradezco el soporte brindado... Gracias

[Scott Mitchell]

Hi there.

I have just downloaded the software after reading a thread on the EMLID community pages. It looks really good so far. One of the contributors there has setup a batch script to take the exported baseline data from EMLID studio into a format to append to the SALSA project file.

I am experiencing the same issue as Mauro above, with an "invalid covariance". The test set I have is for a static log in the Scottish Highlands, using OSNet data as reference stations. There are five in total, with a deliberate use of long baseline as I want to test the result against Carlson GNSS which I have been trialling in the background.

My trouble is that no matter what I do the xx, xy,... values throw up this error. I tried to manually enter eveything with zeros and still no joy. My question is a basic one. What are the rules around these numbers, and how do I setup the vectors to do it. I realise the residuals from Emlid studio are small, but the log was 2 hour static in very good conditions, and with some settings tweaking to get a fixed solution in there. The SALSA manual doesn't help my cause, the numbers I have are negative as per the exported solution. I managed to remove error warnings by putting larger numbers in there (7mm, 8mm, all +ve) which gave me a chance to run a LSA (Chi-Failed but that is not my concern just now). I am just a bit perplexed as to what I should be putting in there, and if there is a tweak I am missing.

Any assistance or guidance would be much appreciated.

Many Thanks

Scott Mitchell

Link to ES thread.

Data files. The OS Stations file is the base reference stations from OSNet. The XXXX_Drumbeg files are the results of the Emlid studio processing for each vector baseline. And the dxyz file contains the vectors as per the script I mentioned.

[Clark Hughes]

Hi Scott,

I'm very hopeful that some folks on our team who are smarter than me will chime in with some help, but here is my quick take...

I believe that the error you're seeing is based on a test of the covariance matrix being positive definite. A non positive definite covariance matrix is non-physical and can't be passed along to the least squares formulation. I suspect that either your GNSS processing software or your conversion script is running into some precision limits which are resulting in the invalid matrix. I won't speculate further but will show you what I see when I play with the first matrix from your attached file dxyz_blocks.txt:

That file includes:

DXYZ BRAE Drumbeg -30120.94200 43846.00620 20705.73880 m ... 1.000e-08 0.000e+00 1.000e-08 ... 1.000e-08 0.000e+00 ... 1.000e-08

We can check for positive eigenvalues in python/numpy:

>>> import numpy as np

>>> from numpy.linalg import eig

>>> a = np.array([[1.0e-8, 0.0,    1.0e-8],
              [0.0,    1.0e-8, 0.0   ],
              [1.0e-8, 0.0,    1.0e-8]])

>>> w,v=eig(a)

>>> print('E-value:', w)
E-value: [2.e-08 0.e+00 1.e-08]

Note the zero-value eigenvalue above; that seems to be the problem.

Noticing that the off-diagonal xz component is the same magnitude as the diagonal components, I thought to try dialing that down an order of magnitude:

>>> a = np.array([[1.0e-8, 0.0,    1.0e-9],
              [0.0,    1.0e-8, 0.0   ],
              [1.0e-8, 0.0,    1.0e-8]])
>>> w,v=eig(a)
>>> print('E-value:', w)
E-value: [1.31622777e-08 6.83772234e-09 1.00000000e-08]

Now we see that all the eigenvalues are positive, and this covariance matrix will probably pass SALSA's test.

Again, I'm wary of speculating about the upstream GNSS processing and your scripts, but I think the take-away is that the covariance information passed to SALSA has to be physical. Hopefully you find the above guidance useful; reach out with any further questions or needs.

Clark