[time-nuts] BC637PCI 1024 week rollover

d0ct0r time at patoka.org
Tue Feb 11 22:45:27 EST 2014


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.


More information about the time-nuts mailing list