Hi Danny,
Not all NV08C units have calibrated group delay on Glonass channels.
NVS ships calibrated units only since April 2012 and distributors stock
may be outdated.
With code biases on Glonass RTKLIB will not manage to fix the
ambiguities properly when you enable Glonass AR, which should therefore
be turned OFF.
I recently bought from the factory some calibrated NV08C and will report
if I see improvements over the previous batches.
With regards to my implementation of the parser the code - being part of
RTKLIB - is open source.
Anybody is very welcome to modify it.
All the best,
Michele
On 27/09/2012 08:15, Danny Miller wrote:
Wow, misspelled the unit. NV08C now. The company is NVS.
The units also receive Galileo & Compass, but Galileo is only sending
dummy data and Compass is only supposed to be on a trial basis (low
accuracy) right now.
Danny
On 9/27/2012 12:59 AM, Danny Miller wrote:
I've been playing with the new NVS08C GPS, which Michele outlined in
a blog:
http://michelebavaro.blogspot.com/
Who wrote an RTKLib branch to support it.
They're pretty remarkable. I have 2 units with identical patch
antennas (also have Sarantel quad-helicals if I need 'em). These are
cheap antenna I bought on eBay like a year ago, but they do seem to
receive GLONASS sats nicely (the frequency is close). One thing to
note, the spec sheet seems to say it provides "2.65 to 2.8V" of
antenna power, which may not be enough. The reference schematic
contains a resistor and cap pair needed to use voltages supplies from
another rail (like 3.3v power for a 3.3v ant).
Since they receive GLONASS as well as GPS, the constellation view is
instantly quite huge, 20 sats isn't uncommon. In fact, on RAW, the
serial bandwidth is "significant" and from the look of it 115200 may
not be sufficient.
The units' output is amazingly consistent. With a pair of static
patch antennae on a groundplane, after about 30 sec they stop moving
and rarely move more than a few cm. Given a couple of hours, you may
see a track drift 1-2M, but it's a very smooth, noise-free track. If
you move it in a 1M square you'll see a ~1M square on the track.
That's without PPP or RTK, just watching the hardware solution. But,
they're off by about 1-2M from my "best result" from a PPP static
fix, and 1-2M from each other's solutions, too. But, they're HIGHLY
consistent inside of a unit. If I move the antenna under a metal
shield to kill the signal and bring it back out, the solution will
restart within about 0.5M of its last lock.
However, strangely, the RTK and PPP has so far been "off". That is,
when RTK DOES get to "Fixed", sometimes it's Fixed within a few CM,
but early on I get a lot of Fixed off my like 2-4M, and most of the
time I only have Float. The Lea-6T worked more stable in RTK IIRC.
It's odd because the simple non-RTK hardware solution can get better
results, at least early on.
I don't know if there might be a problem in the pseudorange/carrier
phase/doppler resulting in what seems like relatively poor RTKLib
performance, or maybe Michele's config or application code has
something strange, or maybe RTKLib has trouble with an unusually high
number of sats? (I guess I could retry that with GLONASS support
disabled to go back to a more modest number of sats).
Danny
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
