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 [email protected] 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
_______________________________________________
This message is sent to you from [email protected] 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
