Dear Danny
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?
The base-station position is fixed to just the single-solution
of the base-station. It does not need receiver's NMEA.
About 10 m error of the base-station position does not
affect the relative solution.
Tomoji TAKASU
--------------------------------------------------
From: "Danny Miller" <[email protected]>
Sent: Tuesday, June 21, 2011 5:16 AM
To: "Open Source GPS-related discussion and support"
<[email protected]>
Subject: Re: [FOSS-GPS] Can't get Ambiguity Validation Ratio to move
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
_______________________________________________
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
