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, [email protected] wrote:
In a message dated 10/02/2014 21:56:25 GMT Standard Time,
[email protected] writes:
On 10/02/14 11:15, [email protected] 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 -- [email protected]
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 -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
