[time-nuts] BC637PCI 1024 week rollover

Magnus Danielson magnus at rubidium.dyndns.org
Sun Feb 9 09:35:42 EST 2014


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




More information about the time-nuts mailing list