Open DavidKelleySCSC opened 6 years ago
DavidKelleySCSC
commented
6 years ago Bump.
Would like input data from at least two other GNSS devices from other makers
Still need some a few other data sources to test this out. If you can provide a Mt1003 (and MT1011) feed from your base station, and it is not using RTKLIB code to do so, please contact me by PM.
tomojitakasu
commented
3 years ago In general, 1 ms ambiguity resolution is not easy work without any other information except for stream data themselves. For example, no satellite ephemerides found in most CORS streams. In other cases, the station position itself is unknown. In these cases, it is difficult to resolve 1 ms ambiguity in pseudorange of measurement messages. I know some 1 ms ambiguity resolution techniques like in A-GPS (Diggelen, 2009) 4.4 but it can not be applied without satellite position info. It is just a reason why I decided RTKLIB does not support basic or compact measurement messages without 1 ms ambiguity, including MT1001, 1003, 1009, 1011, MSM1, MSM2 and MSM3.
Last week there was a lively thread titled "Someone help me for NRTK Settings ?" from @ogokdas which went over a number of setup issues before getting things worked out. Sorry, do not know how to link to this.
One of the lesson learned (at least to me) was that the RTCM 3.x MT1003 and MT1011 messages are not decoded (or used) in the RTKLIB code base. So I thought I would add it and created this thread to track that work and to ask for the assistance of others in testing.
Background: In general terms, a MT1003 (or MT1011 the GLO one) is simply the more common MT1004 (or MT1012) but without the CNR values for L1 or L2, and without the ambiguity value (used to remove the 1mSec pRange modulo). For this you save 3 bytes per SV in the message. Very few deployments can be found using this message, as it turned out CNR is very useful.
The CNR values are not used in the 'stock' RTKLIB nav filter, although it is a very common practice to de-weight the observational values sent to the Kalman filter when CNR drops off and this provides a great improvement in moving vehicles due to drop outs. The gain factor used into the covariance matrix is typically nonlinear and matched to the GNSS correlator behavior under weak signal levels. If you are planning to add that to the stock filter, be sure and also add a Doppler gate function as well and mobile performance is greatly improved.
The only problem I see in decoding the MT1003 and the creating the observation data structure that RTKLIB uses is the ambiguity value (amb from now). In the 'old days' of the 80's I was taught to use the estimated position and the ephemeris to determine the gross distance to each SV, and hence the modulo ambiguity. As as this is a base station, we have a good location in ECEF to use. But my own experience is that novice users often do not set that value (msgs MT005/1006) so it seems to me to be a brittle solution to depend on that.
My key technical questions for those that know are; how does one efficiently determine the ambiguity value without the bother of staring a filter up? What do you think of a solution that depends on the ECEF values to be present and grossly correct before it can be used? Feedback solicited.
Help: I would like to test this new code with with at least two independent data sources. At present I have a message stream from a NAVCOM SF-3050 model, but there seems to be some issues with that setup. Would like input data from at least two other GNSS devices from other makers, and we can provide an NTRIP Caster site where these can all be placed for community access and testing. On the decoder side, there is the new RTKLIB code to be developed and validated (the DUT), our firms SNIP decoder code, and RTCM Inspect a commercial tool I have come to trust over the years from Alberding GmbH. Some of the older tool may also be of value here, I have yet to check.