[time-nuts] BC637PCI 1024 week rollover
d0ct0r
time at patoka.org
Thu Feb 13 16:53:49 EST 2014
I modified two things for now. Its a "demo" software (Linux edition).
And refclock_banncom driver for NTP. Personally, I would prefer to
modify microcode or library. But that is proprietary with no source code
around.
Regards,
V.P.
On 2014-02-13 10:46, GandalfG8 at aol.com wrote:
> You've lost me, what code are you modifying at the moment, is it the
> actual Datum demo software?
>
> Regards
>
> Nigel
> GM8PZR
>
>
> In a message dated 12/02/2014 03:48:12 GMT Standard Time,
> time at patoka.org
> writes:
>
>
> You are right ! Now I am going to modify the code a lit bit.
>
> Each time as we call bcReadBinTimeEx or bcReadBinTime, we need to add
> "magic number" to unsigned long pointer which store major time.
> Example:
>
> if (bcReadBinTime(stfp_handle, &btm[1], &btm[0], &stat ) == 0) {
> msyslog(LOG_ERR, "get_datumtime error:
> %m");
> return(NULL);
> }
> btm[1] + 619315200;
>
>
> At least its working for "demo":
>
> Binary Time: 02/12/2014 03:45:09.6158902 Status: 7
> Binary Time: 02/12/2014 03:45:09.6259547 Status: 7
> Binary Time: 02/12/2014 03:45:09.6360200 Status: 7
>
>
>
>
> On 2014-02-10 18:51, GandalfG8 at aol.com wrote:
>> In a message dated 10/02/2014 21:56:25 GMT Standard Time,
>> magnus at rubidium.dyndns.org writes:
>>
>> On 10/02/14 11:15, GandalfG8 at aol.com wrote:
>>> Ah, I took 1999 as I thought that was the only relevant date for
>>> another
>>> 1024 weeks, I'm not familiar with the shifted 1024 week period so
>>> will
>> take a
>>> look at that.
>>>
>>> Does "shifted" imply a shift at the whim of the manufacturer, ie
>>> could
>> it
>>> explain why these boards might have been ok a few years ago but
>>> not
>>> now?
>>
>> Yes. We have seen week 500 and week 512 occuring.
>>
>> Considering this simple code:
>>
>> if (gpsweek < 500)
>> gpsweek += 1024;
>>
>> This means that GPS week 500 to 1023 maps straight and truncated
>> GPS
>> week 0 to 499 is mapped to GPS week 1024 to 1523.
>>
>> However, when GPS week 1524 occurs, GPS week 500 is transmitted, so
>> receivers jump from GPS week 1523 to GPS week 500 and the NMEA
>> readout
>> date jumps 19.3 years. Woops.
>>
>> The interesting thing is that the GPS otherwise operate properly, as
>> it
>> is only the read-out date which goes wrong, not the internal gears
>> of
>> the GPS, so the leap second applied will be the current and not the
>> one
>> from 19 years ago.
>> -------------------------------------
>> Yes, that's what I was seeing, anything received by the GPS module
>> was
>> passed through correctly, week number, leap seconds, etc, it was what
>> the BC637
>> did with it after that wasn't quite so helpful.
>> -------------------------------------
>>
>>
>>
>>> Oh dear, I think a wee light bulb has just exploded:-)
>>
>> Good. :)
>>
>>> I haven't checked this yet, but if shifting means to start a 1024
>>> week
>>> period that's approximately from or not too far before the date
>>> of
>>> manufacture, either for individual units or just as a ballpark for
>>> a
>> given production
>>> run, that would buy them nearly twenty years from then, which
>>> would
>> mean
>>> these boards should still be ok.
>>
>> It's arbitrary. It could be from writing the code to just before a
>> certain batch. Who knows. Adjusting it is trivial.
>>
>>> If shifting means to do this say at the design stage or starting
>>> with
>>> the
>>> first production run then they might buy twenty years from then but
>>> regardless of individual manufacturing date.
>>
>> It's arbitrary. Considering that GPS week 500 and GPS week 512 have
>> been
>> found in equipment, and these are not "random numbers", it seems
>> like
>> a
>> random pick early in the design.
>>
>>> I'm not too sure that even the earliest of these boards should be
>>> twenty
>>> years old yet, but if plan Z was to stick with some previously
>>> picked
>>> arbitrary date, such as company formation or granny's birthday,
>>> then
>> that might
>>> well be the answer:-)
>>>
>>> Thank you, will definitely look more closely at this, perhaps it's
>>> not
>> time
>>> yet to put the boards back into hibernation after all:-)
>>
>> Good, now you learned something. :)
>> ------------------------
>> Certainly seems that way, perhaps the old brain cell does still fire
>> up
>> now and again after all:-)
>>
>> I was quite surprised though just how little a Google search threw up
>> on
>> 1024 week offsets, however I worded it I got plenty of hits regarding
>> the
>> 1024 week rollover itself, plus its implications, but virtually
>> nothing
>> regarding the use of offsets and any consequences of that.
>> -----------------------
>>
>>
>>
>>
>>
>>> I agree re the TMS29F010, and I'm sure I could read it, but would
>>> definitely need an adapter for that.
>>
>> Ah. Yes.
>>
>> I don't know what FW my boards have, if it has the GPS FW latent or
>> not.
>> ----------------------------
>> I bought a set of PLCC adapters on Ebay this afternoon, probably
>> about
>> time
>> my programmers joined the 19th century, so with a bit of luck, a
>> following
>> wind, and a good head of steam, I might even have a dump of the
>> firmware
>> by the weekend:-)
>>
>> Regards
>>
>> Nigel
>> GM8PZR
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
> --
> WBW,
>
> V.P.
>
> --
> WBW,
>
> V.P.
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
--
WBW,
V.P.
More information about the time-nuts
mailing list