[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