[time-nuts] BC637PCI 1024 week rollover
GandalfG8 at aol.com
GandalfG8 at aol.com
Thu Feb 13 15:46:50 UTC 2014
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.
More information about the Time-nuts_lists.febo.com
mailing list