On 09/02/14 22:05, gandal...@aol.com wrote:
In a message dated 09/02/2014 15:31:47 GMT Standard Time,
mag...@rubidium.dyndns.org writes:
On 09/02/14 12:56, gandal...@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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
