[FOSS-GPS] Questions regarding NV08C-CMS + RTKLIB

[Michele Bavaro]

Hello Neil,

Some comments in line below:

On 03/11/2013 05:47, Neil Schemenauer wrote:
> Hi,
>
> Before I get into a long description of my problems, I want to thank
> the people making open-source GNSS a possibility.  RTKLIB looks like
> an amazing piece of work, thanks to T. Takasu for such a generous
> gift to the world.  Also thanks to Michele Bavaro, he has been very
> generous with his time as well.
>
> I purchased two NV08C-CMS receivers from OptimalSystem.DE.  I'm
> using two Tallysman TW3430 antennas.  The hardware seems to be
> working but I have trouble getting a FIX solution.  I think
> something is wrong with my setup but I don't know what.  My view of
> the sky is pretty clear and I think my antennas are pretty good
> quality.  The baseline is short, say 25 to 1000 m.
>
> Here is one of many different sets of RTKNAVI options that I tried:
>
>      http://arctrix.com/nas/tmp/rtk-kin2.conf
>
> I tried AR "fix-and-hold" as well as "continuous".  I tried GPS
> only, GPS+SBAS, GPS+GLO, GPS+GLO+SBAS.  I can often get a FIX
> solution if I use "static" instead of kinematic, if I wait a while.
> Kinematic can't seem to hold a fixed solution.  BTW, can I use
> static if I am occasionally moving the rover while doing a survey?

I think that as long as you use "continuous" it should be possible, 
although with little benefit compared to restarting the AR each time.
This would better be answered by Tomoji anyway.
There is a fundamental problem with doing Glonass AR, which is the 
uncalibrated bias of Glonass carrier phase measurements.
NV08C-CSM allows you to read and write the Glonass code biases table 
(messages A0h and A1h), but not carrier phase.
Biases are introduced mainly by different path lengths in the hardware 
filters for different frequencies. GPS has all satellites on the same 
frequency (CDMA) so the delay is common to all channels and cancels out 
when doing double differences. Glonass uses a DSSS FDMA modulation and 
the carrier frequencies span about 7MHz, which is enough to imply a 
non-common delay on all channels. By the way, the same problem is being 
studied for high-order Binary Offset Carrier (BOC) modulations as well 
(e.g. Galileo) where a different group delay on the two lobes of the 
signal might appear as multipath.
Calibration of code biases is a lot simpler than carrier phase biases as 
code is ambiguous by about 300km, whereas carrier is ambiguous by about 
19cm.
Calibration must be done either using a hardware simulator, or reverse 
engineering geometric ranges from a receiver placed at a known location 
and time
using precise products for satellite trajectory, satellite clock errors 
and atmosphere delays.
Once done, calibration should be quite robust to moderate environmental 
condition changes.

> The monitor log has errors like:
>
>      ambiguity validate failed nb=10 ratio=1.23 s=xx/xx
>      large residual (sat=XX-X ...)
>
> I think the 's' number gets larger as I run RTKNAVI.  I sometimes
> get a FIX solution for a moment when I first start RTKNAVI.  Based
> on the ground track plot, it looks to be the correct fix but it
> switches to FLOAT almost immediately.
FIX is declared when the AR ratio is above the threshold you set.
The threshold of 3.0, as per "Settings 2" tab is usually too optimistic.
IMHO, 10.0 is a safer choice.
I don't have the rover logs to post-process the Kinematic problem 
myself, please post those as well.
Tomoji could also investigate the problem then.

>
> Here are some NVS BINR files I saved from the base station.
>
>      http://arctrix.com/nas/tmp/roof.zip
>      http://arctrix.com/nas/tmp/roof-20131102.zip
>
> The RINEX files for the 20131102 data is here if you want to look at
> it directly:
>
>      http://arctrix.com/nas/tmp/roof-20131102.obs
>      http://arctrix.com/nas/tmp/roof-20131102.nav

I tried converting the BINR log with the un-official NVS BINR-to-Rinex 
converter:
https://www.dropbox.com/s/ptb0j4k0mcz5o7h/RCv3.0.zip
and the results are pretty similar to the last version of RTKCONV... at 
least.
I took broadcast ephemerides from IGS:
ftp://cddis.gsfc.nasa.gov/pub/gps/data/daily/2013/306/13g/ (Glonass)
ftp://cddis.gsfc.nasa.gov/pub/gps/data/daily/2013/306/13n/ (GPS)
to remove potential lack of nav data in the BINR log (this happens 
sometimes).

> I mounted the antenna on a roof, trying to stay above or away from
> possible multi-path sources.  Maybe I was not entirely successful.
> It seems like RTKLIB doesn't show anything about multi-path, maybe
> due to a limit of the NV08C receiver?
Tomoji to confirm, but I think multipath for single frequency is not 
implemented (please see 2.4.2 UM at page 69).
> Here is a PPP solution from the PPP tool provided by Natural
> Resources Canada (uses precise GNSS orbits and clocks).  I'm getting
> horizonal RMS errors of about 0.8 m, even with multiple hour
> observation data.  I was hoping for better.  This is shorter
> observation, from the roof.zip data I think:
>
>      http://arctrix.com/nas/tmp/roof-ppp.pdf
>
> In the above report, it looks like the receiver clock has a lot of
> drift, maybe that doesn't matter.
AFAIS, clock bias goes down approximately by 30us (475000 to 445000 ns) 
in 20 minutes (21:54 to 22:14).
This looks like a 25ns/sec clock drift, which seems actually tiny!
I will double check my calculation and get back to you on this.
> Another thing I noticed this afternoon while playing with the
> hardware, I don't seem to get many "NAV" messages from the
> receivers.  I understand these contain ephemeris and clock data.
> When I look at the RTKNAVI monitor, the "Obs(x)" count increases
> continuously but for "Nav(x)" I only seem to get a few after
> starting STRSRV.
I think NV08C-CSM only sends you a new exphemeris (message F7h) once it 
is updated by the system, meaning about once every two hours for GPS.
This is the reason why usually I plug the receiver, let it warm up and 
get all the ephemerides (usually 1 minute is more than enough in 
open-sky) before sending the F4h message with RTKLIB

> That leads me to another question.  Does anyone know where the
> startup/shutdown commands for the NV08C-CMS are documented?  Based
> on the datasheet, I guess these may depend on the firmware loaded on
> the receivers.  It would be nice to know some more details though.
> For example, the Storegis tool allows the elevation mask to be set.
> Maybe that's not relevant if you are reading raw data using BINR
> though.

The BINR and NMEA protocol are described in big detail in the documents 
found here:
http://www.nvs-gnss.com/support/documentation.html
It may be useful to set C/N0 and elevation masks.
At high latitudes, I have seen masks of 20-25 degrees being more 
successful than 10-15.
The geometry suffers as most satellites are South, but Glonass should 
mitigate the problem a little.

> I may be on the wrong track since I'm not an expert on GNSS but this
> NAV message issue seems like a problem.   Sometimes RTKNAVI will
> show many GPS sat signals above 40 dB but they will all be grey.
> Sometimes they will stay that way for many minutes.  It seems like
> restarting some of the programs may fix, maybe restarting STRSRV.  I
> think they are shown grey because there is "Obs" data but no "Nav"
> data for them.  The monitor view seems to confirm this.  The
> Storegis has no trouble finding many satellites and the position
> seems very stable so I don't think there is something wrong with my
> antenna, cable, etc.
Another way might be implementing parsing for message E5h (Bit 
Information Transmitted by Satellites): that would also get SBAS into 
RTKLIB.
I started writing some code, but came to the conclusion that the message 
structure is not RTKLIB-friendly.
NVS has not been receptive to my request of using separate messages to 
output nav-bits.

> Thanks for any direction and thanks again to the people making open
> source GNSS happen.
>
>    Neil
> _______________________________________________
> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription
> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
Cheers,
Michele