rt17.c code change

[rtklibfan]

Thank you very much for making certain needed code changes in rt17.c. I was hoping you would. :-)

However, the following code change which you made in rt17.c/get_time() causes the week to be set to a negative value when raw->time is zero. I suspect that is not what you intended to have happen with that particular change.

Background: Unlike everyone else, Trimble does not give us the gps week number. That's why raw->time is zero there. When we don't know what the gps week number is, we just have to do the best we can. I went to considerable lengths in rt17.c to determine the correct gps week number whenever possible. When all else fails and we still don't know the gps week number when we need it, most of the time the current gps week number based on the current gps time is the correct choice. When it is not, such as when processing an old file, the user can use the -WEEK=n receiver dependent option. Please note that UNAVCO TEQC handles this the same way.

The rt17.c/get_time() code change in question:

if (week == 0)
{

if 0

    time2gpst(timeget(), &week);

else

    /* add to get week number (by TTAKA 2014/08/26) */
    time2gpst(raw->time, &week);

endif

    raw->week = week;

    trace( 2, "RT17: Initial GPS WEEK number unknown; "
              "WEEK number %d assumed.\n", week );
}

I suggest instead perhaps something similar to the following code:

if (week == 0)
{
    if ((raw->time.time == 0) && (raw->time.sec == 0.0))
        raw->time = timeget();

    time2gpst(raw->time, &week);
    raw->week = week;

    trace( 2, "RT17: Initial GPS WEEK number unknown; "
              "WEEK number %d assumed.\n", week );
}

[tomojitakasu]

The raw->time is previously initialized by the current CPU time in RTKNAVI, RTKRCV, STRSVR or STR2STR. It is also initialized in RTKCONV or CONVBIN by user input with input dialog or -tr option. Other formats have the same problem (lack of week info, how to resolve week number) typically in RTCM.

[astrodanco]

It was definitely zero when I went through the code in the debugger at which point it was set to a negative value by the referenced lines of code. It was CONVBIN running in the debugger. There must be some code path somewhere that doesn’t always initialize it.

[tomojitakasu]

Would you use -tr option to specify approx. receiving time for CONVBIN?

[astrodanco]

If you’re asking me what I would do, I would add the additional line of code I proposed earlier. :-)

[astrodanco]

This issue is made moot by code changes included in my pull request #45 (RT17 updates) and can be closed if/when that pull request is merged.

[astrodanco]

I see what you did there in 2.4.3 beta, in rt17.c/get_time() using utc2gpst(timeget()) instead of only timeget(). Thank you for that important code review and correction! I appreciate it. Could you please do the same sort of correction with the somewhat differing RT17 Update code I submitted? Thank you.

[tomojitakasu]

They are merged to rtklib 2.4.2 p10. Thanks.

[a903139]

Where can I get rtklib´s libraries in COFF format, or their source code? Thank you.