[FOSS-GPS] Can't get Ambiguity Validation Ratio to move

Tomoji Takasu ttaka at yk.rim.or.jp
Mon Jun 20 17:11:06 EDT 2011


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" <dannym at austin.rr.com>
Sent: Tuesday, June 21, 2011 5:16 AM
To: "Open Source GPS-related discussion and support" 
<foss-gps at lists.osgeo.org>
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" <dannym at austin.rr.com>
>> Sent: Tuesday, June 21, 2011 1:34 AM
>> To: "Open Source GPS-related discussion and support" 
>> <foss-gps at lists.osgeo.org>
>> 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" <dannym at austin.rr.com>
>>>> Sent: Monday, June 20, 2011 5:07 PM
>>>> To: <foss-gps at lists.osgeo.org>
>>>> 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 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> 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
>>
>
> _______________________________________________
> 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
>
>
> 




More information about the FOSS-GPS mailing list