[time-nuts] BC637PCI 1024 week rollover
magnus at rubidium.dyndns.org
Sun Feb 9 19:06:37 EST 2014
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
>> time data from the Ace3 and performs its own calculation which is where
>> 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
>> 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
>> 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
>> 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.
> 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.
More information about the time-nuts