Weight Matrix about gogps_java

[ZiglioUK]

For example, a satellite with a very low elevation (2.5), leads to a weight of:
weight = 1 / Math.pow(Math.sin(elevation * Math.PI / 180), 2) = 517.7

Why 1/...? shouldn't weights be bigger when elevation is higher? it seems counterintuitive

[ege010]

Hi @ZiglioNZ!

What is used there is actually a cofactor matrix, the inverse of which is used to weight observations in the least-squares solution. Here you can find the corresponding code in the MATLAB version: http://sourceforge.net/p/gogps/code/HEAD/tree/trunk/positioning/least_squares/LS_SA_code.m#l104

DTM values are introduced as "pseudo-observations", with their own observation error (line 699 in this section: http://sourceforge.net/p/gogps/code/HEAD/tree/trunk/positioning/kalman/goGPS_KF_DD_code_phase_loop.m#l665).
You can check also equations (22) and (30) here: https://www.researchgate.net/publication/257836193_goGPS_Open_Source_Software_for_Enhancing_the_Accuracy_of_Low-cost_Receivers_by_Single-frequency_Relative_Kinematic_Positioning

[ZiglioUK]

I've actually already ported the Matlab code for DTM to Java and have been using it for a few months.
I've used it both with the Google Maps Elevation API (that is probably not precise enough for your needs) and without just to add a soft constraint when I only have 4 satellites.
I haven't found necessarily an increase in precision but when you use the DTM it converges much more quickly. I've found at times with 5 or 6 satellites I need to run up to 400 iterations before the update is smaller than 1m.

See https://github.com/Sirtrack/goGPS/blob/snapshotGPS/src/main/java/org/gogpsproject/ReceiverPosition.java (line 1302)

// Add height soft constraint
double lam = Math.toRadians(this.getGeodeticLongitude());
double phi = Math.toRadians(this.getGeodeticLatitude());
double hR_app = this.getGeodeticHeight();
...

I'd like to merge my contributions into the main project here (thank you for upgrading my access rights).
The problem with this file (ReceiverPosition.java) is it's just too big.
That's why #17
In order to foster innovation (!) we should be able to experiment without risking to break things for everyone.