[time-nuts] BC637PCI 1024 week rollover

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  
itself.

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  
hint:-)

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.

Regards

Nigel
GM8PZR

In a message dated 10/02/2014 00:23:34 GMT Standard Time, time at patoka.org  
writes:

I  found the document about Trimble ACE3  module:

http://www.symres.com/files/ACE3.pdf

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 
no problems
with either dates or  first fix after WNRO through the year 2015.

[* Note – GPS Week Numbers  system, as defined by the ICD200 GPS 
Specification, occupy
a range from  zero to 1023. The Week Number Roll Over (WNRO) occurs every 
1024
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 
GPS outputs
the Extended GPS Week Number as the  absolute number of weeks since the 
beginning of
GPS time or 06 January  1980. If the true GPS Week Number is desired, the 
system
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 
0x1F.

Regards,

V.P.

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  
>> 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 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.
> 
> 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.
> 
> Regards
> 
> Nigel
> 
>  
> 
> _______________________________________________
>  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.
_______________________________________________
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.