[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
>
gprsinex_comparison.zip
Description: Zip archive