[time-nuts] BC637PCI 1024 week rollover

[Magnus Danielson]

On 09/02/14 22:05, GandalfG8 at aol.com wrote:
> In a message dated 09/02/2014 15:31:47 GMT Standard Time,
> magnus at rubidium.dyndns.org writes:
>
> On  09/02/14 12:56, GandalfG8 at aol.com wrote:
>> Oh well, full credit to Mr  Trimble for getting it right, he does bake
>> exceedingly nice GPS  modules and the Ace3 doesn't have a rollover issue
> and it
>> does  report the date correctly.
>>
>> Unfortunately, as far as I can tell  anyway, the BC637PCI takes the raw
> GPS
>> time data from the Ace3 and  performs its own calculation which is where
> the
>>    problem  seems to occur, certainly it's a 1024 week issue with the date
>>   from  the BC637 being displayed as June 26 1994 in all versions of  the
>> associated  demo software.
>> It is possible to set the  date correctly but the next packet from the GPS
>> module promptly  overwrites it again.
>>
>> I still don't recall seeing this before,  although with two boards
> behaving
>> in the same fashion I'm having  doubts about that, but more to the point
>> these boards indicate a  firmware date of 2003 which implies they were
> put
>> into the field  like this, and that doesn't make much sense  either.
>>
>> Any  ideas anyone?, and again has anyone else seen this and/or am I
> missing
>>   something glaringly obvious?
>
> If the ACE3 gives correct date, but the  BC637 FW does not, then it is
> obvious that the FW does the unwrapping  itself just like a problematic
> GPS receiver would. Most probably would the  ACE3 have issues if it
> looses it's CMOS backup.
>
> I haven't looked at  those details, but you should be able to disable the
> date from being set  by the GPS. Maybe play around there.
>
> Might be that the FW needs an  update, which naturally may not be in
> existence. Can you read-out the  EPROM?
>
> Only proves to show that my comment that NTPD needs to do the  1024 week
> correction for other GPS dependent drivers than the NMEA (NTP  bug 2466)
> is a correct assumption. See the posting I forwarded  yesterday.
>
> Cheers,
> Magnus
> Hi Magnus, and thanks for your comments.
>
> I arrived at the same conclusion regarding the BC637 firmware and  that's
> the issue I'd like to resolve, but I'm a bit cautious given that these  were
> produced after 1999 as I can't understand why the firmware wouldn't already
> have been updated.'

It probably operates on a shifted 1024 week period and that was probably 
not changed after the original code was written. Obviously the shifted 
wrapping has now occurred.

1999 is only relevant for the non-shifted 1024 period.

> It is possible to set the board for other than GPS, (Timecode, Freerunning,
>   or 1PPS) but I suspect I might then loose the conditioning, something I'd
> need to check. Either way, I'd like to have the correct GPS date too if
> possible, but it's the conditioning that's of more interest so I'd do without
> the correct date if needs be.
>
> I've identified two programmable devices, the version H manual  with
> schematics is very useful:-), the first being a OTP configuration PROM  for the
> Spartan FPGA and the other a TMS29F010 flash mamory IC which I suspect  holds
> the firmware. That is socketed but I don't think I have the necessary 32
> pin quad adapter to be able to read it.

It would be the TMS29F010 flash which would be of interest.

> This was only intended to be a quick test, funny how "quick  tests" soon
> become major projects:-), so these might have to go back  into hibernation
> again shortly, for the time being at least.

Fair enough!

Cheers,
Magnus