Re: RINEX update

[John Ackermann N8UR]

Hi Gary --

Absolutely.  I mainly wanted to prove that the F9P itself wasn't the
problem.  I strongly suspect that when the M8P works, so will the F9P.

John
----

On 4/29/20 9:03 PM, Gary E. Miller wrote:
> Yo John!
> 
> I'll work on the M8P files first.  If those do not work then these
> will not.
> 
> On Wed, 29 Apr 2020 16:01:21 -0400
> John Ackermann N8UR <address@hidden> wrote:
> 
>> I repeated the process described below with the dual-frequency F9P
>> receiver, and RTKLIB convbin again processed this correctly while gpsd
>> did not.  Same sets of zip files attached here.
>>
>> (Files are called "short" because I'm currently doing an 8H capture
>> and this is just the first 20K lines of the log file.)
>>
>> John
>> ----
>>
>> On 4/29/20 11:28 AM, John Ackermann N8UR wrote:
>>> Last night I saved a couple of hours of raw observations from my M8P
>>> using gpspipe.  I thought using the single-frequency receiver would
>>> reduce the number of variables.
>>>
>>> This morning I generated .obs files from that data using gpsrinex
>>> and also rtklib's convbin program.
>>>
>>> I sent both .obs files to NRCan.  It processed the version from
>>> convbin, and rejected the version from gpsrinex.
>>>
>>> If the list accepts files this big, attached are a zip file
>>> containing the raw .ubx log and the two RINEX files, and another
>>> zip with the NRCan results for the convbin file.  If they don't
>>> come through, I'll share them via Dropbox.
>>>
>>> I tried comparing the two RINEX files by eye, but the differences
>>> between version 2.11 used by convbin and 3.03 used by gpsd are such
>>> that it's hard for me to spot much except:
>>>
>>> 1.  The convbin file includes only C1 and L1 data (not D1), and only
>>> specifies those two fields in the header, while the gpsd file
>>> specifies six fields in the header and includes C1 L1 and D1 in the
>>> data with the other fields left blank (which I believe is OK).
>>>
>>> 2.  The convbin file starts at 23 22 29.9940000, while the gpsd file
>>> starts at 23 25 00.9940000 -- 2 1/2 minutes later.
>>>
>>> 3.  Both files wrote at 30 second intervals, but the convbin
>>> sequence is at 29 and 59 seconds, so apparently the timetags do
>>> *not* have to be at the 00 and 30 integer second points, at least
>>> for NRCan.
>>>
>>> 3.  Looking at contemporaneous data stanzas, the observations do not
>>> seem to line up at all.  Although the SVs seem to be listed in
>>> different order, I don't see any matching values column-to-column.
>>> (The stanzas are offset by one second, but even over 30 seconds the
>>> values in each file for each SV don't change in a gross way, so I
>>> don't think the offset makes much difference for eyeball purposes.)
>>>
>>> 4.  I haven't fully figured out the rules for the LLI bit, but where
>>> shown it doesn't seem to match up between the two files.
>>>
>>> Thanks,
>>> John
>>>   
> 
> 
> 
> 
> 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
>