OK, I was wondering about that. The base is not actually moving, but
this seems right.
How does it calculate E/N/U-Baseline without a base location? The
spatial orientation of the EN plane changes (rotates) with lat/long.
I assume it calculates an approximate lat/long solution and uses that to
come up with the orientation of the ENU coordinate system? Can it do
this with SkyTraq-Raw, without a solution from the receiver itself?
BTW, I am very excited about RTKlib, and cannot thank you enough for
making it available the way you have. There is no shortage of practical
uses for this.
Thanks,
Danny
On 6/20/2011 2:40 PM, Tomoji Takasu wrote:
Dear Danny
What is the best way to determine a location? If I use a single
unit's NMEA, I will not know the location with centimeter accuracy.
Collect receiver data in some period, process them in
"Single" mode and average the results.
Am I correct in understanding that the small error in base location
will not affect the relative accuracy of the base-to-rover
difference? Only that the absolute location of the rover will be off
by an identical amount?
You are right.
It might be useful to have a mode where the output is purely a
relative distance vector might be useful. Would that get rid of the
need to fix exact coordinates for a base?
Use "Moving-Base" mode and output "E/N/U-Baseline".
regards,
Tomoji TAKASU
--------------------------------------------------
From: "Danny Miller" <[email protected]>
Sent: Tuesday, June 21, 2011 1:34 AM
To: "Open Source GPS-related discussion and support"
<[email protected]>
Subject: Re: [FOSS-GPS] Can't get Ambiguity Validation Ratio to move
OK- thank you so much! I will try it out!
What is the best way to determine a location? If I use a single
unit's NMEA, I will not know the location with centimeter accuracy.
Am I correct in understanding that the small error in base location
will not affect the relative accuracy of the base-to-rover
difference? Only that the absolute location of the rover will be off
by an identical amount?
It might be useful to have a mode where the output is purely a
relative distance vector might be useful. Would that get rid of the
need to fix exact coordinates for a base?
I was gonna say "maybe it should get an inaccurate base location from
NMEA", but SkyTrak-Raw doesn't offer a calculated position fix at all.
Danny
On 6/20/2011 3:56 AM, Tomoji Takasu wrote:
Dear Danny
In the data window of RTKNavi, I noticed the Lat/long/height of
Base is not listed with real numbers (90deg 0m). This isn't right-
that GPS has a fine solution in NMEA.
You have to set the base-station position properly in
Options dialog for relative modes. RTKNAVI never uses
receiver's NMEA.
This is FAQ. So I will add FAQ in the support page.
regards,
********
Tomoji TAKASU
--------------------------------------------------
From: "Danny Miller" <[email protected]>
Sent: Monday, June 20, 2011 5:07 PM
To: <[email protected]>
Subject: [FOSS-GPS] Can't get Ambiguity Validation Ratio to move
I'm new to RTK. I have a pair of LEA-6T GPS units, one active
Sarantel SL-1206 quadrafiliar helix ant. There were supposed to be
two of those but the second one was DOA so I'm making do with an
active patch antenna for the second. I don't have an antenna file
for either of them. I'm using 2.4.1.
I have UBX RXM-RAW and RXM-SFRB reading out of both of them at 5Hz
(tried this at 1Hz too). I can get a fix out of either one of
them. In Kinematic mode of RTKNavi, I get a position, but the
"ratio factor of ambiguity validation" factor is stuck at 0.0. I
waited like an hour and it was still at 0.
In the data window of RTKNavi, I noticed the Lat/long/height of
Base is not listed with real numbers (90deg 0m). This isn't right-
that GPS has a fine solution in NMEA. Both Base and Rover are
showing strong (~45dbHz) signal bars in all colors.
I looked under Solution 1 and Solution 2 and both have valid,
similar solutions.
I looked under errors and saw:
eight "outlier rejected" per sample period (5Hz)
one "no double-differenced residuals" message
I tried switching the COM ports for Base and Rover, effectively
switching which unit was which (neither is moving right now).
Nothing changed, the "Base" unit channel still has no
Lat/long/height and ambiguity validation is still 0. That is, the
problem is not tied to the GPS hardware unit.
I tried disabling the Rover in RTKnavi. There's still no solution
under the Lat/Long/Height of Base. The signal strength bars all
turn gray.
I tried the mkl version (I have an i7). It didn't change anything.
I tried 2.4.0 rtknavi. In that one, I can't get a rover solution
to show up at all, it's blank on the main window and rtkplot shows
nothing.
Any ideas?
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
_______________________________________________
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
