[time-nuts] BC637PCI 1024 week rollover
GandalfG8 at aol.com
GandalfG8 at aol.com
Mon Feb 10 04:31:11 EST 2014
That's the document I was refering to when I said earlier that I'd seen
written confirmation from Trimble that they weren't expecting any rollover
problems with the Ace3, I didn't mention the "through the year 2015" comment
as we haven't actually got there yet:-)
That may indeed be an issue in the not too distant future but for now I
have no concerns over the Ace3, as per previous comments I've tested both the
Ace3 and Ace2 and demonstrated they handle the date correctly.
The problem, as I'm seeing it here anyway, seems to lie with the BC637
The BC637 demo software menu item "Time/Receiver Time" returns, by way of
example, the following,....
Time of Week -- 119761.64, Week Number -- 1779, GPS/UTC -- 16.0
Note that the week number is correct, and this is one of the reasons I've
assumed the BC637 is taking raw data from the Ace3 and doing its own
processing, the fact that the Ace3 iteslf knows the right date is perhaps another
All I'm still hoping for at the moment is just that another BC637 user can
confirm whether or not they're seeing the same thing or whether their date
display from the demo software is correct.
It does appear that the BC637 is in error but this still doesn't seem to me
to be logical, given its date of manufacture plus my doubts over what it
was doing a few years ago.
So, at this stage, I still feel I haven't fully eliminated the possibility
that it's me doing something stupid, and that's all I'm trying to
establish before pursuing it any further.
In a message dated 10/02/2014 00:23:34 GMT Standard Time, time at patoka.org
I found the document about Trimble ACE3 module:
Here is the paragraph about WNRO:
Effect of GPS Week Number Roll-over (WNRO)
The ACE III GPS module has been designed to handle WNRO, and there are
with either dates or first fix after WNRO through the year 2015.
[* Note – GPS Week Numbers system, as defined by the ICD200 GPS
a range from zero to 1023. The Week Number Roll Over (WNRO) occurs every
weeks, or approximately every 19 years 8 months. August 1999 was the
first roll-over for
the GPS system since the beginning of GPS time on 06 January 1980.]
[ Caution – Trimble OEM GPS receivers have reported the true GPS Week
Number in TSIP
messages 0x41 and 0x8F-20 as a number between 0 and 1023. The ACE III
the Extended GPS Week Number as the absolute number of weeks since the
GPS time or 06 January 1980. If the true GPS Week Number is desired, the
developer should ignore the extra MSBs of the Extended GPS Week Number
and use only
the 10 LSBs]
I tried to modify the "demo" code to obtain FW of my GPS module. But I
had no luck with it, since
"bcGPSMan" subroutine always return ERROR state in response to packet ID
On 2014-02-09 16: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
> and it
>> does report the date correctly.
>> Unfortunately, as far as I can tell anyway, the BC637PCI takes the
>> time data from the Ace3 and performs its own calculation which is
>> problem seems to occur, certainly it's a 1024 week issue with the
>> from the BC637 being displayed as June 26 1994 in all versions of
>> associated demo software.
>> It is possible to set the date correctly but the next packet from the
>> 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
>> 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
> 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
> correction for other GPS dependent drivers than the NMEA (NTP bug
> 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
> the issue I'd like to resolve, but I'm a bit cautious given that these
> produced after 1999 as I can't understand why the firmware wouldn't
> have been updated.
> It is possible to set the board for other than GPS, (Timecode,
> or 1PPS) but I suspect I might then loose the conditioning, something
> 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
> 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
> the firmware. That is socketed but I don't think I have the necessary
> pin quad adapter to be able to read it.
> This was only intended to be a quick test, funny how "quick tests"
> become major projects:-), so these might have to go back into
> again shortly, for the time being at least.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to
and follow the instructions there.
More information about the time-nuts