gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gpsrinex and Trimble


From: John Ackermann N8UR
Subject: Re: gpsrinex and Trimble
Date: Wed, 6 May 2020 15:13:38 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1

Hi Gary -- top-answering to remove cruft.

ZIP file attached of the rinex files generated both with the old code
and with the patched version.

Here's the command file used to generate both the new and the old files
(with different -f arguments):

gpsrinex -i 30 -n 2880 --ant_type TRM41249.00 \
-f n8ur_f9p_gpsrinex_new.obs :3000

and this was the gpsfake command (again, identical but for filenames):

gpsfake -D 5 -1 -P 3000 n8ur_f9p.ubx

I normally do all my measurements from the antenna reference plane, so
the 0.0 meters is to be expected.   It's just that OPUS *really* wants
to make sure you don't mess that up.

And, I'm not sure that OPUS actually reads that data from the header --
it wants you to enter antenna type and elevation regardless of whether
they are in the file.

The uploads failed both yesterday and today, and the data is now 2+ days
old, so the last reason given shouldn't apply.

John
----

On 5/6/20 2:48 PM, Gary E. Miller wrote:
> Yo John!
> 
> On Wed, 6 May 2020 11:40:43 -0400
> John Ackermann N8UR <address@hidden> wrote:
> 
>> Tried that and NRCan was still happy, but OPUS wasn't:
>>
>> FILE: n8ur_f9p_gpsrinex_new.obs OP1588779287056
> 
> Could I see that file?
> 
>>  1008   NOTE: You provided a zero or negative antenna height.
>>  1008   If ARP HGT = 0.0, OPUS solves for the position of your
>> selected antenna's reference point (ARP).
>>  1008   If ARP HGT < 0.0, OPUS solves for a location inside or above
>> the antenna
> 
> The new --ant-h option can solve that one.
> 
>>  1020   1. Collection interval of the data file was not one of the
>> allowed rates.
>>  1020      The intervals that are accepted are 1,2,3,5,10,15,30
>> seconds.
> 
> You did not give your gpsrine command line, I assume -i 30, which
> is the default?
> 
> ? 1020   2. The time of each epoch is offset from one of the
>> above intervals.  The
>>  1020      seconds epoch field must coincide with one of the above
>> rates.
> 
> That is what the patch should change.  I'd like to see your file to confirm.
> 
> 
>> 1020   3. The data file may have been collected in kinematic
>> mode. OPUS does not
>>  1020      process kinematic data files.
> 
> Nope.
> 
>>  1020   4. Note: OPUS processes data every 30 seconds, and 2+ hour
>> files 1020      collected at the 1 second rate should be changed to
>> 30 seconds.
> 
> I assume you did longer than 2 hours?
> 
>> 1020   5. If your data were collected today or yesterday,
>> we may not have 1020      sufficient CORS data - try resubmitting
>> your file tomorrow. 1020
> 
> As it says, wait and retry.
> 
> RGDS
> GARY
> ---------------------------------------------------------------------------
> Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
>       address@hidden  Tel:+1 541 382 8588
> 
>           Veritas liberabit vos. -- Quid est veritas?
>     "If you can't measure it, you can't improve it." - Lord Kelvin
> 

Attachment: gprsinex_comparison.zip
Description: Zip archive


reply via email to

[Prev in Thread] Current Thread [Next in Thread]